RFC2596 日本語訳

Network Working Group                                            M. Wahl
Request for Comments: 2596                  Innosoft International, Inc.
Category: Standards Track                                       T. Howes
                                           Netscape Communications Corp.
                                                                May 1999

コメントを求めるワーキンググループM.ウォール要求をネットワークでつないでください: 2596年のInnosoftの国際Inc.カテゴリ: 標準化過程T.ハウズネットスケープ・コミュニケーションズ1999年5月

                     Use of Language Codes in 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 (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

1. Abstract

1. 要約

   The Lightweight Directory Access Protocol [1] 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 [2] 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.

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

   This document describes how language codes [3] are carried in LDAP
   and are to be interpreted by LDAP servers.  All implementations MUST
   be prepared to accept language codes in the LDAP protocols.  Servers
   may or may not be capable of storing attributes with language codes
   in the directory.  This document does not specify how to determine
   whether particular attributes can or cannot have language codes.

このドキュメントは、言語コード[3]がどのように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 RFC 2119 [4].

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

2. Language Codes

2. 言語コード

   Section 2 of RFC 1766 [3] describes the language code format which is
   used in LDAP.  Briefly, it is a string of ASCII alphabetic characters
   and hyphens.  Examples include "fr", "en-US" and "ja-JP".

RFC1766[3]のセクション2はLDAPで使用される言語コード形式について説明します。 簡潔に、それは、一連のASCII英字とハイフンです。 例は"fr"、「アン米国」、および「ja-JP」を含んでいます。

Wahl & Howes                Standards Track                     [Page 1]

RFC 2596             Use of Language Codes in LDAP              May 1999

ウォールとハウズStandardsは1999年5月にLDAPにおける言語コードのRFC2596使用を追跡します[1ページ]。

   Language codes are case insensitive.  For example, the language code
   "en-us" is the same as "EN-US" and "en-US".

言語コードは大文字と小文字を区別しないです。 例えば、言語コード、「アン、-、私たち、」 「アン米国」と「アン米国」と同じくらいはそうですか?

   Implementations MUST NOT otherwise interpret the structure of the
   code when comparing two codes, and MUST treat them as simply strings
   of characters. Client and server implementations MUST allow any
   arbitrary string which follows the patterns given in RFC 1766 to be
   used as a language code.

実装は、そうでなければ、比較2つのコードであるときにコードの構造を解釈してはいけなくて、同じくらい単にそれらを扱わなければなりません。キャラクタのストリング。 クライアントとサーバ実装は、RFC1766で与えられたパターンに従うどんな任意のストリングも言語コードとして使用されるのを許容しなければなりません。

3. Use of Language Codes in LDAP

3. LDAPにおける言語コードの使用

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

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

   In general, an attribute with a language code is to be treated as a
   subtype of the attribute without a language code.  If a server does
   not support storing language codes with attribute values in the DIT,
   then it MUST always treat an attribute with a language code as an
   unrecognized attribute.

一般に、言語コードがある属性は言語コードなしで属性の「副-タイプ」として扱われることです。 属性値がDITにある状態でサーバが、保存が言語コードであるとサポートしないなら、それはいつも言語コードがある属性を認識されていない属性として扱わなければなりません。

3.1. Attribute Description

3.1. 属性記述

   An attribute consists of a type, a list of options for that type, and
   a set of one or more values.  In LDAP, the type and the options are
   combined into the AttributeDescription, defined in section 4.1.5 of
   [1]. This is represented as an attribute type name and a possibly-
   empty list of options.  One of these options associates a natural
   language with values for that attribute.

属性はタイプ、そのタイプのためのオプションのリスト、および1つ以上の値のセットから成ります。 LDAPでは、タイプとオプションは[1]についてセクション4.1.5で定義されたAttributeDescriptionに結合されます。 これはオプションの属性タイプ名とことによると空のリストとして表されます。 これらのオプションの1つはその属性のために自然言語を値に関連づけます。

        language-option = "lang-" lang-code

言語オプションは"lang"lang-コードと等しいです。

        lang-code = printable-ascii ; a code as defined in RFC 1766

lang-コードは印刷可能なASCIIと等しいです。 RFC1766で定義されるコード

   Multiple language options may be present on a particular value.

複数の言語オプションが特定の値に存在しているかもしれません。

   The language code has no effect on the character set encoding for
   string representations of DirectoryString syntax values; the UTF-8
   representation of UniversalString (ISO 10646) is always used.

言語コードはストリングのためにDirectoryString構文値の表現をコード化しながら、文字集合で効き目がありません。 UniversalString(ISO10646)のUTF-8表現はいつも使用されます。

   Examples of valid AttributeDescription:
        givenName;lang-en-US
        CN;lang-ja

有効なAttributeDescriptionに関する例: givenName; 米国であることでアンをlangしているCN; lang-ja

   In LDAP and in examples in this document, a directory attribute is
   represented as an AttributeDescription with a list of values.  Note
   that the data could be stored in the LDAP server in a different
   representation.

LDAPとこのドキュメントの例では、ディレクトリ属性はAttributeDescriptionとして値のリストで表されます。 異なった表現におけるLDAPサーバでデータを保存できたことに注意してください。

Wahl & Howes                Standards Track                     [Page 2]

RFC 2596             Use of Language Codes in LDAP              May 1999

ウォールとハウズStandardsは1999年5月にLDAPにおける言語コードのRFC2596使用を追跡します[2ページ]。

3.2. Distinguished Names and Relative Distinguished Names

3.2. 分類名と相対的な分類名

   No attribute description options are permitted in Distinguished Names
   or Relative Distinguished Names.  Thus language codes MUST NOT be
   used in forming DNs.

属性記述オプションは全くDistinguished NamesかRelative Distinguished Namesで受入れられません。 したがって、DNsを形成する際に言語コードを使用してはいけません。

3.3. Search Filter

3.3. 検索フィルタ

   If a language code is present in an AttributeDescription in a search
   filter, then only attribute values in the directory which match the
   base attribute type or its subtype, the language code and the
   assertion value match this filter.

言語コードが検索フィルタの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アン米国」の平等マッチのフィルタと主張は「ビリー・レイ」を評価します、以下のディレクトリエントリに対して

   objectclass: top                     DOES NOT MATCH (wrong type)
   objectclass: person                  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;dynamic: Billy Ray     MATCHES
   CN;lang-en;dynamic: Billy Ray        DOES NOT MATCH (differing lang-)
   name: Billy Ray                      DOES NOT MATCH (no lang-)
   SN: Ray                              DOES NOT MATCH (wrong value)

objectclass: 最高DOES NOT MATCH(間違ったタイプ)objectclass: DOES NOT MATCH(間違ったタイプ)が命名する人;、lang-EN-米国: マッチが命名するビリーRay; lang EN米国: ビリーボブDOES NOT MATCH(間違った値)CN;、langアン、私たち、: ビリー・レイはCN; lang EN米国; 動力に合っています: ビリー・レイはCN; lang-アン; 動力に合っています: ビリーレイDOES NOT MATCH(異なったlang)は以下を命名します。 ビリーレイDOES NOT MATCH(langがない)SN: レイは合っていません。(間違った値)

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

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

   Client implementors should however note that providing a language
   code in a search filter AttributeDescription will often filter out
   desirable values where the language code 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 language codes with attribute
   values in the DIT, then any filter which includes a language code
   will always fail to 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 forms to Undefined.

属性値がDITにある状態でサーバが、保存が言語コードであるとサポートしないと、言語コードを含んでいるどんなフィルタもいつも合うというわけではないでしょう、それが認識されていない属性タイプであるので。 誤りは全くこれのために返されないでしょう。 存在フィルタはFALSEで他にUndefinedへのフォームを評価するでしょう。

   If no language code is specified in the search filter, 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

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

Wahl & Howes                Standards Track                     [Page 3]

RFC 2596             Use of Language Codes in LDAP              May 1999

ウォールとハウズStandardsは1999年5月にLDAPにおける言語コードのRFC2596使用を追跡します[3ページ]。

   objectclass: top                     DOES NOT MATCH (wrong type)
   objectclass: person                  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;dynamic: Billy Ray     MATCHES
   CN;lang-en;dynamic: Billy Ray        MATCHES
   name: Billy Ray                      MATCHES
   SN: Ray                              DOES NOT MATCH (wrong value)

objectclass: 最高DOES NOT MATCH(間違ったタイプ)objectclass: DOES NOT MATCH(間違ったタイプ)が命名する人;、lang-EN-米国: マッチが命名するビリーRay; lang EN米国: ビリーボブDOES NOT MATCH(間違った値)CN; lang-EN-米国; 動力: ビリー・レイはCN; lang-アン; 動力に合っています: ビリーレイMATCHESは以下を命名します。 ビリー・レイはSNに合っています: レイは合っていません。(間違った値)

   Thus in general, clients SHOULD NOT use the language code option in
   AttributeDescription fields in search filters.

したがって、一般に、クライアントSHOULD NOTは検索フィルタのAttributeDescription分野で言語コードオプションを使用します。

3.4. Compare

3.4. 比較してください。

   A language code 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 codes in a search filter with
   an equality match, as described in the previous section.  If there is
   no attribute in the entry with the same subtype and language code,
   the noSuchAttributeType error will be returned.

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

   Thus for example a compare request of type "name" and assertion value
   "Johann", against an entry with all the following directory entry

したがって、例えば、aは「ジョハン」というタイプ「名前」と主張価値の要求を比較します、以下のすべてのディレクトリエントリがあるエントリーに対して

   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.

サーバが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 language codes with attribute
   values in the DIT, then any comparison which includes a language code
   will always fail to locate an attribute type, and noSuchAttributeType
   will be returned.

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

   Thus in general, clients SHOULD NOT use the language code option in
   AttributeDescription fields in the compare request.

その結果、一般に、クライアントSHOULD NOTが中でAttributeDescription分野で言語コードオプションを使用する、要求を比較してください。

3.5. Requested Attributes in Search

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

   Clients MAY provide language codes in AttributeDescription in the
   requested attribute list in a search request.

クライアントは検索要求における要求された属性リストにAttributeDescriptionの言語コードを提供するかもしれません。

Wahl & Howes                Standards Track                     [Page 4]

RFC 2596             Use of Language Codes in LDAP              May 1999

ウォールとハウズStandardsは1999年5月にLDAPにおける言語コードのRFC2596使用を追跡します[4ページ]。

   If a language code is provided in an attribute description, then only
   attribute values in a directory entry which have the same language
   code as that provided are to be returned. Thus if a client requests
   an attribute "description;lang-en", the server MUST NOT return values
   of an attribute "description" or "description;lang-fr".

言語コードを属性記述に提供するなら、ディレクトリエントリの同じ言語コードを持っている唯一の属性値はそれが提供されたので返すことです。 または、したがって、クライアントが属性を要求するならサーバが、「lang記述;アン」と属性「記述」の値を返してはいけない、「記述;、lang-fr、」

   Clients MAY provide in the attribute list multiple
   AttributeDescription which have the same base attribute type but
   different options. For example a client MAY provide both "name;lang-
   en" and "name;lang-fr", and this would permit an attribute with
   either language code 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".

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

   If a server does not support storing language codes with attribute
   values in the DIT, then any attribute descriptions in the list which
   include language codes 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 code, then all attribute
   values regardless of their language code are returned.

すべての属性を指定しながら要求をするか、または言語コードを提供しないで属性を要求するなら、それらの言語コードにかかわらずすべての属性値を返します。

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

クライアントは「記述」属性を要求するかどうか、そして、例えばエントリーが含むマッチング

   objectclass: top
   objectclass: organization
   O: Software GmbH
   description: software
   description;lang-en: software products
   description;lang-de: Softwareprodukte
   postalAddress: Berlin 8001 Germany
   postalAddress;lang-de: Berlin 8001 Deutschland

objectclass: 最高objectclass: 組織O: ソフトウェアGmbH記述: langソフトウェア記述;アン: ソフトウェア・プロダクト記述;、lang-de: Softwareprodukte postalAddress: ベルリン8001ドイツpostalAddress;、lang-de: ベルリン8001ドイッチェランド

   The server will return:

サーバは戻るでしょう:

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

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

3.6. Add Operation

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

   Clients MAY provide language codes in AttributeDescription in
   attributes of a new entry to be created, subject to the limitation
   that the client MUST NOT use language codes in the attribute value or
   values which form the RDN of the entry.

クライアントは作成されるためにAttributeDescriptionの言語コードを新しいエントリーの属性に提供するかもしれなくて、クライアントが使用してはいけない制限を条件として言語は属性でエントリーのRDNを形成する値か値をコード化します。

Wahl & Howes                Standards Track                     [Page 5]

RFC 2596             Use of Language Codes in LDAP              May 1999

ウォールとハウズStandardsは1999年5月にLDAPにおける言語コードのRFC2596使用を追跡します[5ページ]。

   A client MAY provide multiple attributes with the same attribute type
   and value, so long as each attribute has a different language code,
   and at most one attribute does not have a language code option.

クライアントは同じ属性タイプと値を複数の属性に提供するかもしれません、異なった言語コードが各属性にあって、最も1つで非常に長いので、属性に、言語コードオプションがありません。

   Servers which support storing language codes in the DIT MUST allow
   any attribute it recognizes that has the Directory String syntax to
   have a language option associated with it. Servers SHOULD allow
   language options to be associated with other attributes.

保存がDIT MUSTの言語コードであるとサポートするサーバが持っているディレクトリString構文を持っているそれが認識するどんな属性にもそれに関連している言語オプションを許容します。 サーバSHOULDは、言語オプションが他の属性に関連しているのを許容します。

   For example, the following is a legal request.

例えば、↓これは法的な要求です。

   objectclass: top
   objectclass: person
   objectclass: residentialPerson
   name: John Smith
   CN: John Smith
   CN;lang-en: John Smith
   SN: Smith
   streetAddress: 1 University Street
   streetAddress;lang-en: 1 University Street
   streetAddress;lang-fr: 1 rue Universite
   houseIdentifier;lang-fr: 9e etage

objectclass: 最高objectclass: 人のobjectclass: residentialPersonは以下を命名します。 ジョンスミスCN: ジョンスミスCN; langアン: ジョンスミスSN: スミスstreetAddress: 1 大学通りstreetAddress; langアン: 1 大学通りstreetAddress; lang-fr、: 1 悔悟Universite houseIdentifier; lang-fr、: 9e etage

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

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

3.7. Modify Operation

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

   A client MAY provide a language code in an AttributeDescription as
   part of a modification element in the modify operation.

クライアントが変更要素の一部としてAttributeDescriptionの言語コードを中に提供するかもしれない、操作を変更してください。

   Attribute types and language codes 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 a language
   code, the language code MUST be provided in the modify operation, and
   if the stored values to be deleted do not have a language code, then
   no language code is to be provided.

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

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

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

Wahl & Howes                Standards Track                     [Page 6]

RFC 2596             Use of Language Codes in LDAP              May 1999

ウォールとハウズStandardsは1999年5月にLDAPにおける言語コードのRFC2596使用を追跡します[6ページ]。

3.8. Diagnostic Messages

3.8. 診断メッセージ

   Servers SHOULD use only printable ASCII characters in the
   errorMessage field, as not all clients will be able to display the
   full range of Unicode.

サーバSHOULDはerrorMessage分野で印刷可能なASCII文字だけを使用します、すべてのクライアントがどんな最大限の範囲のユニコードを表示できるというわけではないとき。

4. Differences from X.500(1997)

4. X.500からの違い(1997)

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

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

   a) An X.500 operation which has specified a language code on a value
      matches a value in the directory without a language code.
   b) LDAP references RFC 1766, which allows for IANA registration of
      new tags.
   c) LDAP does not allow language codes in distinguished names.
   d) X.500 describes subschema administration procedures to allow
      language codes to be associated with particular attributes types.

