RFC4522 日本語訳

Network Working Group                                            S. Legg
Request for Comments: 4522                                       eB2Bcom
Category: Standards Track                                      June 2006

Leggがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4522年のeB2Bcomカテゴリ: 標準化過程2006年6月

             Lightweight Directory Access Protocol (LDAP):
                       The Binary Encoding Option

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP): オプションをコード化するバイナリー

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

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

Abstract

要約

   Each attribute stored in a Lightweight Directory Access Protocol
   (LDAP) directory has a defined syntax (i.e., data type).  A syntax
   definition specifies how attribute values conforming to the syntax
   are normally represented when transferred in LDAP operations.  This
   representation is referred to as the LDAP-specific encoding to
   distinguish it from other methods of encoding attribute values.  This
   document defines an attribute option, the binary option, that can be
   used to specify that the associated attribute values are instead
   encoded according to the Basic Encoding Rules (BER) used by X.500
   directories.

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)ディレクトリに保存された各属性は定義された構文(すなわち、データ型)を持っています。 構文定義はLDAP操作で移すとどう通常構文に従う属性値を表すかを指定します。 この表現は、属性値をコード化する他のメソッドとそれを区別するためにLDAP特有のコード化と呼ばれます。 このドキュメントは属性オプション、X.500ディレクトリによって使用されるBasic Encoding Rules(BER)によると、関連属性値が代わりにコード化されると指定するのに使用できる2進のオプションを定義します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Conventions .....................................................2
   3. The Binary Option ...............................................2
   4. Syntaxes Requiring Binary Transfer ..............................3
   5. Attributes Returned in a Search .................................4
   6. All User Attributes .............................................4
   7. Conflicting Requests ............................................5
   8. Security Considerations .........................................5
   9. IANA Considerations .............................................5
   10. References .....................................................5
      10.1. Normative References ......................................5
      10.2. Informative References ....................................6

1. 序論…2 2. コンベンション…2 3. 2進のオプション…2 4. バイナリーを必要とする構文が移されます…3 5. 属性は検索で戻りました…4 6. すべてのユーザ属性…4 7. 闘争要求…5 8. セキュリティ問題…5 9. IANA問題…5 10. 参照…5 10.1. 標準の参照…5 10.2. 有益な参照…6

Legg                        Standards Track                     [Page 1]

RFC 4522            LDAP: The Binary Encoding Option           June 2006

Legg規格はRFC4522LDAPを追跡します[1ページ]: 2006年6月にオプションをコード化するバイナリー

1.  Introduction

1. 序論

   Each attribute stored in a Lightweight Directory Access Protocol
   (LDAP) directory [RFC4510] has a defined syntax (i.e., data type)
   which constrains the structure and format of its values.

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)ディレクトリ[RFC4510]に保存された各属性は値の構造と形式を抑制する定義された構文(すなわち、データ型)を持っています。

   The description of each syntax [RFC4517] specifies how attribute or
   assertion values [RFC4512] conforming to the syntax are normally
   represented when transferred in LDAP operations [RFC4511].  This
   representation is referred to as the LDAP-specific encoding to
   distinguish it from other methods of encoding attribute values.

それぞれの構文[RFC4517]の記述はLDAP操作[RFC4511]で移すとどう通常構文に従う属性か主張値[RFC4512]を表すかを指定します。 この表現は、属性値をコード化する他のメソッドとそれを区別するためにLDAP特有のコード化と呼ばれます。

   This document defines an attribute option, the binary option, which
   can be used in an attribute description [RFC4512] in an LDAP
   operation to specify that the associated attribute values or
   assertion values are, or are requested to be, encoded according to
   the Basic Encoding Rules (BER) [BER] as used by X.500 [X.500]
   directories, instead of the usual LDAP-specific encoding.

