RFC4520 日本語訳

Network Working Group                                        K. Zeilenga
Request for Comments: 4520                           OpenLDAP Foundation
BCP: 64                                                        June 2006
Obsoletes: 3383
Category: Best Current Practice

Zeilengaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4520OpenLDAP財団BCP: 64 2006年6月は以下を時代遅れにします。 3383年のカテゴリ: 最も良い現在の習慣

     Internet Assigned Numbers Authority (IANA) Considerations for
            the Lightweight Directory Access Protocol (LDAP)

ライトウェイト・ディレクトリ・アクセス・プロトコルのためのインターネット規定番号権威(IANA)問題(LDAP)

Status of This Memo

このメモの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   This document provides procedures for registering extensible elements
   of the Lightweight Directory Access Protocol (LDAP).  The document
   also provides guidelines to the Internet Assigned Numbers Authority
   (IANA) describing conditions under which new values can be assigned.

このドキュメントはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)の広げることができる原理を登録するための手順を提供します。 また、ドキュメントは、新しい値を割り当てることができる状態について説明しながら、インターネットAssigned民数記Authority(IANA)にガイドラインを供給します。

1.  Introduction

1. 序論

   The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an
   extensible protocol.  LDAP supports:

ライトウェイト・ディレクトリ・アクセス・プロトコル[RFC4510](LDAP)は広げることができるプロトコルです。 LDAPは以下をサポートします。

      -  the addition of new operations,
      -  the extension of existing operations, and
      -  the extensible schema.

- そして、新しい操作の追加--既存の操作の拡大、--広げることができる図式。

   This document details procedures for registering values used to
   unambiguously identify extensible elements of the protocol, including
   the following:

このドキュメントは明白に以下を含むプロトコルの広げることができる原理を特定するのに使用される値を示すための手順を詳しく述べます:

      - LDAP message types
      - LDAP extended operations and controls
      - LDAP result codes
      - LDAP authentication methods
      - LDAP attribute description options
      - Object Identifier descriptors

- LDAPメッセージタイプ--コントロール--LDAP結果コード--LDAP拡大手術とLDAP認証方法--LDAP属性記述オプション--オブジェクトIdentifier記述子

Zeilenga                 Best Current Practice                  [Page 1]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[1ページ]RFC4520IANA問題

   These registries are maintained by the Internet Assigned Numbers
   Authority (IANA).

これらの登録はインターネットAssigned民数記Authority(IANA)によって維持されます。

   In addition, this document provides guidelines to IANA describing the
   conditions under which new values can be assigned.

さらに、このドキュメントは新しい値を割り当てることができる状態について説明するIANAにガイドラインを供給します。

   This document replaces RFC 3383.

このドキュメントはRFC3383を取り替えます。

2.  Terminology and Conventions

2. 用語とコンベンション

   This section details terms and conventions used in this document.

このセクションは本書では使用される用語とコンベンションについて詳述します。

2.1.  Policy Terminology

2.1. 方針用語

   The terms "IESG Approval", "Standards Action", "IETF Consensus",
   "Specification Required", "First Come First Served", "Expert Review",
   and "Private Use" are used as defined in BCP 26 [RFC2434].

期間「IESG承認」、「規格動作」、「IETFコンセンサス」、「仕様が必要である」、「先着順」、「専門のレビュー」、および「私用」はBCP26[RFC2434]で定義されるように使用されています。

   The term "registration owner" (or "owner") refers to the party
   authorized to change a value's registration.

「登録所有者」(または、「所有者」)という用語は値の登録を変えるのに権限を与えられたパーティーについて言及します。

2.2.  Requirement Terminology

2.2. 要件用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119].  In
   this case, "the specification", as used by BCP 14, refers to the
   processing of protocols being submitted to the IETF standards
   process.

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように本書では解釈されることであるべきですか? この場合、BCP14によって使用される「仕様」はIETF標準化過程に提出されるプロトコルの処理を示します。

2.3.  Common ABNF Productions

2.3. 一般的なABNF創作

   A number of syntaxes in this document are described using ABNF
   [RFC4234].  These syntaxes rely on the following common productions:

多くの構文が、ABNF[RFC4234]を使用することで本書では説明されます。 これらの構文は以下の一般的な創作を当てにします:

         ALPHA = %x41-5A / %x61-7A    ; "A"-"Z" / "a"-"z"
         LDIGIT = %x31-39             ; "1"-"9"
         DIGIT = %x30 / LDIGIT        ; "0"-"9"
         HYPHEN = %x2D                ; "-"
         DOT = %x2E                   ; "."
         number = DIGIT / ( LDIGIT 1*DIGIT )
         keychar = ALPHA / DIGIT / HYPHEN
         leadkeychar = ALPHA
         keystring = leadkeychar *keychar
         keyword = keystring

アルファー=%x41-5A/%x61-7A。 --「Z」/“a"--「z」LDIGIT=%x31-39。 「1インチ--」 9インチのケタ=%x30 / LDIGIT。 「0インチ--」 9インチは=%x2Dをハイフンで結びます。 「--」ドット=%x2E。 「. 」 数は(LDIGIT1*DIGIT)keychar=アルファー/ DIGIT / HYPHEN leadkeychar=アルファーkeystring=leadkeychar*DIGIT/keycharなキーワード=keystringと等しいです。

   Keywords are case insensitive.

キーワードは大文字と小文字を区別しないです。

Zeilenga                 Best Current Practice                  [Page 2]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[2ページ]RFC4520IANA問題

3.  IANA Considerations for LDAP

3. LDAPのためのIANA問題

   This section details each kind of protocol value that can be
   registered and provides IANA guidelines on how to assign new values.

このセクションは、示すことができる各種類のプロトコル価値を詳しく述べて、どう新しい値を割り当てるかに関するガイドラインをIANAに供給します。

   IANA may reject obviously bogus registrations.

IANAは明らかににせの登録証明書を拒絶するかもしれません。

   LDAP values specified in RFCs MUST be registered.  Other LDAP values,
   except those in private-use name spaces, SHOULD be registered.  RFCs
   SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
   values.

RFCsで指定されたLDAP値を示さなければなりません。 登録されていて、私用名前空間のそれらを除いて、他のLDAPはSHOULDを評価します。 参照ではなく、RFCs SHOULD、登録されていないLDAP値を使用するか、またはそうでなければ、認識してください。