a) 値の言語コードを指定したX.500操作はa言語コードb)なしでディレクトリの値に合っています。 LDAP参照RFC1766であり、どれが新しいことのIANA登録を考慮するかが. c)にタグ付けをします。 LDAPは分類名d)に言語コードを許容しません。 X.500は、言語コードが特定の属性タイプに関連しているのを許容するためにサブスキーマ管理手順について説明します。

5. Security Considerations

5. セキュリティ問題

   There are no known security considerations for this document.  See
   the security considerations sections of [1] and [2] for security
   considerations of LDAP in general.

このドキュメントのためのセキュリティ問題は知られていません。 一般に、LDAPのセキュリティ問題のための[1]と[2]のセキュリティ問題部を見てください。

6. Acknowledgements

6. 承認

   This document is a product of the IETF ASID and LDAPEXT working
   groups.  Martin Duerst provided many valuable comments on an earlier
   version of this document.

このドキュメントはIETF ASIDとLDAPEXTワーキンググループの製品です。 マーチンDuerstはこのドキュメントの以前のバージョンの多くの貴重なコメントを提供しました。

7. Bibliography

7. 図書目録

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

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

   [2] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
       X.500 Directory Access Protocol Attribute Syntax Definitions",
       RFC 2252, December 1997.

[2] ウォールとM.とCoulbeckとA.とハウズとT.とS.Kille、「軽量のX.500ディレクトリアクセス・プロトコル属性構文定義」、RFC2252、1997年12月。

   [3] Alvestrand, H.,"Tags for the Identification of Languages", RFC
       1766, March 1995.