このドキュメントは属性オプションを定義して、Basic Encoding Rules(BER)によると、関連属性値か値があるか、または要求されているという主張をある2進のオプション(指定するのにLDAP操作における属性記述[RFC4512]に使用できる)はX.500[X.500]ディレクトリによって使用されるように[BER]をコード化しました、普通のLDAP特有のコード化の代わりに。

   The binary option was originally defined in RFC 2251 [RFC2251].  The
   LDAP technical specification [RFC4510] has obsoleted the previously
   defined LDAP technical specification [RFC3377], which included RFC
   2251.  The binary option was not included in the revised LDAP
   technical specification for a variety of reasons including
   implementation inconsistencies.  No attempt is made here to resolve
   the known inconsistencies.

2進のオプションは元々、RFC2251[RFC2251]で定義されました。 LDAP技術仕様書[RFC4510]は以前に定義されたLDAP技術仕様書[RFC3377]を時代遅れにしました。(それは、RFC2251を含んでいました)。 2進のオプションは実装矛盾を含むさまざまな理由による改訂されたLDAP技術仕様書に含まれていませんでした。 知られている矛盾を決議するためにここで試みを全くしません。

   This document reintroduces the binary option for use with certain
   attribute syntaxes, such as certificate syntax [RFC4523], that
   specifically require it.  No attempt has been made to address use of
   the binary option with attributes of syntaxes that do not require its
   use.  Unless addressed in a future specification, this use is to be
   avoided.

明確にそれを必要とする証明書構文[RFC4523]などのある属性構文でこのドキュメントは使用のための2進のオプションに再紹介します。 使用を必要としない構文の属性で2進のオプションの使用を扱うのを試みを全くしていません。 将来の仕様で扱われない場合、この使用は避けられることです。

2.  Conventions

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, RFC 2119
   [BCP14].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[BCP14]で説明されるように本書では解釈されることであるべきです。

3.  The Binary Option

3. 2進のオプション

   The binary option is indicated with the attribute option string
   "binary" in an attribute description.  Note that, like all attribute
   options, the string representing the binary option is case
   insensitive.

2進のオプションは属性記述における属性オプションストリング「バイナリー」で示されます。 すべてがオプションを結果と考えるように2進のオプションを表すストリングが大文字と小文字を区別しないことに注意してください。

Legg                        Standards Track                     [Page 2]

RFC 4522            LDAP: The Binary Encoding Option           June 2006