3.1.  Object Identifiers

3.1. オブジェクト識別子

   Numerous LDAP schema and protocol elements are identified by Object
   Identifiers (OIDs) [X.680].  Specifications that assign OIDs to
   elements SHOULD state who delegated the OIDs for their use.

多数のLDAP図式とプロトコル要素はObject Identifiers(OIDs)[X.680]によって特定されます。 要素SHOULDにOIDsを割り当てる仕様は、だれが彼らの使用のためにOIDsを代表として派遣したかを述べます。

   For IETF-developed elements, specifications SHOULD use OIDs under
   "Internet Directory Numbers" (1.3.6.1.1.x).  For elements developed
   by others, any properly delegated OID can be used, including those
   under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
   Enterprise Numbers" (1.3.6.1.4.1.x).

IETFによって開発された要素のために、仕様SHOULDは「インターネットディレクトリ番号」(1.3.6.1.1.x)の下でOIDsを使用します。 他のものによって発生された要素のために、どんな適切に代表として派遣されたOIDも使用できます、「インターネットディレクトリ番号」(1.3.6.1.1.x)か「インターネット私企業番号」(1.3.6.1.4.1.x)の下でそれらを含んでいて。

   Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
   Review with Specification Required.  Only one OID per specification
   will be assigned.  The specification MAY then assign any number of
   OIDs within this arc without further coordination with IANA.

インターネットディレクトリ民数記(1.3.6.1.1.x)はSpecification Requiredと共にExpert Reviewに割り当てられるでしょう。 1仕様あたり1OIDだけが割り当てられるでしょう。 そして、仕様はこのアークの中でIANAとのさらなるコーディネートなしでいろいろなOIDsを割り当てるかもしれません。

   Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
   IANA <http://www.iana.org/cgi-bin/enterprise.pl>.  Practices for IANA
   assignment of Internet Private Enterprise Numbers are detailed in RFC
   2578 [RFC2578].

インターネット兵士のエンタープライズ民数記(1.3.6.1.4.1.x)はIANA<http://www.iana.org/cgi-bin/enterprise.pl>によって割り当てられます。 インターネット兵士のエンタープライズ民数記のIANA課題のための習慣はRFC2578[RFC2578]で詳細です。

   To avoid interoperability problems between early implementations of a
   "work in progress" and implementations of the published specification
   (e.g., the RFC), experimental OIDs SHOULD be used in "works in
   progress" and early implementations.  OIDs under the Internet
   Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
   Practices for IANA assignment of these Internet Experimental numbers
   are detailed in RFC 2578 [RFC2578].

「処理中の作業」の早めの実装と広められた仕様(例えば、RFC)、実験的なOIDs SHOULDの実装の間の相互運用性問題を避けるには、「執筆中の作品」と早めの実装に使用されてください。 インターネットExperimental OIDアーク(1.3.6.1.3.x)の下におけるOIDsはこのために使用されるかもしれません。 これらのインターネットExperimental番号のIANA課題のための習慣はRFC2578[RFC2578]で詳細です。

3.2.  Protocol Mechanisms

3.2. プロトコルメカニズム

   LDAP provides a number of Root DSA-Specific Entry (DSE) attributes
   for discovery of protocol mechanisms identified by OIDs, including
   the supportedControl, supportedExtension, and supportedFeatures
   attributes [RFC4512].

LDAPは多くのRoot DSA特有のEntry(DSE)属性をOIDsによって特定されたプロトコルメカニズムの発見に提供します、supportedControl、supportedExtension、およびsupportedFeatures属性[RFC4512]を含んでいて。

Zeilenga                 Best Current Practice                  [Page 3]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[3ページ]RFC4520IANA問題

   A registry of OIDs used for discovery of protocol mechanisms is
   provided to allow implementors and others to locate the technical
   specification for these protocol mechanisms.  Future specifications
   of additional Root DSE attributes holding values identifying protocol
   mechanisms MAY extend this registry for their values.

作成者と他のものがこれらのプロトコルメカニズムのための技術仕様書の場所を見つけるのを許容するためにプロトコルメカニズムの発見に使用されるOIDsの登録を提供します。プロトコルメカニズムを特定する値を保持する追加Root DSE属性の将来の仕様は、それらの値のためにこの登録を広げるかもしれません。

   Protocol mechanisms are registered on a First Come First Served
   basis.

プロトコルメカニズムはFirst Come First Servedベースに登録されます。

3.3.  LDAP Syntaxes

3.3. LDAP構文

   This registry provides a listing of LDAP syntaxes [RFC4512].  Each
   LDAP syntax is identified by an OID.  This registry is provided to
   allow implementors and others to locate the technical specification
   describing a particular LDAP Syntax.

この登録はLDAP構文[RFC4512]のリストを提供します。 それぞれのLDAP構文はOIDによって特定されます。 作成者と他のものが特定のLDAP Syntaxについて説明する技術仕様書の場所を見つけるのを許容するためにこの登録を提供します。

   LDAP Syntaxes are registered on a First Come First Served with
   Specification Required basis.

LDAP SyntaxesはFirst Come First ServedにSpecification Required基礎に登録されます。

   Note: Unlike object classes, attribute types, and various other kinds
         of schema elements, descriptors are not used in LDAP to
         identify LDAP Syntaxes.

以下に注意してください。 オブジェクトのクラス、属性タイプ、および他の様々な種類の図式要素と異なって、記述子は、LDAP Syntaxesを特定するのにLDAPで使用されません。

3.4.  Object Identifier Descriptors

3.4. オブジェクト識別子記述子

   LDAP allows short descriptive names (or descriptors) to be used
   instead of a numeric Object Identifier to identify select protocol
   extensions [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516]
   extensions, and other objects.

LDAPは、短い描写的である名前(または、記述子)が数値Object Identifierの代わりに選んだプロトコル拡大[RFC4511]、図式要素[RFC4512]、LDAP URL[RFC4516]拡張子、および他のオブジェクトを特定するのに使用されるのを許容します。

   Although the protocol allows the same descriptor to refer to
   different object identifiers in certain cases and the registry
   supports multiple registrations of the same descriptor (each
   indicating a different kind of schema element and different object
   identifier), multiple registrations of the same descriptor are to be
   avoided.  All such multiple registration requests require Expert
   Review.