Alvestrand(H.)が「言語の識別のためにタグ付けをする」[3]、RFC1766、1995年3月。

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

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

Wahl & Howes                Standards Track                     [Page 7]

RFC 2596             Use of Language Codes in LDAP              May 1999

ウォールとハウズStandardsは1999年5月にLDAPにおける言語コードのRFC2596使用を追跡します[7ページ]。

8. Authors' Addresses

8. 作者のアドレス

   Mark Wahl
   Innosoft International, Inc.
   8911 Capital of Texas Hwy Suite 4140
   Austin, TX 78759 USA

4140年のテキサスHwyスイートテキサス78759オースチン(米国)のマークウォールInnosoftの国際Inc.8911Capital

   EMail:  M.Wahl@innosoft.com

メール: M.Wahl@innosoft.com

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd
   Mountain View, CA 94043 USA

ティムハウズネットスケープ・コミュニケーションズ501E.Middlefieldカリフォルニア94043第マウンテンビュー(米国)

   Phone:  +1 650 937-3419
   EMail:   howes@netscape.com

以下に電話をしてください。 +1 650 937-3419 メールしてください: howes@netscape.com

Wahl & Howes                Standards Track                     [Page 8]

RFC 2596             Use of Language Codes in LDAP              May 1999

ウォールとハウズStandardsは1999年5月にLDAPにおける言語コードのRFC2596使用を追跡します[8ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

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

Wahl & Howes                Standards Track                     [Page 9]

ウォールとハウズ標準化過程[9ページ]