Legg規格はRFC4522LDAPを追跡します[2ページ]: 2006年6月にオプションをコード化するバイナリー

   Where the binary option is present in an attribute description, the
   associated attribute values or assertion values MUST be BER encoded
   (otherwise the values are encoded according to the LDAP-specific
   encoding [RFC4517] for the attribute's syntax).  Note that it is
   possible for a syntax to be defined such that its LDAP-specific
   encoding is exactly the same as its BER encoding.

2進のオプションが属性記述で存在しているところでは、関連属性値か主張値がコード化されたBERでなければなりません(さもなければ、属性の構文のためのLDAP特有のコード化[RFC4517]に従って、値はコード化されます)。 LDAP特有のコード化がまさにBERコード化と同じであるように、構文が定義されるのが、可能であることに注意してください。

   In terms of the protocol [RFC4511], the binary option specifies that
   the contents octets of the associated AttributeValue or
   AssertionValue OCTET STRING are a complete BER encoding of the
   relevant value.

プロトコル[RFC4511]で、2進のオプションは、関連AttributeValueかAssertionValue OCTET STRINGのコンテンツ八重奏が関連価値をコード化する完全なBERであると指定します。

   The binary option is not a tagging option [RFC4512], so the presence
   of the binary option does not specify an attribute subtype.  An
   attribute description containing the binary option references exactly
   the same attribute as the attribute description without the binary
   option.  The supertype/subtype relationships of attributes with
   tagging options are not altered in any way by the presence or absence
   of the binary option.

2進のオプションがタグ付けオプション[RFC4512]でないので、2進のオプションの存在は属性「副-タイプ」を指定しません。 まさに同じように2進のオプション参照を含んでいると2進のオプションなしで属性記述とみなされる属性記述。 タグ付けオプションがある属性のsupertype/subtype関係は2進のオプションの存在か欠如で何らかの方法で変更されません。

   An attribute description SHALL be treated as unrecognized if it
   contains the binary option and the syntax of the attribute does not
   have an associated ASN.1 type [RFC4517], or the BER encoding of
   values of that type is not supported.

属性記述SHALLは2進のオプションを含んでいて、関連ASN.1が属性の構文で[RFC4517]をタイプしないなら認識されていないとして扱われるか、またはサポートされませんその値のBERコード化が、タイプする。

   The presence or absence of the binary option only affects the
   transfer of attribute and assertion values in the protocol; servers
   store any particular attribute value in a format of their choosing.

2進のオプションの存在か欠如がプロトコルにおける、属性と主張値の転送に影響するだけです。 サーバは彼らが選ぶ形式でどんな特定の属性値も保存します。

4.  Syntaxes Requiring Binary Transfer

4. 2進の転送を必要とする構文

   The attribute values of certain attribute syntaxes are defined
   without an LDAP-specific encoding and are required to be transferred
   in the BER-encoded form.  For the purposes of this document, these
   syntaxes are said to have a binary transfer requirement.  The
   certificate, certificate list, certificate pair, and supported
   algorithm syntaxes [RFC4523] are examples of syntaxes with a binary
   transfer requirement.  These syntaxes also have an additional
   requirement that the exact BER encoding must be preserved.  Note that
   this is a property of the syntaxes themselves, and not a property of
   the binary option.  In the absence of this requirement, LDAP clients
   would need to re-encode values using the Distinguished Encoding Rules
   (DER).

ある属性構文の属性値が、LDAP特有のコード化なしで定義されて、BERによってコード化されたフォームで移すのに必要です。 このドキュメントの目的のために、これらの構文は2進の転送要件を持っていると言われています。 証明書、証明書リスト、証明書組、およびサポートしているアルゴリズム構文[RFC4523]は2進の転送要件がある構文に関する例です。 また、これらの構文には、正確なBERコード化を保存しなければならないという追加要件があります。 これが2進のオプションの特性ではなく、構文自体の特性であることに注意してください。 この要件がないとき、LDAPクライアントは、Distinguished Encoding Rules(DER)を使用することで値を再コード化する必要があるでしょう。

Legg                        Standards Track                     [Page 3]

RFC 4522            LDAP: The Binary Encoding Option           June 2006

Legg規格はRFC4522LDAPを追跡します[3ページ]: 2006年6月にオプションをコード化するバイナリー

5.  Attributes Returned in a Search

5. 検索で返された属性

   An LDAP search request [RFC4511] contains a list of the attributes
   (the requested attributes list) to be returned from each entry
   matching the search filter.  An attribute description in the
   requested attributes list also implicitly requests all subtypes of
   the attribute type in the attribute description, whether through
   attribute subtyping or attribute tagging option subtyping [RFC4512].

LDAP検索要求[RFC4511]は検索フィルタに合っている各エントリーから返される属性(要求された属性リスト)のリストを含んでいます。 また、要求された属性リストにおける属性記述は属性記述でそれとなく属性タイプのすべての血液型亜型を要求します、属性副タイプか属性タグ付けオプション副タイプ[RFC4512]にかかわらず。

   The requested attributes list MAY contain attribute descriptions with
   the binary option, but MUST NOT contain two attribute descriptions
   with the same attribute type and the same tagging options (even if
   only one of them has the binary option).  The binary option in an
   attribute description in the requested attributes list implicitly
   applies to all the subtypes of the attribute type in the attribute
   description (however, see Section 7).

要求された属性リストは、2進のオプションで属性記述を含むかもしれませんが、同じ属性タイプと同じタグ付けオプションで2つの属性記述は含んではいけません(彼らの唯一のひとりに2進のオプションがあっても)。 要求された属性リストにおける属性記述における2進のオプションは属性記述でそれとなく属性タイプのすべての血液型亜型に適用されます(しかしながら、セクション7を見てください)。

   Attributes of a syntax with the binary transfer requirement, if
   returned, SHALL be returned in the binary form (i.e., with the binary
   option in the attribute description and the associated attribute
   values BER encoded) regardless of whether the binary option was
   present in the request (for the attribute or for one of its
   supertypes).

バイナリーは要件を移します、返すなら、SHALL。構文の属性、バイナリーオプションが要求(属性か「スーパー-タイプ」の1つの)に存在していたかどうかにかかわらず二部形式(すなわち、属性記述における2進のオプションとBERがコード化した関連属性値がある)で返してください。

   Attributes of a syntax without the binary transfer requirement, if
   returned, SHOULD be returned in the form explicitly requested.  That
   is, if the attribute description in the requested attributes list
   contains the binary option, then the corresponding attribute in the
   result SHOULD be in the binary form.  If the attribute description in
   the request does not contain the binary option, then the
   corresponding attribute in the result SHOULD NOT be in the binary
   form.  A server MAY omit an attribute from the result if it does not
   support the requested encoding.

2進の転送要件のない構文の属性、返すならSHOULD、明らかに要求された書式で返してください。 すなわち、要求された属性リストにおける属性記述が2進のオプションを含んでいるなら、結果SHOULDの対応する属性は二部形式のそうです。 要求における属性記述が2進のオプションを含んでいないなら、結果SHOULD NOTの対応する属性は二部形式のそうです。 要求されたコード化をサポートしないなら、サーバは結果から属性を省略するかもしれません。

   Regardless of the encoding chosen, a particular attribute value is
   returned at most once.

選ばれたコード化にかかわらず、特定の属性値は高々一度返されます。

6.  All User Attributes

6. すべてのユーザ属性

   If the list of attributes in a search request is empty or contains
   the special attribute description string "*", then all user
   attributes are requested to be returned.

検索要求における属性のリストが空であるか、または特別な属性記述ストリング「*」を含んでいるなら、すべてのユーザ属性が返されるよう要求されます。

   Attributes of a syntax with the binary transfer requirement, if
   returned, SHALL be returned in the binary form.

2進の転送要件がある構文の属性、返すならSHALL、二部形式で返してください。

Legg                        Standards Track                     [Page 4]

RFC 4522            LDAP: The Binary Encoding Option           June 2006

Legg規格はRFC4522LDAPを追跡します[4ページ]: 2006年6月にオプションをコード化するバイナリー

   Attributes of a syntax without the binary transfer requirement and
   having a defined LDAP-specific encoding SHOULD NOT be returned in the
   binary form.

2進の転送要件のない構文の属性とバイナリーで定義されたLDAP特有のコード化SHOULD NOTを返させるのは形成されます。

   Attributes of a syntax without the binary transfer requirement and
   without a defined LDAP-specific encoding may be returned in the
   binary form or omitted from the result.

2進の転送要件のはない定義されたLDAP特有のコード化のはない構文の属性は、二部形式で返されるか、または結果から省略されるかもしれません。

7.  Conflicting Requests

7. 闘争要求

   A particular attribute could be explicitly requested by an attribute
   description and/or implicitly requested by the attribute descriptions
   of one or more of its supertypes, or by the special attribute
   description string "*".  If the binary option is present in at least
   one, but not all, of these attribute descriptions then the effect of
   the request with respect to binary transfer is implementation
   defined.

特定の属性は、属性記述で明らかに要求されている、そして/または、「スーパー-タイプ」の1つ以上の属性記述、または特別な属性記述ストリング「*」によってそれとなく要求されるかもしれません。 2進のオプションがすべてではなく、少なくともこれらの属性記述の1つで存在しているなら、2進の転送に関する要求の効果は定義された実装です。

8.  Security Considerations

8. セキュリティ問題

   When interpreting security-sensitive fields, and in particular fields
   used to grant or deny access, implementations MUST ensure that any
   matching rule comparisons are done on the underlying abstract value,
   regardless of the particular encoding used.

セキュリティ敏感な分野、および特にアクセスを承諾するか、または拒絶するのに使用される分野を解釈するとき、実装は、基本的な抽象的な値でどんな合っている規則比較もするのを確実にしなければなりません、使用される特定のコード化にかかわらず。

9.  IANA Considerations

9. IANA問題

   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
   attribute description option registry [BCP64] as indicated by the
   following template:

インターネットAssigned民数記Authority(IANA)は以下のテンプレートによって示されるようにLDAP属性記述オプション登録[BCP64]をアップデートしました:

      Subject:
        Request for LDAP Attribute Description Option Registration
      Option Name: binary
      Family of Options: NO
      Person & email address to contact for further information:
        Steven Legg <steven.legg@eb2bcom.com>
      Specification: RFC 4522
      Author/Change Controller: IESG

Subject: LDAP属性記述オプション登録オプション名のために以下を要求してください。 Optionsの2進のFamily: 詳細のために連絡しないPersonとEメールアドレス全く: スティーブン Legg <steven.legg@eb2bcom.com 、gt;、仕様: RFC4522作者/変化コントローラ: IESG

10.  References

10. 参照

10.1.  Normative References

10.1. 引用規格

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

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

Legg                        Standards Track                     [Page 5]

RFC 4522            LDAP: The Binary Encoding Option           June 2006

Legg規格はRFC4522LDAPを追跡します[5ページ]: 2006年6月にオプションをコード化するバイナリー

   [BCP64]    Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
              Considerations for the Lightweight Directory Access
              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

[BCP64]Zeilenga、K.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC4520、2006年6月。

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

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

   [RFC4511]  Sermersheim, J., "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月。

   [RFC4517]  Legg, S., Ed., "Lightweight Directory Access Protocol
              (LDAP):  Syntaxes and Matching Rules", RFC 4517, June
              2006.

[RFC4517] Legg、S.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「構文とマッチングは統治する」RFC4517、2006年6月。

   [RFC4523]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP) Schema Definitions for X.509 Certificates", RFC
              4523, June 2006.