同じ記述子はプロトコルである場合には異なったオブジェクト識別子を示すことができます、そして、登録は同じ記述子の複数の登録証明書をサポートしますが(それぞれ異種の図式要素と異なったオブジェクト識別子を示して)、同じ記述子の複数の登録証明書は避けられることです。 すべてのそのような複数の登録要求がExpert Reviewを必要とします。

   Descriptors are restricted to strings of UTF-8 [RFC3629] encoded
   Unicode characters restricted by the following ABNF:

記述子は以下のABNFによって制限されたUTF-8[RFC3629]のコード化されたユニコード文字のストリングに制限されます:

      name = keystring

名前=keystring

   Descriptors are case insensitive.

記述子は大文字と小文字を区別しないです。

   Multiple names may be assigned to a given OID.  For purposes of
   registration, an OID is to be represented in numeric OID form (e.g.,
   1.1.0.23.40) conforming to the following ABNF:

複数の名前が与えられたOIDに割り当てられるかもしれません。 登録の目的のために、OIDが数値OIDフォームに表されることになっている、(例えば、1.1 .0 .23 .40) 以下のABNFに以下を従わせること。

Zeilenga                 Best Current Practice                  [Page 4]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[4ページ]RFC4520IANA問題

      numericoid = number 1*( DOT number )

numericoidはNo.1*と等しいです。(DOT番号)

   While the protocol places no maximum length restriction upon
   descriptors, they should be short.  Descriptors longer than 48
   characters may be viewed as too long to register.

プロトコルがどんな最大の長さの制限も記述子に置かない間、それらは短いはずです。 48のキャラクタより長い記述子は登録できないくらい長いとして見なされるかもしれません。

   A value ending with a hyphen ("-") reserves all descriptors that
   start with that value.  For example, the registration of the option
   "descrFamily-" reserves all options that start with "descrFamily-"
   for some related purpose.

ハイフン(「-」)がある値の結末はその値から始まるすべての記述子を予約します。 例えば、オプション"descrFamily"の登録は何らかの関連する目的のために"descrFamily"から始まるすべてのオプションを控えます。

   Descriptors beginning with "x-" are for Private Use and cannot be
   registered.

「x」で始まる記述子は、兵士のUseのためにあって、登録できません。

   Descriptors beginning with "e-" are reserved for experiments and will
   be registered on a First Come First Served basis.

記述子、始まる、「電子、」 実験のために予約されて、First Come First Servedベースに登録されるでしょう。

   All other descriptors require Expert Review to be registered.

他のすべての記述子が、Expert Reviewが登録されるのを必要とします。

   The registrant need not "own" the OID being named.

記入者は命名されるOIDを「所有する必要はありません」。

   The OID name space is managed by the ISO/IEC Joint Technical
   Committee 1 - Subcommittee 6.

スペースというOID名はISO/IEC Joint Technical Committee1によって管理されます--小委員会6。

3.5.  AttributeDescription Options

3.5. AttributeDescriptionオプション

   An AttributeDescription [RFC4512] can contain zero or more options
   specifying additional semantics.  An option SHALL be restricted to a
   string of UTF-8 encoded Unicode characters limited by the following
   ABNF:

AttributeDescription[RFC4512]は追加意味論を指定するゼロか、より多くのオプションを含むことができます。 SHALLにゆだねてください。UTF-8のストリングに制限されて、コード化されたユニコード文字が以下でABNFを制限したということになってください:

      option = keystring

オプションはkeystringと等しいです。

   Options are case insensitive.

オプションは大文字と小文字を区別しないです。

   While the protocol places no maximum length restriction upon option
   strings, they should be short.  Options longer than 24 characters may
   be viewed as too long to register.

プロトコルがどんな最大の長さの制限もオプションストリングに置かない間、それらは短いはずです。 24のキャラクタより長いオプションは登録できないくらい長いとして見なされるかもしれません。

   Values ending with a hyphen ("-") reserve all option names that start
   with the name.  For example, the registration of the option
   "optionFamily-" reserves all options that start with "optionFamily-"
   for some related purpose.

ハイフン(「-」)で終わる値は名前から始まるすべてのオプション名を予約します。 例えば、オプション"optionFamily"の登録は何らかの関連する目的のために"optionFamily"から始まるすべてのオプションを控えます。

   Options beginning with "x-" are for Private Use and cannot be
   registered.

「x」で始まるオプションは、兵士のUseのためにあって、登録できません。

Zeilenga                 Best Current Practice                  [Page 5]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[5ページ]RFC4520IANA問題

   Options beginning with "e-" are reserved for experiments and will be
   registered on a First Come First Served basis.

始めをゆだねる、「電子、」 実験のために予約されて、First Come First Servedベースに登録されるでしょう。

   All other options require Standards Action or Expert Review with
   Specification Required to be registered.

すべての別の選択肢が、Specification RequiredとStandards ActionかExpert Reviewが登録されるのを必要とします。

3.6.  LDAP Message Types

