RFC3866 日本語訳

Network Working Group                                   K. Zeilenga, Ed.
Request for Comments: 3866                           OpenLDAP Foundation
Obsoletes: 2596                                                July 2004
Category: Standards Track

ワーキンググループK.Zeilenga、エドをネットワークでつないでください。コメントのために以下を要求してください。 3866年のOpenLDAP財団は以下を時代遅れにします。 2596 2004年7月のカテゴリ: 標準化過程

                    Language Tags and Ranges in the
              Lightweight Directory Access Protocol (LDAP)

ライトウェイト・ディレクトリ・アクセス・プロトコルの言語タグと範囲(LDAP)

Status of this Memo

このMemoの状態

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

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).

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

Abstract

要約

   It is often desirable to be able to indicate the natural language
   associated with values held in a directory and to be able to query
   the directory for values which fulfill the user's language needs.
   This document details the use of Language Tags and Ranges in the
   Lightweight Directory Access Protocol (LDAP).

ディレクトリに保持される値に関連している自然言語を示して、ユーザの言語の必要性を実現させる値のためのディレクトリについて質問できるのはしばしば望ましいです。 ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)でこのドキュメントはLanguage TagsとRangesの使用を詳しく述べます。

1.  Background and Intended Use

1. バックグラウンドと意図している使用

   The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a
   means for clients to interrogate and modify information stored in a
   distributed directory system.  The information in the directory is
   maintained as attributes of entries.  Most of these attributes have
   syntaxes which are human-readable strings, and it is desirable to be
   able to indicate the natural language associated with attribute
   values.

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[RFC3377]はクライアントが分配されたディレクトリシステムに保存された情報について査問して、変更する手段を提供します。 ディレクトリの情報はエントリーの属性として保守されます。 これらの属性の大部分には、人間読み込み可能なストリングである構文があります、そして、属性値に関連している自然言語を示すことができるのは望ましいです。

   This document describes how language tags and ranges [RFC3066] are
   carried in LDAP and are to be interpreted by LDAP implementations.
   All LDAP implementations MUST be prepared to accept language tags and
   ranges.

このドキュメントは、言語タグと範囲[RFC3066]がどのようにLDAPで運ばれて、LDAP実装によって解釈されるかことであると説明します。 LDAP実装がそうしなければならないすべてが、言語タグを受け入れるように準備されて、及びます。

   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].

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