[RFC4523]Zeilenga、K.、「X.509証明書のためのライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)図式定義」、RFC4523、2006年6月。

   [BER]      ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
              Information Technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER).

[BER]ITU-T推薦X.690(07/02)| ISO/IEC8825-1、情報Technology--ASN.1符号化規則: 基本的なコード化の仕様は(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)を統治します。

10.2.  Informative References

10.2. 有益な参照

   [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
              Access Protocol (v3)", RFC 2251, December 1997.

[RFC2251]ウォール、M.、ハウズ、T.、およびS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。

   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
              Protocol (v3): Technical Specification", RFC 3377,
              September 2002.

[RFC3377] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、2002年9月。

   [X.500]    ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
              Information technology - Open Systems Interconnection -
              The Directory:  Overview of concepts, models and services

[X.500]ITU-T推薦X.500(02/01)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-1:2001、ディレクトリ: 概念の、そして、モデルの、そして、サービスの概要

Legg                        Standards Track                     [Page 6]

RFC 4522            LDAP: The Binary Encoding Option           June 2006

Legg規格はRFC4522LDAPを追跡します[6ページ]: 2006年6月にオプションをコード化するバイナリー

Author's Address

作者のアドレス

   Dr. Steven Legg
   eB2Bcom
   Suite 3, Woodhouse Corporate Centre
   935 Station Street
   Box Hill North, Victoria 3129
   AUSTRALIA

スティーブンLegg eB2Bcom Suite博士3、北のウッドハウス法人のセンター935駅の通りBoxヒル、ビクトリア・3129オーストラリア

   Phone: +61 3 9896 7830
   Fax:   +61 3 9896 7801
   EMail: steven.legg@eb2bcom.com

以下に電話をしてください。 +61 3 9896 7830、Fax: +61 3 9896 7801はメールされます: steven.legg@eb2bcom.com

Legg                        Standards Track                     [Page 7]

RFC 4522            LDAP: The Binary Encoding Option           June 2006

Legg規格はRFC4522LDAPを追跡します[7ページ]: 2006年6月にオプションをコード化するバイナリー

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)によって提供されます。

Legg                        Standards Track                     [Page 8]

Legg標準化過程[8ページ]