3.6. LDAPメッセージタイプ

   Each protocol message is encapsulated in an LDAPMessage envelope
   [RFC4511.  The protocolOp CHOICE indicates the type of message
   encapsulated.  Each message type consists of an ASN.1 identifier in
   the form of a keyword and a non-negative choice number.  The choice
   number is combined with the class (APPLICATION) and data type
   (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
   encoding.  The choice numbers for existing protocol messages are
   implicit in the protocol's ASN.1 defined in [RFC4511].

protocolOp CHOICEは、メッセージのタイプが要約したのを示します。それぞれのメッセージタイプはキーワードと非負の特選している数の形でASN.1識別子から成ります。特選している数は、メッセージのコード化でBERタグを組み立てるためにクラス(APPLICATION)とデータ型(CONSTRUCTEDかPRIMITIVE)に結合されます。それぞれのプロトコルメッセージがLDAPMessage封筒でカプセル化される、[RFC4511既存のプロトコルメッセージの特選している数は[RFC4511]で定義されたプロトコルのASN.1で暗に示されています。

   New values will be registered upon Standards Action.

新しい値はStandards Actionに示されるでしょう。

   Note: LDAP provides extensible messages that reduce but do not
         eliminate the need to add new message types.

以下に注意してください。 LDAPは減少しますが、新しいメッセージタイプを加える必要性を排除しない広げることができるメッセージを提供します。

3.7.  LDAP Authentication Method

3.7. LDAP認証方法

   The LDAP Bind operation supports multiple authentication methods
   [RFC4511].  Each authentication choice consists of an ASN.1
   identifier in the form of a keyword and a non-negative integer.

LDAP Bind操作は、複数の認証方法が[RFC4511]であるとサポートします。 それぞれの認証選択はキーワードと非負の整数の形でASN.1識別子から成ります。

   The registrant SHALL classify the authentication method usage using
   one of the following terms:

記入者SHALLは次の用語の1つを使用することで認証方法用法を分類します:

         COMMON      - method is appropriate for common use on the
                       Internet.
         LIMITED USE - method is appropriate for limited use.
         OBSOLETE    - method has been deprecated or otherwise found to
                       be inappropriate for any use.

COMMON--インターネットにおける一般の使用に、メソッドは適切です。 LIMITED USE--限られた使用に、メソッドは適切です。 推奨しないOBSOLETE--別の方法で、メソッドは、どんな使用にも不適当であることがわかりました。

   Methods without publicly available specifications SHALL NOT be
   classified as COMMON.  New registrations of the class OBSOLETE cannot
   be registered.

メソッド、公的に利用可能な仕様SHALL NOTがなければ、COMMONとして分類されてください。 クラスOBSOLETEの新しい登録証明書を登録できません。

   New authentication method integers in the range 0-1023 require
   Standards Action to be registered.  New authentication method
   integers in the range 1024-4095 require Expert Review with
   Specification Required.  New authentication method integers in the
   range 4096-16383 will be registered on a First Come First Served
   basis.  Keywords associated with integers in the range 0-4095 SHALL
   NOT start with "e-" or "x-".  Keywords associated with integers in

範囲0-1023の新しい認証方法整数は、Standards Actionが登録されるのを必要とします。 範囲1024-4095の新しい認証方法整数はSpecification RequiredとExpert Reviewを必要とします。 範囲4096-16383の新しい認証方法整数はFirst Come First Servedベースに示されるでしょう。 0-4095 範囲SHALL NOTの整数に関連しているキーワードが始まる、「電子、」 「x。」 関連している中に整数がある状態でキーワード

Zeilenga                 Best Current Practice                  [Page 6]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[6ページ]RFC4520IANA問題

   the range 4096-16383 SHALL start with "e-".  Values greater than or
   equal to 16384 and keywords starting with "x-" are for Private Use
   and cannot be registered.

範囲4096-16383SHALLが始める、「電子、」 値より多くの16384と「x」から始まるキーワードは、兵士のUseのためにあって、示すことができません。

   Note: LDAP supports Simple Authentication and Security Layers
         [RFC4422] as an authentication choice.  SASL is an extensible
         authentication framework.

以下に注意してください。 LDAPは認証選択としてSimple AuthenticationとSecurity Layers[RFC4422]をサポートします。 SASLは広げることができる認証フレームワークです。

3.8.  LDAP Result Codes

3.8. LDAP結果コード

   LDAP result messages carry a resultCode enumerated value to indicate
   the outcome of the operation [RFC4511].  Each result code consists of
   an ASN.1 identifier in the form of a keyword and a non-negative
   integer.

メッセージがresultCodeを運ぶというLDAP結果は、操作[RFC4511]の結果を示すために値を列挙しました。 それぞれの結果コードはキーワードと非負の整数の形でASN.1識別子から成ります。

   New resultCodes integers in the range 0-1023 require Standards Action
   to be registered.  New resultCode integers in the range 1024-4095
   require Expert Review with Specification Required.  New resultCode
   integers in the range 4096-16383 will be registered on a First Come
   First Served basis.  Keywords associated with integers in the range
   0-4095 SHALL NOT start with "e-" or "x-".  Keywords associated with
   integers in the range 4096-16383 SHALL start with "e-".  Values
   greater than or equal to 16384 and keywords starting with "x-" are
   for Private Use and cannot be registered.

範囲0-1023の新しいresultCodes整数は、Standards Actionが登録されるのを必要とします。 範囲1024-4095の新しいresultCode整数はSpecification RequiredとExpert Reviewを必要とします。 範囲4096-16383の新しいresultCode整数はFirst Come First Servedベースに示されるでしょう。 0-4095 範囲SHALL NOTの整数に関連しているキーワードが始まる、「電子、」 「x。」 4096-16383 範囲SHALLの整数に関連しているキーワードが始まる、「電子、」 値より多くの16384と「x」から始まるキーワードは、兵士のUseのためにあって、示すことができません。

3.9.  LDAP Search Scope

3.9. LDAP検索範囲

   LDAP SearchRequest messages carry a scope-enumerated value to
   indicate the extent of search within the DIT [RFC4511].  Each search
   value consists of an ASN.1 identifier in the form of a keyword and a
   non-negative integer.

LDAP SearchRequestメッセージは、DIT[RFC4511]の中に検索の範囲を示すために範囲で列挙された値を運びます。 それぞれの検索値はキーワードと非負の整数の形でASN.1識別子から成ります。

   New scope integers in the range 0-1023 require Standards Action to be
   registered.  New scope integers in the range 1024-4095 require Expert
   Review with Specification Required.  New scope integers in the range
   4096-16383 will be registered on a First Come First Served basis.
   Keywords associated with integers in the range 0-4095 SHALL NOT start
   with "e-" or "x-".  Keywords associated with integers in the range
   4096-16383 SHALL start with "e-".  Values greater than or equal to
   16384 and keywords starting with "x-" are for Private Use and cannot
   be registered.

範囲0-1023の新しい範囲整数は、Standards Actionが登録されるのを必要とします。 範囲1024-4095の新しい範囲整数はSpecification RequiredとExpert Reviewを必要とします。 範囲4096-16383の新しい範囲整数はFirst Come First Servedベースに示されるでしょう。 0-4095 範囲SHALL NOTの整数に関連しているキーワードが始まる、「電子、」 「x。」 4096-16383 範囲SHALLの整数に関連しているキーワードが始まる、「電子、」 値より多くの16384と「x」から始まるキーワードは、兵士のUseのためにあって、示すことができません。

3.10.  LDAP Filter Choice

3.10. LDAPフィルタ選択

   LDAP filters are used in making assertions against an object
   represented in the directory [RFC4511].  The Filter CHOICE indicates
   a type of assertion.  Each Filter CHOICE consists of an ASN.1
   identifier in the form of a keyword and a non-negative choice number.

LDAPフィルタはディレクトリ[RFC4511]に表されたオブジェクトに対して主張をする際に使用されます。 Filter CHOICEは一種の主張を示します。 各Filter CHOICEはキーワードと非負の特選している数の形でASN.1識別子から成ります。

Zeilenga                 Best Current Practice                  [Page 7]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[7ページ]RFC4520IANA問題

   The choice number is combined with the class (APPLICATION) and data
   type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
   message's encoding.

特選している数は、メッセージのコード化でBERタグを組み立てるためにクラス(APPLICATION)とデータ型(CONSTRUCTEDかPRIMITIVE)に結合されます。

   Note: LDAP provides the extensibleMatching choice, which reduces but
         does not eliminate the need to add new filter choices.

以下に注意してください。 LDAPはextensibleMatching選択を提供しますが、新しいフィルタ選択を加える必要性を排除しません。(選択は減少します)。

3.11.  LDAP ModifyRequest Operation Type

3.11. LDAP ModifyRequest操作タイプ

   The LDAP ModifyRequest carries a sequence of modification operations
   [RFC4511].  Each kind (e.g., add, delete, replace) of operation
   consists of an ASN.1 identifier in the form of a keyword and a non-
   negative integer.

LDAP ModifyRequestは変更操作[RFC4511]の系列を運びます。 各種類、(例えば、加えてください、削除、取り替え、)、操作はキーワードと非負の整数の形でASN.1識別子から成ります。

   New operation type integers in the range 0-1023 require Standards
   Action to be registered.  New operation type integers in the range
   1024-4095 require Expert Review with Specification Required.  New
   operation type integers in the range 4096-16383 will be registered on
   a First Come First Served basis.  Keywords associated with integers
   in the range 0-4095 SHALL NOT start with "e-" or "x-".  Keywords
   associated with integers in the range 4096-16383 SHALL start with
   "e-".  Values greater than or equal to 16384 and keywords starting
   with "x-" are for Private Use and cannot be registered.

範囲0-1023の新しい操作タイプ整数は、Standards Actionが登録されるのを必要とします。 範囲1024-4095の新しい操作タイプ整数はSpecification RequiredとExpert Reviewを必要とします。 範囲4096-16383の新しい操作タイプ整数はFirst Come First Servedベースに示されるでしょう。 0-4095 範囲SHALL NOTの整数に関連しているキーワードが始まる、「電子、」 「x。」 4096-16383 範囲SHALLの整数に関連しているキーワードが始まる、「電子、」 値より多くの16384と「x」から始まるキーワードは、兵士のUseのためにあって、示すことができません。

3.12.  LDAP authzId Prefixes

3.12. LDAP authzId接頭語

   Authorization Identities in LDAP are strings conforming to the
   <authzId> production [RFC4513].  This production is extensible.  Each
   new specific authorization form is identified by a prefix string
   conforming to the following ABNF:

LDAPの承認Identitiesは<authzId>生産[RFC4513]に一致しているストリングです。 この生産は広げることができます。 それぞれの新しい特定の承認フォームは以下のABNFに一致している接頭語ストリングによって特定されます:

         prefix = keystring COLON
         COLON = %x3A ; COLON (":" U+003A)

=keystringコロンコロン=%x3Aを前に置いてください。 コロン(「:」 U+003A)

   Prefixes are case insensitive.

接頭語は大文字と小文字を区別しないです。

   While the protocol places no maximum length restriction upon prefix
   strings, they should be short.  Prefixes longer than 12 characters
   may be viewed as too long to register.

プロトコルがどんな最大の長さの制限も接頭語ストリングに置かない間、それらは短いはずです。 12のキャラクタより長い接頭語は登録できないくらい長いとして見なされるかもしれません。

   Prefixes beginning with "x-" are for Private Use and cannot be
   registered.

「x」で始まる接頭語は、兵士のUseのためにあって、登録できません。

   Prefixes beginning with "e-" are reserved for experiments and will be
   registered on a First Come First Served basis.

始めを前に置く、「電子、」 実験のために予約されて、First Come First Servedベースに登録されるでしょう。

   All other prefixes require Standards Action or Expert Review with
   Specification Required to be registered.

他のすべての接頭語が、Specification RequiredとStandards ActionかExpert Reviewが登録されるのを必要とします。

Zeilenga                 Best Current Practice                  [Page 8]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[8ページ]RFC4520IANA問題

3.13.  Directory Systems Names

3.13. ディレクトリシステム名

   The IANA-maintained "Directory Systems Names" registry [IANADSN] of
   valid keywords for well-known attributes was used in the LDAPv2
   string representation of a distinguished name [RFC1779].  LDAPv2 is
   now Historic [RFC3494].

登録というよく知られる属性のための有効なキーワードのIANAによって維持された「ディレクトリシステム名」[IANADSN]は分類名[RFC1779]のLDAPv2ストリング表現に使用されました。 現在、LDAPv2はHistoric[RFC3494]です。

   Directory systems names are not known to be used in any other
   context.  LDAPv3 [RFC4514] uses Object Identifier Descriptors
   [Section 3.2] (which have a different syntax than directory system
   names).

いかなる他の文脈でもディレクトリシステム名が使用されるのが知られません。 LDAPv3[RFC4514]がObject Identifier Descriptors[セクション3.2]を使用する、(どれにディレクトリシステム名と異なった構文があるか、)

   New Directory System Names will no longer be accepted.  For
   historical purposes, the current list of registered names should
   remain publicly available.

新しいディレクトリSystem Namesはもう受け入れられないでしょう。 歴史的な目的のために、登録名の現在のリストは公的に利用可能なままで残っているはずです。

4.  Registration Procedure

4. 登録手順

   The procedure given here MUST be used by anyone who wishes to use a
   new value of a type described in Section 3 of this document.

このドキュメントのセクション3で説明されたタイプの新しい値を使用したがっているだれでもここの与えられた手順を用いなければなりません。

   The first step is for the requester to fill out the appropriate form.
   Templates are provided in Appendix A.

第一歩はリクエスタが適切な書類に書き込むことです。 テンプレートをAppendix Aに提供します。

   If the policy is Standards Action, the completed form SHOULD be
   provided to the IESG with the request for Standards Action.  Upon
   approval of the Standards Action, the IESG SHALL forward the request
   (possibly revised) to IANA.  The IESG SHALL be regarded as the
   registration owner of all values requiring Standards Action.

方針であるなら、Standards Action、完成したフォームはSHOULDです。Standards Actionを求める要求と共にIESGに供給してください。 Standards Actionの承認のときに、IESG SHALLは要求(ことによると、復習する)をIANAに転送します。 IESG SHALL、Standards Actionを必要とするすべての値の登録所有者と見なされてください。

   If the policy is Expert Review, the requester SHALL post the
   completed form to the <directory@apps.ietf.org> mailing list for
   public review.  The review period is two (2) weeks.  If a revised
   form is later submitted, the review period is restarted.  Anyone may
   subscribe to this list by sending a request to <directory-
   request@apps.ietf.org>.  During the review, objections may be raised
   by anyone (including the Expert) on the list.  After completion of
   the review, the Expert, based on public comments, SHALL either
   approve the request and forward it to the IANA OR deny the request.
   In either case, the Expert SHALL promptly notify the requester of the
   action.  Actions of the Expert may be appealed [RFC2026].  The Expert
   is appointed by Applications Area Directors.  The requester is viewed
   as the registration owner of values registered under Expert Review.

リクエスタSHALLが方針がExpert Reviewであるなら、完成したフォームを the <directory@apps.ietf.org に掲示する、gt;、公開レビューのためのメーリングリスト。 レビューの期間は何2(2)週間であるのも。 後で改訂されたフォームを提出するなら、レビューの期間を再開します。 だれでも<ディレクトリ- request@apps.ietf.org に要求を送ることによってこのリストに加入するかもしれない、gt。 レビューの間、反論はリストでだれによっても上げられるかもしれません(Expertを含んでいます)。 レビュー、SHALLがパブリックコメントに基づいて要求を承認して、それを送るExpertの完成の後に、IANA ORは要求を否定します。 どちらの場合ではも、Expert SHALLは即座に動作のリクエスタに通知します。 Expertの機能は上告されるかもしれません[RFC2026]。 ExpertはApplications Areaディレクターによって任命されます。 値の登録所有者がExpert Reviewの下に登録したので、リクエスタは見られます。

   If the policy is First Come First Served, the requester SHALL submit
   the completed form directly to the IANA: <iana@iana.org>.  The
   requester is viewed as the registration owner of values registered
   under First Come First Served.

方針がFirst Come First Servedであるなら、リクエスタSHALLは直接IANAに完成したフォームを提出します: <iana@iana.org>。 値の登録所有者がFirst Come First Servedの下に登録したので、リクエスタは見られます。

Zeilenga                 Best Current Practice                  [Page 9]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[9ページ]RFC4520IANA問題

   Neither the Expert nor IANA will take position on the claims of
   copyright or trademark issues regarding completed forms.

ExpertもIANAも完成したフォームに関する著作権か商標問題のクレームのときに立場を取らないでしょう。

   Prior to submission of the Internet Draft (I-D) to the RFC Editor but
   after IESG review and tentative approval, the document editor SHOULD
   revise the I-D to use registered values.

インターネットDraftの服従の前に、RFC Editorにもかかわらず、IESGレビューと一時的な承認の後にドキュメントエディタSHOULDへの(I-D)は、登録された値を使用するためにI-Dを改訂します。

5.  Registration Maintenance

5. 登録メインテナンス

   This section discusses maintenance of registrations.

このセクションは登録証明書のメインテナンスについて論じます。

5.1.  Lists of Registered Values

5.1. 登録された値のリスト

   IANA makes lists of registered values readily available to the
   Internet community on its web site: <http://www.iana.org/>.

IANAは登録された値のリストを容易にウェブサイトのインターネットコミュニティに利用可能にします: <http://www.iana.org/>。

5.2.  Change Control

5.2. 変化コントロール

   The registration owner MAY update the registration subject to the
   same constraints and review as with new registrations.  In cases
   where the registration owner is unable or is unwilling to make
   necessary updates, the IESG MAY assume ownership of the registration
   in order to update the registration.

登録所有者は新しい登録証明書なら同じ規制とレビューを条件として登録をアップデートするかもしれません。 登録所有者が必要なアップデートをしたがっていない場合では、IESG MAYは、登録をアップデートするために登録の所有権を引き受けます。

5.3.  Comments

5.3. コメント

   For cases where others (anyone other than the registration owner)
   have significant objections to the claims in a registration and the
   registration owner does not agree to change the registration,
   comments MAY be attached to a registration upon Expert Review.  For
   registrations owned by the IESG, the objections SHOULD be addressed
   by initiating a request for Expert Review.

他のもの(登録所有者以外のだれも)が登録におけるクレームに重要な反論を持って、登録所有者が登録を変えるのに同意しないケースにおいて、コメントはExpert Reviewでの登録に付けられるかもしれません。 IESG、反論SHOULDによって所有されていた登録証明書には、Expert Reviewを求める要求を開始することによって、扱われてください。

   The form of these requests is ad hoc, but MUST include the specific
   objections to be reviewed and SHOULD contain (directly or by
   reference) materials supporting the objections.

これらの要求のフォームは、臨時ですが、見直されるために特定の反論を含まなければなりません、そして、SHOULDは反論をサポートする材料を含んでいます(直接か参照で)。

6.  Security Considerations

6. セキュリティ問題

   The security considerations detailed in BCP 26 [RFC2434] are
   generally applicable to this document.  Additional security
   considerations specific to each name space are discussed in Section
   3, where appropriate.

一般に、BCP26[RFC2434]で詳細なセキュリティ問題はこのドキュメントに適切です。 適切であるところでセクション3でそれぞれの名前スペースに特定の追加担保問題について議論します。

   Security considerations for LDAP are discussed in documents
   comprising the technical specification [RFC4510].

技術仕様書[RFC4510]を包括するドキュメントでLDAPのためのセキュリティ問題について議論します。

Zeilenga                 Best Current Practice                 [Page 10]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[10ページ]RFC4520IANA問題

7.  Acknowledgement

7. 承認

   This document is a product of the IETF LDAP Revision (LDAPBIS)
   Working Group (WG).  This document is a revision of RFC 3383, also a
   product of the LDAPBIS WG.

このドキュメントはIETF LDAP Revision(LDAPBIS)作業部会(WG)の製品です。 また、このドキュメントはRFC3383の改正、LDAPBIS WGの製品です。

   This document includes text borrowed from "Guidelines for Writing an
   IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
   Harald Alvestrand.

このドキュメントはトーマスNartenとハラルドAlvestrandによって「RFCsにIANA問題部に書くためのガイドライン」[RFC2434]から借りられたテキストを含んでいます。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Structure of Management Information Version 2 (SMIv2)",
              STD 58, RFC 2578, April 1999.

[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日

   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510, June
              2006.

[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。

   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
              Protocol (LDAP): The Protocol", RFC 4511, June 2006.

[RFC4511] Sermersheim、J.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「プロトコル」、RFC4511、2006年6月。

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

[RFC4512] Zeilenga、K.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「ディレクトリ情報モデル」、RFC4512、2006年6月。

   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
              (LDAP): Authentication Methods and Security Mechanisms",
              RFC 4513, June 2006.

[RFC4513] ハリソン、R.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日

Zeilenga                 Best Current Practice                 [Page 11]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[11ページ]RFC4520IANA問題

   [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
              Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
              2006.

[RFC4516] エドスミス、M.、T.ハウズ、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「Uniform Resource Locator」、RFC4516、2006年6月。

   [Unicode]  The Unicode Consortium, "The Unicode Standard, Version
              3.2.0" is defined by "The Unicode Standard, Version 3.0"
              (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
              as amended by the "Unicode Standard Annex #27: Unicode
              3.1" (http://www.unicode.org/reports/tr27/) and by the
              "Unicode Standard Annex #28: Unicode 3.2"
              (http://www.unicode.org/reports/tr28/).

[ユニコード] ユニコードConsortium、「ユニコード規格、バージョン、3.2、0インチ、定義される、「ユニコード規格、修正されるバージョン3インチ(読書、MA、アディソン-ウエスリー、2000ISBN0-201-61633-5)、「ユニコード規格別館#27:」 「ユニコード規格別館#28:」 ユニコード3.2インチ( http://www.unicode.org/reports/tr28/ )。

   [X.680]    International Telecommunication Union - Telecommunication
              Standardization Sector, "Abstract Syntax Notation One
              (ASN.1) - Specification of Basic Notation", X.680(2002)
              (also ISO/IEC 8824-1:2002).

[X.680]国際電気通信連合--電気通信標準化セクター、「構文記法1(ASN.1)を抜き取ってください--基本的な記法の仕様」、X.680(2002)(ISO/IEC8824-1も: 2002)。

8.2.  Informative References

8.2. 有益な参照

   [RFC1779]  Kille, S., "A String Representation of Distinguished
              Names", RFC 1779, March 1995.

[RFC1779] Kille、S.、「分類名のストリング表現」、RFC1779、1995年3月。

   [RFC3494]  Zeilenga, K.,"Lightweight Directory Access Protocol
              version 2 (LDAPv2) to Historic Status", RFC 3494, March
              2003.

[RFC3494]Zeilenga、2003年3月のK.、「Historic Statusへのライトウェイト・ディレクトリ・アクセス・プロトコルバージョン2(LDAPv2)」RFC3494。

   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): String Representation of Distinguished Names", RFC
              4514, June 2006.

[RFC4514] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「分類名のストリング表現」、RFC4514、2006年6月。

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422, June
              2006.

エド[RFC4422]メリニコフ、A.、K.Zeilenga、エド、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、6月2006日

   [IANADSN]  IANA, "Directory Systems Names",
              http://www.iana.org/assignments/directory-system-names.

[IANADSN]IANA、「ディレクトリシステム名」、 http://www.iana.org/assignments/directory-system-names 。

Zeilenga                 Best Current Practice                 [Page 12]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[12ページ]RFC4520IANA問題

Appendix A.  Registration Templates

付録A.登録テンプレート

   This appendix provides registration templates for registering new
   LDAP values.  Note that more than one value may be requested by
   extending the template by listing multiple values, or through use of
   tables.

この付録は新しいLDAP値を示すための登録テンプレートを提供します。 1つ以上の値が複数の値を記載するか、テーブルの使用を通してテンプレートを広げることによって要求されているかもしれないことに注意してください。

A.1.  LDAP Object Identifier Registration Template

A.1。 LDAPオブジェクト識別子登録テンプレート

   Subject: Request for LDAP OID Registration

Subject: LDAP OIDには、登録を要求してください。

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Specification: (I-D)

仕様: (I-D)

   Author/Change Controller:

コントローラを書くか、または変えてください:

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

A.2.  LDAP Protocol Mechanism Registration Template

A.2。 LDAPプロトコルメカニズム登録テンプレート

   Subject: Request for LDAP Protocol Mechanism Registration

Subject: LDAPには、プロトコルメカニズム登録を要求してください。

   Object Identifier:

オブジェクト識別子:

   Description:

記述:

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Usage: (One of Control or Extension or Feature or other)

用法: (何らかのControl、ExtensionまたはFeatureの1つ)

   Specification: (RFC, I-D, URI)

仕様: (RFC、I-D、ユリ)

   Author/Change Controller:

コントローラを書くか、または変えてください:

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

Zeilenga                 Best Current Practice                 [Page 13]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[13ページ]RFC4520IANA問題

A.3.  LDAP Syntax Registration Template

A.3。 LDAP構文登録テンプレート

   Subject: Request for LDAP Syntax Registration

Subject: LDAP構文には、登録を要求してください。

   Object Identifier:

オブジェクト識別子:

   Description:

記述:

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Specification: (RFC, I-D, URI)

仕様: (RFC、I-D、ユリ)

   Author/Change Controller:

コントローラを書くか、または変えてください:

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

A.4.  LDAP Descriptor Registration Template

A.4。 LDAP記述子登録テンプレート

   Subject: Request for LDAP Descriptor Registration

Subject: LDAP記述子には、登録を要求してください。

   Descriptor (short name):

記述子(省略名):

   Object Identifier:

オブジェクト識別子:

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Usage: (One of administrative role, attribute type, matching rule,
     name form, object class, URL extension, or other)

用法: (1つ、管理役割、何らかの規則、名前フォーム、オブジェクトのクラス、URL拡大に合っている属性タイプ)

   Specification: (RFC, I-D, URI)

仕様: (RFC、I-D、ユリ)

   Author/Change Controller:

コントローラを書くか、または変えてください:

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

Zeilenga                 Best Current Practice                 [Page 14]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[14ページ]RFC4520IANA問題

A.5.  LDAP Attribute Description Option Registration Template

A.5。 LDAP属性記述オプション登録テンプレート

   Subject: Request for LDAP Attribute Description Option Registration
   Option Name:

Subject: LDAP属性記述オプション登録オプション名のために以下を要求してください。

   Family of Options: (YES or NO)

オプションのファミリー: (諾否)

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Specification: (RFC, I-D, URI)

仕様: (RFC、I-D、ユリ)

   Author/Change Controller:

コントローラを書くか、または変えてください:

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

A.6.  LDAP Message Type Registration Template

A.6。 LDAPメッセージタイプ登録テンプレート

   Subject: Request for LDAP Message Type Registration

Subject: LDAPメッセージタイプには、登録を要求してください。

   LDAP Message Name:

LDAPメッセージ名:

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Specification: (Approved I-D)

仕様: (承認されたI-D)

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

A.7.  LDAP Authentication Method Registration Template

A.7。 LDAP認証方法登録テンプレート

   Subject: Request for LDAP Authentication Method Registration

Subject: LDAPには、認証方法登録を要求してください。

   Authentication Method Name:

認証方法名:

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Specification: (RFC, I-D, URI)

仕様: (RFC、I-D、ユリ)

   Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)

意図している用法: (1つ、限られた使用であって、時代遅れのコモン、)

   Author/Change Controller:

コントローラを書くか、または変えてください:

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

Zeilenga                 Best Current Practice                 [Page 15]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[15ページ]RFC4520IANA問題

A.8.  LDAP Result Code Registration Template

A.8。 LDAP結果コード登録テンプレート

   Subject: Request for LDAP Result Code Registration

Subject: LDAPには、結果コード登録を要求してください。

   Result Code Name:

結果コードネーム:

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Specification: (RFC, I-D, URI)

仕様: (RFC、I-D、ユリ)

   Author/Change Controller:

コントローラを書くか、または変えてください:

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

A.8.  LDAP Search Scope Registration Template

A.8。 LDAP検索範囲登録テンプレート

   Subject: Request for LDAP Search Scope Registration

Subject: LDAPには、検索範囲登録を要求してください。

   Search Scope Name:

範囲名を捜してください:

   Filter Scope String:

範囲ストリングをフィルターにかけてください:

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Specification: (RFC, I-D, URI)

仕様: (RFC、I-D、ユリ)

   Author/Change Controller:

コントローラを書くか、または変えてください:

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

Zeilenga                 Best Current Practice                 [Page 16]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[16ページ]RFC4520IANA問題

A.9.  LDAP Filter Choice Registration Template

A.9。 LDAPのフィルタの特選している登録テンプレート

   Subject: Request for LDAP Filter Choice Registration

Subject: LDAPフィルタには、特選している登録を要求してください。

   Filter Choice Name:

特選している名前をフィルターにかけてください:

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Specification: (RFC, I-D, URI)

仕様: (RFC、I-D、ユリ)

   Author/Change Controller:

コントローラを書くか、または変えてください:

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

A.10.  LDAP ModifyRequest Operation Registration Template

A.10。 LDAP ModifyRequest操作登録テンプレート

   Subject: Request for LDAP ModifyRequest Operation Registration

Subject: LDAP ModifyRequestには、操作登録を要求してください。

   ModifyRequest Operation Name:

ModifyRequest操作名:

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

   Specification: (RFC, I-D, URI)

仕様: (RFC、I-D、ユリ)

   Author/Change Controller:

コントローラを書くか、または変えてください:

   Comments:

コメント:

   (Any comments that the requester deems relevant to the request.)

(リクエスタが要求に関連していると考えるどんなコメントも。)

Appendix B.  Changes since RFC 3383

RFC3383以来の付録B.変化

   This informative appendix provides a summary of changes made since
   RFC 3383.

この有益な付録はRFC3383以来行われた変更の概要を提供します。

      -  Object Identifier Descriptors practices were updated to require
         all descriptors defined in RFCs to be registered and
         recommending all other descriptors (excepting those in
         private-use name space) be registered.  Additionally, all
         requests for multiple registrations of the same descriptor are
         now subject to Expert Review.

- オブジェクトIdentifier DescriptorsはRFCsで定義されたすべての記述子が登録されるのが必要であるようにアップデートして、登録されていて、他のすべての記述子(私用名前スペースでそれらを除く)を推薦するのを練習します。 さらに、同じ記述子の複数の登録証明書を求めるすべての要求が現在、Expert Reviewを受けることがあります。

      -  Protocol Mechanisms practices were updated to include values of
         the 'supportedFeatures' attribute type.

- 'supportedFeatures'属性タイプの値を含むようにプロトコルMechanisms習慣をアップデートしました。

Zeilenga                 Best Current Practice                 [Page 17]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[17ページ]RFC4520IANA問題

      -  LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
         operation, and authzId prefixes registries were added.

- LDAP Syntax、検索Scope、Filter Choice、ModifyRequest操作、およびauthzId接頭語登録は加えられました。

      -  References to RFCs comprising the LDAP technical specifications
         have been updated to latest revisions.

- LDAP技術仕様書を包括するRFCsの参照を最新の改正にアップデートしました。

      -  References to ISO 10646 have been replaced with [Unicode].

- ISO10646の参照を[ユニコード]に取り替えました。

      -  The "Assigned Values" appendix providing initial registry
         values was removed.

- 「割り当てられた値」という初期の登録値を提供する付録は取られました。

      -  Numerous editorial changes were made.

- 多数の編集の変更は行われました。

Author's Address

作者のアドレス

   Kurt D. Zeilenga
   OpenLDAP Foundation

カートD.Zeilenga OpenLDAP財団

   EMail: Kurt@OpenLDAP.org

メール: Kurt@OpenLDAP.org

Zeilenga                 Best Current Practice                 [Page 18]

RFC 4520              IANA Considerations for LDAP             June 2006

LDAP2006年6月のためのZeilengaの最も良い現在の習慣[18ページ]RFC4520IANA問題

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Zeilenga                 Best Current Practice                 [Page 19]

Zeilengaの最も良い現在の習慣[19ページ]