Zeilenga                    Standards Track                     [Page 1]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[1ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

   This document replaces RFC 2596.  Appendix A summaries changes made
   since RFC 2596.

このドキュメントはRFC2596を取り替えます。 付録A概要変化は以来、RFCを2596にしました。

   Appendix B discusses differences from X.500(1997) "contexts"
   mechanism.

付録BはX.500(1997)「文脈」メカニズムから違いについて議論します。

   Appendix A and B are provided for informational purposes only.

付録AとBを情報の目的だけに提供します。

   The remainder of this section provides a summary of Language Tags,
   Language Ranges, and Attribute Descriptions.

このセクションの残りはLanguage Tags、Language Ranges、およびAttribute記述の概要を提供します。

1.1.  Language Tags

1.1. 言語タグ

   Section 2 of BCP 47 [RFC3066] describes the language tag format which
   is used in LDAP.  Briefly, it is a string of [ASCII] letters and
   hyphens.  Examples include "fr", "en-US" and "ja-JP".  Language tags
   are case insensitive.  That is, the language tag "en-us" is the same
   as "EN-US".

BCP47[RFC3066]のセクション2はLDAPで使用される言語タグ形式について説明します。 簡潔に、それは、一連の[ASCII]手紙とハイフンです。 例は"fr"、「アン米国」、および「ja-JP」を含んでいます。 言語タグは大文字と小文字を区別しないです。 すなわち、言語タグ、「アン、-、私たち、」 「EN米国」と同じくらいはそうですか?

   Section 2 of this document details use of language tags in LDAP.

このドキュメントのセクション2はLDAPにおける言語タグの使用を詳しく述べます。

1.2.  Language Ranges

1.2. 言語は及びます。

   Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
   Language ranges are used to specify sets of language tags.

BCP47[RFC3066]のセクション2.5は言語範囲について説明します。 言語範囲は、言語タグのセットを指定するのに使用されます。

   A language range matches a language tag if it is exactly equal to the
   tag, or if it is exactly equal to a prefix of the tag such that the
   first character following the prefix is "-".  That is, the language
   range "de" matches the language tags "de" and "de-CH" but not "den".
   The special language range "*" matches all language tags.

それが「-」がまさにタグかそれともそれがまさにタグの接頭語と等しいので接頭語に従う最初のキャラクタがあるかどうかと等しいことであるなら、言語範囲は言語タグに合っています。 すなわち、言語範囲"de"は「書斎」ではなく言語タグの"de"と「反-CH」に合っています。 特別な言語範囲「*」はすべての言語タグに合っています。

   Due to attribute description option naming restrictions in LDAP, this
   document defines a different language range syntax.  However, the
   semantics of language ranges in LDAP are consistent with BCP 47.

LDAPでの制限を命名する属性記述オプションのため、このドキュメントは異なった言語範囲構文を定義します。 しかしながら、LDAPの言語範囲の意味論はBCP47と一致しています。

   Section 3 of this document details use of language ranges in LDAP.

言語のこのドキュメント詳細使用のセクション3はLDAPのねらいを定めます。

1.3.  Attribute Descriptions

1.3. 属性記述

   This section provides an overview of attribute descriptions in LDAP.
   LDAP attributes and attribute descriptions are defined in [RFC2251].

このセクションは属性記述の概要をLDAPに供給します。 LDAP属性と属性記述は[RFC2251]で定義されます。

   An attribute consists of a type, a set of zero or more associated
   tagging options, and a set of one or more values.  The type and the
   options are combined into the AttributeDescription.

属性はタイプ、1セットのゼロか、より関連したタグ付けオプション、および1つ以上の値のセットから成ります。 タイプとオプションはAttributeDescriptionに結合されます。

Zeilenga                    Standards Track                     [Page 2]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[2ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

   AttributeDescriptions can also contain options which are not part of
   the attribute, but indicate some other function (such as range
   assertion or transfer encoding).

また、AttributeDescriptionsは属性の一部でないオプションを含むことができますが、ある他の機能(範囲主張か転送コード化などの)を示してください。

   An AttributeDescription with one or more tagging options is a direct
   subtype of each AttributeDescription of the same type with all but
   one of the tagging options.  If the AttributeDescription's type is a
   direct subtype of some other type, then the AttributeDescription is
   also a direct subtype of the AttributeDescription which consists of
   the supertype and all of the tagging options.  That is,
   "CN;x-bar;x-foo" is a direct subtype of "CN;x-bar", "CN;x-foo", and
   "name;x-bar;x-foo".  Note that "CN" is a subtype of "name".

1つ以上のタグ付けオプションがあるAttributeDescriptionはタグ付けオプションの1つ以外のすべてがある同じタイプのそれぞれのAttributeDescriptionのダイレクト「副-タイプ」です。 AttributeDescriptionのタイプがある他のタイプのダイレクト「副-タイプ」であるなら、また、AttributeDescriptionは成る「スーパー-タイプ」のAttributeDescriptionとタグ付けオプションのすべてのダイレクト「副-タイプ」です。 すなわち、「CN; x-バー; x-foo」がダイレクト「副-タイプ」である、「CN、; x-バー、」、「CN;、x-foo、」 「名前; x-バー; x-foo。」 "CN"が「名前」の「副-タイプ」であることに注意してください。

2.  Use of Language Tags in LDAP

2. LDAPにおける言語タグの使用

   This section describes how LDAP implementations MUST interpret
   language tags in performing operations.

このセクションはLDAP実装が操作を実行する際にどう言語タグを解釈しなければならないかを説明します。

   Servers which support storing attributes with language tag options in
   the Directory Information Tree (DIT) SHOULD allow any attribute type
   it recognizes that has the Directory String, IA5 String, or other
   textual string syntaxes to have language tag options associated with
   it.  Servers MAY allow language options to be associated with other
   attributes types.

言語タグオプションがディレクトリ情報Tree(DIT)SHOULDにある状態で保存が属性であるとサポートするサーバで、ディレクトリString、IA5 String、または他の原文のストリング構文を持っているそれが見分けるどんな属性タイプもそれに関連している言語タグオプションを持つことができます。 サーバは、言語オプションが他の属性タイプに関連しているのを許容するかもしれません。

   Clients SHOULD NOT assume servers are capable of storing attributes
   with language tags in the directory.

クライアントSHOULD NOTは、言語タグがディレクトリにある状態でサーバが属性を保存できると仮定します。

   Implementations MUST NOT otherwise interpret the structure of the tag
   when comparing two tags, and MUST treat them simply as strings of
   characters.  Implementations MUST allow any arbitrary string which
   conforms to the syntax defined in BCP 47 [RFC3066] to be used as a
   language tag.

実装は、そうでなければ、2個のタグを比較するときタグの構造を解釈してはいけなくて、単にキャラクタのストリングとしてそれらを扱わなければなりません。 実装は、BCP47[RFC3066]で定義された構文に一致しているどんな任意のストリングも言語タグとして使用されるのを許容しなければなりません。

2.1.  Language Tag Options

2.1. 言語タグオプション

   A language tag option associates a natural language with values of an
   attribute.  An attribute description may contain multiple language
   tag options.  An entry may contain multiple attributes with same
   attribute type but different combinations of language tag (and other)
   options.

言語タグオプションは属性の値に自然言語を関連づけます。 属性記述は複数の言語タグオプションを含むかもしれません。 エントリーは、同じ属性タイプがいる複数の属性を含んでいて、言語タグの、そして、(他)のオプションの異なった組み合わせを含むかもしれません。

   A language tag option conforms to the following ABNF [RFC2234]:

言語タグオプションは以下のABNF[RFC2234]に従います:

      language-tag-option = "lang-" Language-Tag

言語タグオプション="lang"Language-タグ

Zeilenga                    Standards Track                     [Page 3]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[3ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

   where the Language-Tag production is as defined in BCP 47 [RFC3066].
   This production and those it imports from [RFC2234] are provided here
   for convenience:

Language-タグ生産がBCP47[RFC3066]で定義されるようにあるところで。 便宜のために、それが[RFC2234]からインポートするこの生産とものをここに提供します:

      Language-Tag = Primary-subtag *( "-" Subtag )

言語タグ=プライマリsubtag*(「-」Subtag)

      Primary-subtag = 1*8ALPHA

プライマリsubtagは1*8ALPHAと等しいです。

      Subtag = 1*8(ALPHA / DIGIT)

Subtag=1*8(アルファー/ケタ)

      ALPHA = %x41-5A / %x61-7A   ; A-Z / a-z

アルファー=%x41-5A/%x61-7A。 a A-Z/z

      DIGIT = %x30-39             ; 0-9

ケタ=%x30-39。 0-9

   A language tag option is a tagging option.  A language tag option has
   no effect on the syntax of the attribute's values nor their transfer
   encoding.

言語タグオプションはタグ付けオプションです。 言語タグオプションは属性の値の構文で効き目がありません。または、それらの転送コード化。

   Examples of valid AttributeDescription:

有効なAttributeDescriptionに関する例:

      givenName;lang-en-US
      CN;lang-ja
      SN;lang-de;lang-gem-PFL
      O;lang-i-klingon;x-foobar
      description;x-foobar
      CN

givenName; アンUS CNをlangしています;のlang-ja SN; lang-de; lang宝石PFL O; lang-i-klingon; x-foobar記述; x-foobar CN

   Notes: The last two have no language tag options.  The x-foobar
          option is fictious and used for example purposes.

注意: 最後の2には、言語タグオプションが全くありません。 x-foobarオプションは、fictiousであり、例えば目的を使用しました。

2.2.  Search Filter

2.2. 検索フィルタ

   If language tag options are present in an AttributeDescription in an
   assertion, then for each entry within scope, the values of each
   attribute whose AttributeDescription consists of the same attribute
   type or its subtypes and contains each of the presented (and possibly
   other) options is to be matched.

言語タグオプションが主張におけるAttributeDescriptionに存在しているなら、範囲の中の各エントリーにおいて、AttributeDescriptionが同じ属性タイプかその血液型亜型から成って、それぞれの提示されて(ことによると他)のオプションを含むそれぞれの属性の値は取り組むことです。

   Thus, for example, a filter of an equality match of type
   "name;lang-en-US" and assertion value "Billy Ray", against the
   following directory entry:

その結果、例えば、タイプの平等マッチのフィルタ以下のディレクトリエントリに対する「米国であることでアンをlangしている名前」と主張値の「ビリーRay」:

   dn: SN=Ray,DC=example,DC=com
   objectClass: person                 DOES NOT MATCH (wrong type)
   objectClass: extensibleObject       DOES NOT MATCH (wrong type)
   name;lang-en-US: Billy Ray          MATCHES
   name;lang-en-US: Billy Bob          DOES NOT MATCH (wrong value)
   CN;lang-en-US: Billy Ray            MATCHES

dn: SNはレイと等しく、DCは例と等しく、DCはcom objectClassと等しいです: 人のDOES NOT MATCH(間違ったタイプ)objectClass: 米国であることでアンをlangしているextensibleObject DOES NOT MATCH(間違ったタイプ)名: ビリー・レイは米国であることでアンをlangしている名前に合っています: 米国であることでアンをlangしているビリーボブDOES NOT MATCH(間違った値)CN: ビリーレイMATCHES

Zeilenga                    Standards Track                     [Page 4]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[4ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

   CN;lang-en-US;x-foobar: Billy Ray   MATCHES
   CN;lang-en;x-foobar: Billy Ray      DOES NOT MATCH (differing lang-)
   CN;x-foobar: Billy Ray              DOES NOT MATCH (no lang-)
   name: Billy Ray                     DOES NOT MATCH (no lang-)
   SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
   SN: Ray                             DOES NOT MATCH (no lang-,
                                           wrong value)

米国であることでアンをlangしているCN、x-foobar: ビリー・レイはCN; lang-アン; x-foobarに合っています: ビリーレイDOES NOT MATCH(異なったlang)CN;、x-foobar: ビリーレイDOES NOT MATCH(langがない)は以下を命名します。 ビリーレイDOES NOT MATCH(langがない)SN; 米国であることでアンをlangしているlangアンGB: ビリー・レイはSNに合っています: レイは合っていません。(langがない、間違った値)

   Note that "CN" and "SN" are subtypes of "name".

"CN"と"SN"が「名前」の血液型亜型であることに注意してください。

   It is noted that providing a language tag option in a search filter
   AttributeDescription will filter out desirable values where the tag
   does not match exactly.  For example, the filter (name;lang-en=Billy
   Ray) does NOT match the attribute "name;lang-en-US:  Billy Ray".

検索フィルタAttributeDescriptionの言語タグオプションを提供するとタグがまさに合っていない望ましい値がだんだん知られることに注意されます。 例えば、フィルタ(名前; ビリー・lang-アン=レイ)が属性に合っていない、「米国であることでアンをlangしている名前:、」 「ビリー・レイ。」

   If the server does not support storing attributes with language tag
   options in the DIT, then any assertion which includes a language tag
   option will not match as such it is an unrecognized attribute type.
   No error would be returned because of this; a presence assertion
   would evaluate to FALSE and all other assertions to Undefined.

言語タグオプションがDITにある状態でサーバが、保存が属性であるとサポートしないなら、どれが言語タグオプションを含んでいるかがそういうものとしてそれに合わないというどんな主張も認識されていない属性タイプです。 誤りは全くこれのために返されないでしょう。 主張がFALSEに評価する存在とUndefinedへの他のすべての主張。

   If no options are specified in the assertion, then only the base
   attribute type and the assertion value need match the value in the
   directory.

オプションが全く主張で指定されないなら、ベース属性タイプと主張値だけがディレクトリの値に合わなければなりません。

   Thus, for example, a filter of an equality match of type "name" and
   assertion value "Billy Ray", against the following directory entry:

その結果、例えば、タイプ「名前」と主張価値の平等マッチ以下のディレクトリエントリに対する「ビリー・レイ」のフィルタ:

      dn: SN=Ray,DC=example,DC=com
      objectClass: person                 DOES NOT MATCH (wrong type)
      objectClass: extensibleObject       DOES NOT MATCH (wrong type)
      name;lang-en-US: Billy Ray          MATCHES
      name;lang-en-US: Billy Bob          DOES NOT MATCH (wrong value)
      CN;lang-en-US;x-foobar: Billy Ray   MATCHES
      CN;lang-en;x-foobar: Billy Ray      MATCHES
      CN;x-foobar: Billy Ray              MATCHES
      name: Billy Ray                     MATCHES
      SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
      SN: Ray                             DOES NOT MATCH (wrong value)

dn: SNはレイと等しく、DCは例と等しく、DCはcom objectClassと等しいです: 人のDOES NOT MATCH(間違ったタイプ)objectClass: 米国であることでアンをlangしているextensibleObject DOES NOT MATCH(間違ったタイプ)名: ビリー・レイは米国であることでアンをlangしている名前に合っています: 米国であることでアンをlangしているビリーボブDOES NOT MATCH(間違った値)CN、x-foobar: ビリー・レイはCN; lang-アン; x-foobarに合っています: ビリー・レイはCNに合っています;、x-foobar: ビリーレイMATCHESは以下を命名します。 ビリー・レイは米国であることでアンをlangしていた状態でSN(langアンGB)に合っています: ビリー・レイはSNに合っています: レイは合っていません。(間違った値)

2.3.  Requested Attributes in Search

2.3. 検索における要求された属性

   Clients can provide language tag options in each AttributeDescription
   in the requested attribute list in a search request.

クライアントは検索要求における要求された属性リストの各AttributeDescriptionの言語タグオプションを提供できます。

   If language tag options are provided in an attribute description,
   then only attributes in a directory entry whose attribute
   descriptions have the same attribute type or its subtype and contains

言語であるならタグオプションを属性記述に提供して、その時が属性記述には同じ属性タイプかその「副-タイプ」があるディレクトリエントリの属性にすぎない、含有

Zeilenga                    Standards Track                     [Page 5]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[5ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

   each of the presented (and possibly other) language tag options are
   to be returned.  Thus if a client requests just the attribute
   "name;lang-en", the server would return "name;lang-en" and
   "CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr".

それぞれの提示されて(ことによると他)の言語タグオプションは返すことです。 または、したがって、クライアントがまさしく属性を要求するならサーバが、「lang名前;アン」と「lang名前;アン」を返すだろう、"SN"ではなく「CN; lang-アン; lang-ja」、「名前;、lang-fr、」

   Clients can provide in the attribute list multiple
   AttributeDescriptions which have the same base attribute type but
   different options.  For example, a client could provide both
   "name;lang-en" and "name;lang-fr", and this would permit an attribute
   with either language tag option to be returned.  Note there would be
   no need to provide both "name" and "name;lang-en" since all subtypes
   of name would match "name".

クライアントは、同じベース属性タイプがいる複数のAttributeDescriptionsを提供して、異なったオプションを属性リストに提供できます。 そして、例えば、クライアントが「lang名前;アン」を両方に提供できた、「名前; 」 これが、言語タグオプションがある属性が返されることを許可するlang-fr。 名前のすべての血液型亜型が「名前」に合っているでしょう、したがって、「名前」と「lang名前;アン」の両方を提供する必要は全くないことに注意してください。

   If a server does not support storing attributes with language tag
   options in the DIT, then any attribute descriptions in the list which
   include language tag options are to be ignored, just as if they were
   unknown attribute types.

言語タグオプションがDITにある状態でサーバが、保存が属性であるとサポートしないなら、リストにおける言語タグオプションを含んでいるどんな属性記述も無視されることです、まるでまさしく彼らが未知の属性タイプであるかのように。

   If a request is made specifying all attributes or an attribute is
   requested without providing a language tag option, then all attribute
   values regardless of their language tag option are returned.

すべての属性を指定しながら要求をするか、または言語タグオプションを提供しないで属性を要求するなら、彼らの言語タグオプションにかかわらずすべての属性値を返します。

   For example, if the client requests a "description" attribute, and a
   matching entry contains the following attributes:

例えばクライアントが「記述」属性を要求して、合っているエントリーが以下の属性を含んでいるなら:

      objectClass: top
      objectClass: organization
      O: Software GmbH
      description: software products
      description;lang-en: software products
      description;lang-de: Softwareprodukte

objectClass: 最高objectClass: 組織O: ソフトウェアGmbH記述: ソフトウェア・プロダクト記述; langアン: ソフトウェア・プロダクト記述;、lang-de: Softwareprodukte

   The server would return:

サーバは戻るでしょう:

      description: software products
      description;lang-en: software products
      description;lang-de: Softwareprodukte

記述: ソフトウェア・プロダクト記述; langアン: ソフトウェア・プロダクト記述;、lang-de: Softwareprodukte

2.4.  Compare

2.4. 比較してください。

   Language tag options can be present in an AttributeDescription used
   in a compare request AttributeValueAssertion.  This is to be treated
   by servers the same as the use of language tag options in a search
   filter with an equality match, as described in Section 2.2.  If there
   is no attribute in the entry with the same attribute type or its
   subtype and contains each of the presented (or possibly other)
   language tag options, the noSuchAttributeType error will be returned.

言語タグオプションはaで使用されるAttributeDescriptionでのプレゼントが要求AttributeValueAssertionを比較するということであるかもしれません。 これは平等マッチがある検索フィルタにおける言語タグオプションの使用としてサーバによって同じように扱われることになっています、セクション2.2で説明されるように。 あれば、同じくらいがあるエントリーにおけるどんな属性も、タイプかその「副-タイプ」を結果と考えて、それぞれの提示されて(ことによると他)の言語タグオプション(誤りが返されるnoSuchAttributeType)を含んでいません。

Zeilenga                    Standards Track                     [Page 6]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[6ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

   Thus, for example, a compare request of type "name" and assertion
   value "Johann", against an entry containing the following attributes:

このようにして、例えば、aは以下の属性を含むエントリーに対して「ジョハン」というタイプ「名前」と主張価値の要求を比較します:

      objectClass: top
      objectClass: person
      givenName;lang-de-DE: Johann
      CN: Johann Sibelius
      SN: Sibelius

objectClass: 最高objectClass: 人のgivenName; lang反-DE: ジョハンCN: ジョハンシベリウスSN: シベリウス

   would cause the server to return compareTrue.

サーバがcompareTrueを返すことを引き起こすでしょう。

   However, if the client issued a compare request of type
   "name;lang-de" and assertion value "Johann" against the above entry,
   the request would fail with the noSuchAttributeType error.

しかしながら、クライアントがaを発行したならタイプの要求を比較してください、「名前;、lang-de、」 上のエントリーに対する主張価値の「ジョハン」、noSuchAttributeType誤りに応じて、要求は失敗するでしょう。

   If the server does not support storing attributes with language tag
   options in the DIT, then any comparison which includes a language tag
   option will always fail to locate an attribute, and
   noSuchAttributeType will be returned.

言語タグオプションがDITにある状態でサーバが、保存が属性であるとサポートしないと、言語タグオプションを含んでいるどんな比較もいつも属性の場所を見つけるというわけではないでしょう、そして、noSuchAttributeTypeを返すでしょう。

2.5.  Add Operation

2.5. 操作を加えてください。

   Clients can provide language options in AttributeDescription in
   attributes of a new entry to be created.

クライアントは、作成されるためにAttributeDescriptionの言語オプションを新しいエントリーの属性に提供できます。

   A client can provide multiple attributes with the same attribute type
   and value, so long as each attribute has a different set of language
   tag options.

クライアントは同じ属性タイプと値を複数の属性に提供できます、言語の異なったタグオプションが各属性にある限り。

   For example, the following is a valid request:

例えば、↓これは有効な要求です:

      dn: CN=John Smith,DC=example,DC=com
      objectClass: residentialPerson
      CN: John Smith
      CN;lang-en: John Smith
      SN: Smith
      SN;lang-en: Smith
      streetAddress: 1 University Street
      streetAddress;lang-en-US: 1 University Street
      streetAddress;lang-fr: 1 rue Universite
      houseIdentifier;lang-fr: 9e etage

dn: CNはジョン・スミスと等しく、DCは例と等しく、DCはcom objectClassと等しいです: residentialPerson CN: ジョンスミスCN; langアン: ジョンスミスSN: スミスSN; langアン: スミスstreetAddress: 1 米国であることでアンをlangしている大学通りstreetAddress: 1 大学通りstreetAddress; lang-fr、: 1 悔悟Universite houseIdentifier; lang-fr、: 9e etage

   If a server does not support storing language tag options with
   attribute values in the DIT, then it MUST treat an
   AttributeDescription with a language tag option as an unrecognized
   attribute.  If the server forbids the addition of unrecognized
   attributes then it MUST fail the add request with an appropriate
   result code.

属性値がDITにある状態でサーバが、保存が言語タグオプションであるとサポートしないなら、それは認識されていない属性として言語タグオプションでAttributeDescriptionを扱わなければなりません。 サーバが認識されていない属性の追加を禁じるなら失敗しなければならない、適切な結果コードで要求を加えてください。

Zeilenga                    Standards Track                     [Page 7]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[7ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

2.6.  Modify Operation

2.6. 操作を変更してください。

   A client can provide language tag options in an AttributeDescription
   as part of a modification element in the modify operation.

クライアントが変更要素の一部としてAttributeDescriptionの言語タグオプションを中に提供できる、操作を変更してください。

   Attribute types and language tag options MUST match exactly against
   values stored in the directory.  For example, if the modification is
   a "delete", then if the stored values to be deleted have language tag
   options, then those language tag options MUST be provided in the
   modify operation, and if the stored values to be deleted do not have
   any language tag option, then no language tag option is to be
   provided.

属性タイプと言語タグオプションはちょうどディレクトリに保存された値を比較しなければなりません。 例えば、変更が「削除」であるなら削除されるべき保存された値に言語タグオプションがあるならそれらの言語タグオプションを中に提供しなければならない、削除されるべき保存された値に言語タグオプション(言語タグオプションを全く提供してはいけないその時)が少しのないなら、操作を変更してください。

   If the server does not support storing language tag options with
   attribute values in the DIT, then it MUST treat an
   AttributeDescription with a language tag option as an unrecognized
   attribute, and MUST fail the request with an appropriate result code.

属性値がDITにある状態でサーバが、保存が言語タグオプションであるとサポートしないなら、それは、認識されていない属性として言語タグオプションでAttributeDescriptionを扱わなければならなくて、適切な結果コードに応じて、要求に失敗しなければなりません。

3.  Use of Language Ranges in LDAP

3. 言語の使用はLDAPのねらいを定めます。

   Since the publication of RFC 2596, it has become apparent that there
   is a need to provide a mechanism for a client to request attributes
   based upon set of language tag options whose tags all begin with the
   same sequence of language sub-tags.

RFC2596の公表以来、クライアントがタグが同じである言語のサブタグである系列のですべて始まる言語タグオプションのセットに基づく属性を要求するようにメカニズムを提供する必要があるのは明らかになっています。

   AttributeDescriptions containing language range options are intended
   to be used in attribute value assertions, search attribute lists, and
   other places where the client desires to provide an attribute
   description matching of a range of language tags associated with
   attributes.

クライアントが属性に関連しているさまざまな言語タグの記述マッチングを属性に提供することを望んでいる属性値主張、検索属性リスト、および他の場所で言語範囲オプションを含むAttributeDescriptionsが使用されることを意図します。

   A language range option conforms to the following ABNF [RFC2234]:

言語範囲オプションは以下のABNF[RFC2234]に従います:

      language-range-option = "lang-" [ Language-Tag "-" ]

言語範囲オプションは"lang"と等しいです。[言語タグ「-」]

   where the Language-Tag production is as defined in BCP 47 [RFC3066].
   This production and those it imports from [RFC2234] are provided in
   Section 2.1 for convenience.

Language-タグ生産がBCP47[RFC3066]で定義されるようにあるところで。 便宜のために、それが[RFC2234]からインポートするこの生産とものをセクション2.1に提供します。

   A language range option matches a language tag option if the language
   range option less the trailing "-" matches exactly the language tag
   or if the language range option (including the trailing "-") matches
   a prefix of the language tag option.  Note that the language range
   option "lang-" matches all language tag options.

言語範囲がそれほど引きずっている「-」マッチにちょうど言語タグをゆだねないか、または言語範囲オプション(引きずっている「-」を含んでいる)が言語タグオプションの接頭語に合っているなら、言語範囲オプションは言語タグオプションに合っています。 言語範囲オプション"lang"がすべての言語タグオプションに合っていることに注意してください。

Zeilenga                    Standards Track                     [Page 8]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[8ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

   Examples of valid AttributeDescription containing language range
   options:

言語範囲オプションを含む有効なAttributeDescriptionに関する例:

      givenName;lang-en-
      CN;lang-
      SN;lang-de-;lang-gem-
      O;lang-x-;x-foobar

givenNameに、lang-アンCN; lang- SN;がlangする、-、反-、; lang O(lang-x)に宝石をちりばめさせているx-foobar

   A language range option is not a tagging option.  Attributes cannot
   be stored with language range options.  Any attempt to add or update
   an attribute description with a language range option SHALL be
   treated as an undefined attribute type and result in an error.

言語範囲オプションはタグ付けオプションではありません。 言語範囲オプションで属性を保存できません。 いずれも、属性記述を加えるか、または言語範囲オプションSHALLが誤りにおける未定義の属性タイプと結果として扱われた状態でアップデートするのを試みます。

   A language range option has no effect on the transfer encoding nor on
   the syntax of the attribute values.

言語範囲オプションは転送コード化の上と、そして、属性値の構文の上で効き目がありません。

   Servers SHOULD support assertion of language ranges for any attribute
   type which they allow to be stored with language tags.

言語のサーバSHOULDサポート主張はそれらが言語タグで保存されるのを許容するどんな属性タイプのためにも及びます。

3.1.  Search Filter

3.1. 検索フィルタ

   If a language range option is present in an AttributeDescription in
   an assertion, then for each entry within scope, the values of each
   attribute whose AttributeDescription consists of the same attribute
   type or its subtypes and contains a language tag option matching the
   language range option are to be returned.

言語範囲オプションが主張におけるAttributeDescriptionに存在しているなら、範囲の中の各エントリーにおいて、AttributeDescriptionが同じ属性タイプかその血液型亜型から成って、言語範囲オプションに合っている言語タグオプションを含むそれぞれの属性の値は返すことです。

   Thus, for example, a filter of an equality match of type
   "name;lang-en-" and assertion value "Billy Ray", against the
   following directory entry:

その結果、例えば、タイプの平等マッチのフィルタ、「lang名前;アン、-」 主張は「ビリー・レイ」を評価します、以下のディレクトリエントリに対して:

      dn: SN=Ray,DC=example,DC=com
      objectClass: person                 DOES NOT MATCH (wrong type)
      objectClass: extensibleObject       DOES NOT MATCH (wrong type)
      name;lang-en-US: Billy Ray          MATCHES
      name;lang-en-US: Billy Bob          DOES NOT MATCH (wrong value)
      CN;lang-en-US: Billy Ray            MATCHES
      CN;lang-en-US;x-foobar: Billy Ray   MATCHES
      CN;lang-en;x-foobar: Billy Ray      MATCHES
      CN;x-foobar: Billy Ray              DOES NOT MATCH (no lang-)
      name: Billy Ray                     DOES NOT MATCH (no lang-)
      SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
      SN: Ray                             DOES NOT MATCH (no lang-,
                                            wrong value)

dn: SNはレイと等しく、DCは例と等しく、DCはcom objectClassと等しいです: 人のDOES NOT MATCH(間違ったタイプ)objectClass: 米国であることでアンをlangしているextensibleObject DOES NOT MATCH(間違ったタイプ)名: ビリー・レイは米国であることでアンをlangしている名前に合っています: 米国であることでアンをlangしているビリーボブDOES NOT MATCH(間違った値)CN: ビリー・レイはCNに合っています; 米国であることでアンをlangしている、x-foobar: ビリー・レイはCN; lang-アン; x-foobarに合っています: ビリー・レイはCNに合っています;、x-foobar: ビリーレイDOES NOT MATCH(langがない)は以下を命名します。 ビリーレイDOES NOT MATCH(langがない)SN; 米国であることでアンをlangしているlangアンGB: ビリー・レイはSNに合っています: レイは合っていません。(langがない、間違った値)

   Note that "CN" and "SN" are subtypes of "name".

"CN"と"SN"が「名前」の血液型亜型であることに注意してください。

Zeilenga                    Standards Track                     [Page 9]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[9ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

   If the server does not support storing attributes with language tag
   options in the DIT, then any assertion which includes a language
   range option will not match as it is an unrecognized attribute type.
   No error would be returned because of this; a presence filter would
   evaluate to FALSE and all other assertions to Undefined.

言語タグオプションがDITにある状態でサーバが、保存が属性であるとサポートしないと、言語範囲オプションを含んでいる少しの主張も、それが認識されていない属性タイプであるので、合わないでしょう。 誤りは全くこれのために返されないでしょう。 存在フィルタはFALSEで他にUndefinedへの主張を評価するでしょう。

3.2.  Requested Attributes in Search

3.2. 検索における要求された属性

   Clients can provide language range options in each
   AttributeDescription in the requested attribute list in a search
   request.

クライアントは検索要求における要求された属性リストの各AttributeDescriptionの言語範囲オプションを提供できます。

   If a language range option is provided in an attribute description,
   then only attributes in a directory entry whose attribute
   descriptions have the same attribute type or its subtype and a
   language tag option matching the provided language range option are
   to be returned.  Thus if a client requests just the attribute
   "name;lang-en-", the server would return "name;lang-en-US" and
   "CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr".

言語範囲オプションを属性記述に提供するなら、属性記述には同じ属性タイプかその「副-タイプ」があるディレクトリエントリと提供された言語範囲オプションに合っている言語タグオプションにおける唯一の属性は返すことです。 または、その結果、クライアントがまさしく属性を要求するかどうか、「lang名前;アン、-、」、サーバが"SN"ではなく「米国であることでアンをlangしている名前」と「CN; lang-アン; lang-ja」を返すだろう、「名前;、lang-fr、」

   Clients can provide in the attribute list multiple
   AttributeDescriptions which have the same base attribute type but
   different options.  For example a client could provide both
   "name;lang-en-" and "name;lang-fr-", and this would permit an
   attribute whose type was name or subtype of name and with a language
   tag option matching either language range option to be returned.

クライアントは、同じベース属性タイプがいる複数のAttributeDescriptionsを提供して、異なったオプションを属性リストに提供できます。 例えば、クライアントが両方を提供できた、「lang名前;アン、-、」、「名前; lang-fr」 これは、タイプが名前であった属性か名前と言語タグオプションが言語範囲オプションに合っている「副-タイプ」が返されることを許可するでしょう。

   If a server does not support storing attributes with language tag
   options in the DIT, then any attribute descriptions in the list which
   include language range options are to be ignored, just as if they
   were unknown attribute types.

言語タグオプションがDITにある状態でサーバが、保存が属性であるとサポートしないなら、リストにおける言語範囲オプションを含んでいるどんな属性記述も無視されることです、まるでまさしく彼らが未知の属性タイプであるかのように。

3.3.  Compare

3.3. 比較してください。

   Language range options can be present in an AttributeDescription used
   in a compare request AttributeValueAssertion.  This is to be treated
   by servers the same as the use of language range options in a search
   filter with an equality match, as described in Section 3.1.  If there
   is no attribute in the entry with the same subtype and a matching
   language tag option, the noSuchAttributeType error will be returned.

言語範囲オプションはaで使用されるAttributeDescriptionでのプレゼントが要求AttributeValueAssertionを比較するということであるかもしれません。 これは平等マッチがある検索フィルタにおける言語範囲オプションの使用としてサーバによって同じように扱われることになっています、セクション3.1で説明されるように。 属性が全く同じ「副-タイプ」と合っている言語タグオプションと共にエントリーにないと、noSuchAttributeType誤りは返されるでしょう。

   Thus, for example, a compare request of type "name;lang-" and
   assertion value "Johann", against the entry with the following
   attributes:

このようにして、例えば、aは「名前; langし」て主張が以下の属性でエントリーに対して「ジョハン」を評価するというタイプの要求を比較します:

Zeilenga                    Standards Track                    [Page 10]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[10ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

      objectClass: top
      objectClass: person
      givenName;lang-de-DE: Johann
      CN: Johann Sibelius
      SN: Sibelius

objectClass: 最高objectClass: 人のgivenName; lang反-DE: ジョハンCN: ジョハンシベリウスSN: シベリウス

   will cause the server to return compareTrue.  (Note that the language
   range option "lang-" matches any language tag option.)

サーバがcompareTrueを返すことを引き起こすでしょう。 (言語範囲オプション"lang"がどんな言語タグオプションにも合っていることに注意してください。)

   However, if the client issued a compare request of type
   "name;lang-de" and assertion value "Sibelius" against the above
   entry, the request would fail with the noSuchAttributeType error.

しかしながら、クライアントがaを発行したならタイプの要求を比較してください、「名前;、lang-de、」 上のエントリーに対する主張価値の「シベリウス」、noSuchAttributeType誤りに応じて、要求は失敗するでしょう。

   If the server does not support storing attributes with language tag
   options in the DIT, then any comparison which includes a language
   range option will always fail to locate an attribute, and
   noSuchAttributeType will be returned.

言語タグオプションがDITにある状態でサーバが、保存が属性であるとサポートしないと、言語範囲オプションを含んでいるどんな比較もいつも属性の場所を見つけるというわけではないでしょう、そして、noSuchAttributeTypeを返すでしょう。

4.  Discovering Language Option Support

4. 言語オプションサポートを発見します。

   A server SHOULD indicate that it supports storing attributes with
   language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4
   as a value of the root DSE.

サーバSHOULDは、言語タグオプションがDITにある状態で出版1.3で保存が属性であるとサポートするのを示します。.6 .1 .4 .1 .4203 .1 .5 .4 根のDSEの値として。

   A server SHOULD indicate that it supports language range matching of
   attributes with language tag options stored in the DIT by publishing
   1.3.6.1.4.1.4203.1.5.5 as a value of the "supportedFeatures"
   [RFC3674] attribute in the root DSE.

サーバSHOULDは、言語が言語タグオプションがDITに出版1.3によって保存されている属性の範囲マッチングであるとサポートするのを示します。.6 .1 .4 .1 .4203 .1 .5 「supportedFeatures」[RFC3674]の値としての.5は根でDSEをみなします。

   A server MAY restrict use of language tag options to a subset of the
   attribute types it recognizes.  This document does not define a
   mechanism for determining which subset of attribute types can be used
   with language tag options.

サーバは言語タグオプションの使用をそれが見分ける属性タイプの部分集合に制限するかもしれません。 このドキュメントは、言語タグオプションと共に属性タイプのどの部分集合を使用できるかを決定するためにメカニズムを定義しません。

5.  Interoperability with Non-supporting Implementations

5. 非サポート実装がある相互運用性

   Implementators of this specification should take care that their use
   of language tag options does not impede proper function of
   implementations which do not support language tags.

この仕様のImplementatorsは、彼らの言語タグオプションの使用が言語がタグであるとサポートしない実装の適切な機能を妨害しないことに注意するはずです。

   Per RFC 2251, "an AttributeDescription with one or more options is
   treated as a subtype of the attribute type without any options."  A
   non-supporting server will treat an AttributeDescription with any
   language tag options as an unrecognized attribute type.  A non-
   supporting client will either do the same, or will treat the
   AttributeDescription as it would any other unknown subtype.
   Typically, non-supporting clients simply ignore unrecognized subtypes
   (and unrecognized attribute types) of attributes they request.

RFC2251あたり、「1つ以上のオプションがあるAttributeDescriptionは少しもオプションなしで属性タイプの「副-タイプ」として扱われます」。 非サポートサーバは認識されていない属性タイプとしてどんな言語タグオプションでもAttributeDescriptionを扱うでしょう。 いかなる他の未知の「副-タイプ」も扱うように、非サポートしているクライアントは、同じようにするか、またはAttributeDescriptionを扱うでしょう。 通常、非サポートしているクライアントは単に、それらが要求する属性の認識されていない血液型亜型(そして、認識されていない属性タイプ)を無視します。

Zeilenga                    Standards Track                    [Page 11]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[11ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

   To ensure proper function of non-supporting clients, supporting
   clients SHOULD ensure that entries they populate with tagged values
   are also populated with non-tagged values.

クライアントがSHOULDであるとサポートする非サポートしているクライアントの適切な機能を確実にするには、また、それらがタグ付けをされた値で居住するエントリーが非タグ付けをされた値で居住されるのを確実にしてください。

   Additionally, supporting clients SHOULD be prepared to handle entries
   which are not populated with tagged values.

クライアントがSHOULDであるとサポートして、さらに、タグ付けをされた値で居住されないエントリーを扱うように用意してください。

6.  Security Considerations

6. セキュリティ問題

   Language tags and range options are used solely to indicate the
   native language of values and in querying the directory for values
   which fulfill the user's language needed.  These options are not
   known to raise specific security considerations.  However, the reader
   should consider general directory security issues detailed in the
   LDAP technical specification [RFC3377].

言語タグと範囲オプションが、唯一値の母国語を示すのに使用されて、ユーザの言語を実現させる値のためのディレクトリについて質問するのにおいて必要です。 これらのオプションが特定のセキュリティ問題を提起するのが知られません。 しかしながら、読者は、一般的なディレクトリ安全保障問題がLDAP技術仕様書[RFC3377]で詳細であると考えるべきです。

7.  IANA Considerations

7. IANA問題

   Registration of these protocol mechanisms [RFC3383] has been
   completed by the IANA.

これらのプロトコルメカニズム[RFC3383]の登録はIANAによって終了しました。

   Subject: Request for LDAP Protocol Mechanism Registration
   Object Identifier: 1.3.6.1.4.1.4203.1.5.4
   Description: Language Tag Options
   Object Identifier: 1.3.6.1.4.1.4203.1.5.5
   Description: Language Range Options
   Person & email address to contact for further information:
        Kurt Zeilenga <kurt@openldap.org>
   Usage: Feature
   Specification: RFC 3866
   Author/Change Controller: IESG
   Comments: none

Subject: LDAPプロトコルメカニズム登録オブジェクト識別子のために以下を要求してください。 1.3.6.1.4.1.4203.1.5.4 記述: 言語タグオプションオブジェクト識別子: 1.3.6.1.4.1.4203.1.5.5 記述: 詳細のために連絡する言語Range Options PersonとEメールアドレス: カート Zeilenga <kurt@openldap.org 、gt;、用法: 仕様を特徴としてください: RFC3866作者/変化コントローラ: IESGはコメントします: なし

   These OIDs were assigned [ASSIGN] by OpenLDAP Foundation, under its
   IANA-assigned private enterprise allocation [PRIVATE], for use in
   this specification.

[ASSIGN]はOpenLDAP財団によってこれらのOIDsにこの仕様に基づく使用のためのIANAによって割り当てられた私企業配分[兵士]で割り当てられました。

8.  Acknowledgments

8. 承認

   This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
   RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
   This document also borrows from a number of IETF documents including
   BCP 47 by H. Alvestrand.

このドキュメントはマーク・ウォールとティム・ハウズによるRFC2596の改正です。 RFC2596はIETF ASIDとLDAPEXTワーキンググループの製品でした。 また、このドキュメントはH.AlvestrandでBCP47を含む多くのIETFドキュメントから借ります。

Zeilenga                    Standards Track                    [Page 12]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[12ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [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月。

   [RFC2234]     Crocker, D., Ed. and P. Overell, "Augmented BNF for
                 Syntax Specifications: ABNF", RFC 2234, November 1997.

エド[RFC2234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

   [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月。

   [RFC3066]     Alvestrand, H., "Tags for the Identification of
                 Languages", BCP 47, RFC 3066, January 2001.

[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。

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

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

   [RFC3674]     Zeilenga, K., "Feature Discovery in Lightweight
                 Directory Access Protocol (LDAP)", RFC 3674, December
                 2003.

[RFC3674]Zeilenga、2003年12月のK.、「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)の特徴ディスカバリー」RFC3674。

   [ASCII]       Coded Character Set--7-bit American Standard Code for
                 Information Interchange, ANSI X3.4-1986.

[ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。

9.2.  Informative References

9.2. 有益な参照

   [X.501]       International Telecommunication Union -
                 Telecommunication Standardization Sector, "The
                 Directory -- Models," X.501(1997).

[X.501]国際電気通信連合--電気通信標準化セクター、「ディレクトリ--、モデル、」、X.501(1997)。

   [RFC3383]     Zeilenga, K., "Internet Assigned Numbers Authority
                 (IANA) Considerations for Lightweight Directory Access
                 Protocol (LDAP)", BCP 64, RFC 3383, September 2002.

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

   [ASSIGN]      OpenLDAP Foundation, "OpenLDAP OID Delegations",
                 http://www.openldap.org/foundation/oid-delegate.txt.

[割り当てます] OpenLDAP財団、「OpenLDAP OID委譲」、 http://www.openldap.org/foundation/oid-delegate.txt 。

   [PRIVATE]     IANA, "Private Enterprise Numbers",
                 http://www.iana.org/assignments/enterprise-numbers.

[個人的]のIANA、「私企業番号」、 http://www.iana.org/assignments/enterprise-numbers 。

Zeilenga                    Standards Track                    [Page 13]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[13ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

Appendix A. Differences from RFC 2596

RFC2596からの付録A.差

   This document adds support for language ranges, provides a mechanism
   that a client can use to discover whether a server supports language
   tags and ranges, and clarifies how attributes with multiple language
   tags are to be treated.  This document is a significant rewrite of
   RFC 2596.

このドキュメントは、言語のサポートが及ぶと言い足して、クライアントがサーバが言語がタグであることをサポートして、及ぶかどうか発見するのに使用できるメカニズムを前提として、扱われる複数の言語タグがある属性がことである方法をはっきりさせます。 このドキュメントはRFC2596の重要な書き直しです。

Appendix B. Differences from X.500(1997)

X.500からの付録B.差(1997)

   X.500(1997) [X.501] defines a different mechanism, contexts, as the
   means of representing language tags (codes).  This section summarizes
   the major differences in approach.

X.500(1997)[X.501]は言語を表す手段が(コード)にタグ付けをすると異なったメカニズム、文脈を定義します。 このセクションはアプローチの主要な違いをまとめます。

   a) An X.500 operation which has specified a language code on a value
      matches a value in the directory without a language code.

a) 値の言語コードを指定したX.500操作は言語コードなしでディレクトリの値に合っています。

   b) LDAP references BCP 47 [RFC3066], which allows for IANA
      registration of new tags as well as unregistered tags.

b) LDAP参照BCP47[RFC3066。](その]は登録されていないタグと同様に新しいタグのIANA登録を考慮します)。

   c) LDAP supports language ranges (new in this revision).

c) LDAPは、言語が範囲(この改正で新しい)であるとサポートします。

   d) LDAP does not allow language tags (and ranges) in distinguished
      names.

d) LDAPは分類名で言語タグ(そして、及ぶ)を許容しません。

   e) X.500 describes subschema administration procedures to allow
      language codes to be associated with particular attributes types.

e) X.500は、言語コードが特定の属性タイプに関連しているのを許容するためにサブスキーマ管理手順について説明します。

Editor's Address

エディタのアドレス

   Kurt D. Zeilenga
   OpenLDAP Foundation

カートD.Zeilenga OpenLDAP財団

   EMail: Kurt@OpenLDAP.org

メール: Kurt@OpenLDAP.org

Zeilenga                    Standards Track                    [Page 14]

RFC 3866            Language Tags and Ranges in LDAP           July 2004

Zeilenga標準化過程[14ページ]RFC3866言語は、2004年7月にLDAPにタグ付けをして、ねらいを定めます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2004).  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.

Copyright(C)インターネット協会(2004)。 このドキュメントは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 currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Zeilenga                    Standards Track                    [Page 15]

Zeilenga標準化過程[15ページ]