RFC5051 日本語訳

Network Working Group                                         M. Crispin
Request for Comments: 5051                      University of Washington
Category: Standards Track                                   October 2007

コメントを求めるワーキンググループM.クリスピン要求をネットワークでつないでください: 5051年のワシントン大学カテゴリ: 標準化過程2007年10月

         i;unicode-casemap - Simple Unicode Collation Algorithm

i; ユニコード-casemap--簡単なユニコードCollation Algorithm

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)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document describes "i;unicode-casemap", a simple case-
   insensitive collation for Unicode strings.  It provides equality,
   substring, and ordering operations.

このドキュメントはa簡単な状態で「i; ユニコードでcasemapすること」と説明します。ユニコードストリングのためのケース神経の鈍い照合。 それは平等、サブストリング、および注文に操作を提供します。

1.  Introduction

1. 序論

   The "i;ascii-casemap" collation described in [COMPARATOR] is quite
   simple to implement and provides case-independent comparisons for the
   26 Latin alphabetics.  It is specified as the default and/or baseline
   comparator in some application protocols, e.g., [IMAP-SORT].

[COMPARATOR]で説明された「i; ASCIIでcasemapする」照合は、実行するのがかなり簡単であり、ケースから独立している比較を26のラテン語のalphabeticsに供給します。 それはデフォルト、そして/または、基線比較器としていくつかのアプリケーション・プロトコル、例えば、[IMAP-SORT]で指定されます。

   However, the "i;ascii-casemap" collation does not produce
   satisfactory results with non-ASCII characters.  It is possible, with
   a modest extension, to provide a more sophisticated collation with
   greater multilingual applicability than "i;ascii-casemap".  This
   extension provides case-independent comparisons for a much greater
   number of characters.  It also collates characters with diacriticals
   with the non-diacritical character forms.

しかしながら、「i; ASCIIでcasemapする」照合は非ASCII文字と共に効果を収めません。 それは、「i; ASCIIでcasemapする」よりすばらしい多言語適用性をさらに洗練された照合に提供するために穏やかな拡大で可能です。 この拡大ははるかに大きい数のキャラクタにケースから独立している比較を提供します。 また、それは非識別的なキャラクタフォームでdiacriticalsにキャラクタを照合します。

   This collation, "i;unicode-casemap", is intended to be an alternative
   to, and preferred over, "i;ascii-casemap".  It does not replace the
   "i;basic" collation described in [BASIC].

「i; ASCIIでcasemapします」「i; ユニコードでcasemapする」というこの照合が代替手段であることを意図する、都合のよい。 取り替えない、「i; 」 照合が[BASIC]で説明した基礎。

2.  Unicode Casemap Collation Description

2. ユニコードCasemap照合記述

   The "i;unicode-casemap" collation is a simple collation which is
   case-insensitive in its treatment of characters.  It provides
   equality, substring, and ordering operations.  The validity test
   operation returns "valid" for any input.

「i; ユニコードでcasemapする」照合はキャラクタの処理で大文字と小文字を区別しない簡単な照合です。 それは平等、サブストリング、および注文に操作を提供します。 正当性テスト操作はどんな入力にも「有効な」状態で戻ります。

Crispin                     Standards Track                     [Page 1]

RFC 5051                   i;unicode-casemap                October 2007

クリスピンStandards Track[1ページ]RFC5051i; ユニコード-casemap2007年10月

   This collation allows strings in arbitrary (and mixed) character
   sets, as long as the character set for each string is identified and
   it is possible to convert the string to Unicode.  Strings which have
   an unidentified character set and/or cannot be converted to Unicode
   are not rejected, but are treated as binary.

この照合は任意の、そして、(混ぜられる)の文字の組でストリングを許容します、各ストリングのための文字の組が特定されて、ストリングをユニコードに変換するのが可能である限り。 拒絶されるのではなく、バイナリーとして扱われた状態で未確認の文字の組を持っている、そして/または、ユニコードに変換できないストリング。

   Each input string is prepared by converting it to a "titlecased
   canonicalized UTF-8" string according to the following steps, using
   UnicodeData.txt ([UNICODE-DATA]):

それぞれの入力ストリングがそれをaに変換することによって準備される、「以下のステップに従ったtitlecased canonicalized UTF-8インチのストリング、UnicodeData.txt([ユニコード-DATA])を使用します:」

      (1) A Unicode codepoint is obtained from the input string.

(1) 入力ストリングからユニコードcodepointを入手します。

          (a) If the input string is in a known charset that can be
              converted to Unicode, a sequence in the string's charset
              is read and checked for validity according to the rules of
              that charset.  If the sequence is valid, it is converted
              to a Unicode codepoint.  Note that for input strings in
              UTF-8, the UTF-8 sequence must be valid according to the
              rules of [UTF-8]; e.g., overlong UTF-8 sequences are
              invalid.

(a) 入力ストリングがユニコードに変換できる知られているcharsetにあるなら、そのcharsetの規則に従って、ストリングのcharsetの系列は、正当性がないかどうか読まれて、チェックされます。 系列が有効であるなら、それはユニコードcodepointに変換されます。 UTF-8の入力ストリングに、[UTF-8]の規則に従ってUTF-8系列が有効であるに違いないことに注意してください。 例えば、余りにも長いUTF-8系列は無効です。

          (b) If the input string is in an unknown charset, or an
              invalid sequence occurs in step (1)(a), conversion ceases.
              No further preparation is performed, and any partial
              preparation results are discarded.  The original string is
              used unchanged with the i;octet comparator.

(b) 入力ストリングが未知のcharsetにあるか、または無効の系列がステップ(1)(a)に起こるなら、変換はやみます。 さらなる準備は全く実行されません、そして、どんな部分的な準備結果も捨てられます。 オリジナルのストリングはiで変わりがない状態で使用されます; 八重奏比較器。

      (2) The following steps, using UnicodeData.txt ([UNICODE-DATA]),
          are performed on the resulting codepoint from step (1)(a).

(2) UnicodeData.txt([ユニコード-DATA])を使用して、以下のステップはステップ(1)(a)から結果として起こるcodepointに実行されます。

          (a) If the codepoint has a titlecase property in
              UnicodeData.txt (this is normally the same as the
              uppercase property), the codepoint is converted to the
              codepoints in the titlecase property.

(a) codepointがUnicodeData.txtにtitlecaseの特性を持っているなら(通常、これは大文字している特性と同じです)、codepointはtitlecase所有地のcodepointsに変換されます。

          (b) If the resulting codepoint from (2)(a) has a decomposition
              property of any type in UnicodeData.txt, the codepoint is
              converted to the codepoints in the decomposition property.
              This step is recursively applied to each of the resulting
              codepoints until no more decomposition is possible
              (effectively Normalization Form KD).

(b) (2)(a)からの結果として起こるcodepointがUnicodeData.txtにどんなタイプの分解の特性も持っているなら、codepointは分解所有地のcodepointsに変換されます。 それ以上の分解が可能にならないまで(事実上Normalization Form KD)、このステップはそれぞれの結果として起こるcodepointsに再帰的に適用されます。

          Example: codepoint U+01C4 (LATIN CAPITAL LETTER DZ WITH CARON)
          has a titlecase property of U+01C5 (LATIN CAPITAL LETTER D
          WITH SMALL LETTER Z WITH CARON).  Codepoint U+01C5 has a
          decomposition property of U+0044 (LATIN CAPITAL LETTER D)
          U+017E (LATIN SMALL LETTER Z WITH CARON).  U+017E has a
          decomposition property of U+007A (LATIN SMALL LETTER Z) U+030c

例: codepoint U+01C4(LATIN CAPITAL LETTER DZ WITH CARON)には、U+01C5(LATIN CAPITAL LETTER D WITH SMALL LETTER Z WITH CARON)のtitlecaseの特性があります。 Codepoint U+01C5には、U+0044(LATIN CAPITAL LETTER D)U+017E(LATIN SMALL LETTER Z WITH CARON)の分解の特性があります。 U+017Eには、U+007A(LATIN SMALL LETTER Z)U+030cの分解の特性があります。

Crispin                     Standards Track                     [Page 2]

RFC 5051                   i;unicode-casemap                October 2007

クリスピンStandards Track[2ページ]RFC5051i; ユニコード-casemap2007年10月

          (COMBINING CARON).  Neither U+0044, U+007A, nor U+030C have
          any decomposition properties.  Therefore, U+01C4 is converted
          to U+0044 U+007A U+030C by this step.

(キャロンを結合します。) U+0044、U+007AもU+030Cも、少しの分解の特性もありません。 したがって、U+01C4はこのステップでU+0044U+007A U+030C変えられます。

      (3) The resulting codepoint(s) from step (2) is/are appended, in
          UTF-8 format, to the "titlecased canonicalized UTF-8" string.

(3) ステップ(2)からの結果として起こるcodepoint(s)によるUTF-8形式で「titlecased canonicalized UTF-8インチのストリング」に/を追加するということです。

      (4) Repeat from step (1) until there is no more data in the input
          string.

(4) ステップ(1)から、入力ストリングにはそれ以上のデータが全くないまで、繰り返してください。

   Following the above preparation process on each string, the equality,
   ordering, and substring operations are as for i;octet.

各ストリングの上の準備プロセスに従って、平等、注文、およびサブストリング操作はiに似ています; 八重奏。

   It is permitted to use an alternative implementation of the above
   preparation process if it produces the same results.  For example, it
   may be more convenient for an implementation to convert all input
   strings to a sequence of UTF-16 or UTF-32 values prior to performing
   any of the step (2) actions.  Similarly, if all input strings are (or
   are convertible to) Unicode, it may be possible to use UTF-32 as an
   alternative to UTF-8 in step (3).

同じ結果を生むなら、それが上の準備プロセスの代替の実現を使用することが許可されます。 例えば、実現には、ステップ(2)動作のどれかを実行する前にUTF-16かUTF-32値の系列にすべての入力ストリングを変換するのは、より都合がよいかもしれません。 または、すべて入力されるなら同様に、ストリングがそうである、(変換可能である、)、ユニコード、ステップ(3)におけるUTF-8に代わる手段としてUTF-32を使用するのは可能であるかもしれません。

      Note: UTF-16 is unsuitable as an alternative to UTF-8 in step (3),
      because UTF-16 surrogates will cause i;octet to collate codepoints
      U+E0000 through U+FFFF after non-BMP codepoints.

以下に注意してください。 UTF-16はステップ(3)におけるUTF-8に代わる手段として不適当です、UTF-16代理がiを引き起こすので; 非BMP codepointsの後にU+FFFFを通して0000codepoints U+E照合する八重奏。

   This collation is not locale sensitive.  Consequently, care should be
   taken when using OS-supplied functions to implement this collation.
   Functions such as strcasecmp and toupper are sometimes locale
   sensitive and may inconsistently casemap letters.

この照合は現場敏感ではありません。 この照合を実行するのにOSに供給された機能を使用するとき、その結果、注意するべきです。 strcasecmpやtoupperなどの機能は、時々現場敏感であり、相反して手紙をcasemapするかもしれません。

   The i;unicode-casemap collation is well suited to use with many
   Internet protocols and computer languages.  Use with natural language
   is often inappropriate; even though the collation apparently supports
   languages such as Swahili and English, in real-world use it tends to
   mis-sort a number of types of string:

i; ユニコード-casemapの照合は多くのインターネットプロトコルとコンピュータ言語による使用によく合っています。 自然言語による使用はしばしば不適当です。 照合は明らかにスワヒリ族や英語などの言語をサポートしますが、本当の世界使用で、ストリングの多くのタイプの誤種類に世話をします:

   o  people and place names containing scripts that are not collated
      according to "alphabetical order".
   o  words with characters that have diacriticals.  However,
      i;unicode-casemap generally does a better job than i;ascii-casemap
      for most (but not all) languages.  For example, German umlaut
      letters will sort correctly, but some Scandinavian letters will
      not.
   o  names such as "Lloyd" (which in Welsh sorts after "Lyon", unlike
      in English),
   o  strings containing other non-letter symbols; e.g., euro and pound
      sterling symbols, quotation marks other than '"', dashes/hyphens,
      etc.

o 「アルファベット順」 o単語によると、diacriticalsを持っているキャラクタに照合されないスクリプトを含む人々と地名。 しかしながら、一般に、ユニコード-casemapが私より良い仕事をするという私はほとんどの(すべてでない)言語のためにASCIIでcasemapします。 例えば、ドイツのウムラウト符号手紙は正しく種類を望んでいますが、いくつかのスカンジナビアの手紙はそのように望まないでしょう。oは、「ロイド」(ウェールズ語で英語で異なった後「リヨン」を分類する)、oなどのように他の非手紙シンボルを含むとストリングを命名します。 例えば、ユーロとポンド貨シンボル、引用符、'、「'ダッシュ/ハイフンなど'」

Crispin                     Standards Track                     [Page 3]

RFC 5051                   i;unicode-casemap                October 2007

クリスピンStandards Track[3ページ]RFC5051i; ユニコード-casemap2007年10月

3.  Unicode Casemap Collation Registration

3. ユニコードCasemap照合登録

   <?xml version='1.0'?>
   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
   <collation rfc="5051" scope="global" intendedUse="common">
   <identifier>i;unicode-casemap</identifier>
   <title>Unicode Casemap</title>
   <operations>equality order substring</operations>
   <specification>RFC 5051</specification>
   <owner>IETF</owner>
   <submitter>mrc@cac.washington.edu</submitter>
   </collation>

<?xmlバージョン= '1.0'?><!DOCTYPE照合SYSTEM'collationreg.dtd'><照合rfc=「5051」範囲が「グローバルな」intendedUse=と等しい、「通例、「><識別子>i; ユニコードcasemapな</識別子><タイトル>ユニコードCasemap</タイトル><操作>平等オーダーサブストリング</操作><仕様>RFC 5051</specification> <owner>IETF</owner> <submitter>mrc@cac 。」、'; washington.edu</submitter>の</照合>。

4.  Security Considerations

4. セキュリティ問題

   The security considerations for [UTF-8], [STRINGPREP], and [UNICODE-
   SECURITY] apply and are normative to this specification.

[UTF-8]、[STRINGPREP]、および[ユニコードSECURITY]のためのセキュリティ問題は、適用して、この仕様に規範的です。

   The results from this comparator will vary depending upon the
   implementation for several reasons.  Implementations MUST consider
   whether these possibilities are a problem for their use case:

いくつかの理由のために実現によって、この比較器からの結果は異なるでしょう。 実現は、これらの可能性が彼らの使用のための問題であるか否かに関係なく、以下をケースに入れるように考えなければなりません。

   1) New characters added in Unicode may have decomposition or
      titlecase properties that will not be known to an implementation
      based upon an older revision of Unicode.  This impacts step (2).

1) ユニコードで加えられた新しいキャラクタはユニコードの、より古い改正に基づく実現に知られていない分解かtitlecaseの特性を持っているかもしれません。 これはステップ(2)に影響を与えます。

   2) Step (2)(b) defines a subset of Normalization Form KD (NFKD) that
      does not require normalization of out-of-order diacriticals.
      However, an implementation MAY use an NFKD library routine that
      does such normalization.  This impacts step (2)(b) and possibly
      also step (1)(a), and is an issue only with ill-formed UTF-8
      input.

2) ステップ(2)(b)は故障しているdiacriticalsの正常化を必要としないNormalization Form KD(NFKD)の部分集合を定義します。 しかしながら、実現はそのような正常化をするNFKDライブラリ・ルーチンを使用するかもしれません。 これは、ステップ(2)(b)とことによるとまた、ステップ(1)(a)に影響を与えて、不適格なUTF-8入力だけの問題です。

   3) The set of charsets handled in step (1)(a) is open-ended.  UTF-8
      (and, by extension, US-ASCII) are the only mandatory-to-implement
      charsets.  This impacts step (1)(a).

3) ステップ(1)(a)で扱われたcharsetsのセットは制限のないです。 UTF-8(そして、拡大による米国-ASCII)は唯一の実行するために義務的なcharsetsです。 これはステップ(1)(a)に影響を与えます。

      Implementations SHOULD, as far as feasible, support all the
      charsets they are likely to encounter in the input data, in order
      to avoid poor collation caused by the fall through to the (1)(b)
      rule.

可能であるのと同じくらい遠い実現SHOULDはそれらが入力データで遭遇しそうであるすべてのcharsetsを支持します、(1)(b)規則に終えた秋までに引き起こされた不十分な照合を避けるために。

   4) Other charsets may have revisions which add new characters that
      are not known to an implementation based upon an older revision.
      This impacts step (1)(a) and possibly also step (1)(b).

4) 他のcharsetsには、より古い改正に基づく実現に知られていない新しいキャラクタを加える改正があるかもしれません。 これはステップ(1)(a)とことによるとまた、ステップ(1)(b)に影響を与えます。

Crispin                     Standards Track                     [Page 4]

RFC 5051                   i;unicode-casemap                October 2007

クリスピンStandards Track[4ページ]RFC5051i; ユニコード-casemap2007年10月

   An attacker may create input that is ill-formed or in an unknown
   charset, with the intention of impacting the results of this
   comparator or exploiting other parts of the system which process this
   input in different ways.  Note, however, that even well-formed data
   in a known charset can impact the result of this comparator in
   unexpected ways.  For example, an attacker can substitute U+0041
   (LATIN CAPITAL LETTER A) with U+0391 (GREEK CAPITAL LETTER ALPHA) or
   U+0410 (CYRILLIC CAPITAL LETTER A) in the intention of causing a
   non-match of strings which visually appear the same and/or causing
   the string to appear elsewhere in a sort.

攻撃者は、不適格な入力を作成するか、または未知のcharsetでそうするかもしれません、異なった方法でこの比較器の結果に影響を与えるか、またはこの入力を処理するシステムの他の部分を利用するという意志で。 しかしながら、知られているcharsetのよく形成されたデータさえ予期していなかった方法でこの比較器の結果に影響を与えることができることに注意してください。 例えば、攻撃者は目視により同じに見えるストリングの非マッチを引き起こす、そして/または、ストリングが種類のほかの場所に現れることを引き起こすという意志におけるU+0391(GREEK CAPITAL LETTER ALPHA)かU+0410(CYRILLIC CAPITAL LETTER A)と共にU+0041(LATIN CAPITAL LETTER A)を代入できます。

5.  IANA Considerations

5. IANA問題

   The i;unicode-casemap collation defined in section 2 has been added
   to the registry of collations defined in [COMPARATOR].

i; セクション2で定義されたユニコード-casemapの照合は[COMPARATOR]で定義された校合の登録に加えられます。

6.  Normative References

6. 引用規格

   [COMPARATOR]          Newman, C., Duerst, M., and A. Gulbrandsen,
                         "Internet Application Protocol Collation
                         Registry", RFC 4790, February 2007.

[比較器] ニューマンとC.とDuerst、M.とA.Gulbrandsen、「インターネットアプリケーション・プロトコル照合登録」、RFC4790、2007年2月。

   [STRINGPREP]          Hoffman, P. and M. Blanchet, "Preparation of
                         Internationalized Strings ("stringprep")", RFC
                         3454, December 2002.

[STRINGPREP] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。

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

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

   [UNICODE-DATA]        <http://www.unicode.org/Public/UNIDATA/
                         UnicodeData.txt>

[ユニコードデータ] <http://www.unicode.org/公衆/UNIDATA/UnicodeData.txt>。

                         Although the UnicodeData.txt file referenced
                         here is part of the Unicode standard, it is
                         subject to change as new characters are added
                         to Unicode and errors are corrected in Unicode
                         revisions.  As a result, it may be less stable
                         than might otherwise be implied by the
                         standards status of this specification.

ここで参照をつけられたUnicodeData.txtファイルはユニコード規格の一部ですが、新しいキャラクタがユニコードに追加されて、誤りがユニコード改正で修正されるとき、変化するのは受けることがあります。 そうでなければ、それはその結果、この仕様の規格状態で安定しているかもしれないより暗示しているかもしれません。

   [UNICODE-SECURITY]    Davis, M. and M. Suignard, "Unicode Security
                         Considerations", February 2006,
                         <http://www.unicode.org/reports/tr36/>.

[ユニコードセキュリティ] デイヴィス、M.とM.Suignard、「ユニコードセキュリティ問題。」2006年2月、<http://www.unicode.org/reports/tr36/>。

Crispin                     Standards Track                     [Page 5]

RFC 5051                   i;unicode-casemap                October 2007

クリスピンStandards Track[5ページ]RFC5051i; ユニコード-casemap2007年10月

7.  Informative References

7. 有益な参照

   [BASIC]               Newman, C., Duerst, M., and A. Gulbrandsen,
                         "i;basic - the Unicode Collation Algorithm",
                         Work in Progress, March 2007.

[基本的な] 「i; 基礎--ユニコード照合アルゴリズム」というGulbrandsenが進行中で働かせるニューマン、C.、Duerst、M.、およびA.は2007を行進させます。

   [IMAP-SORT]           Crispin, M. and K. Murchison, "Internet Message
                         Access Protocol - SORT and THREAD Extensions",
                         Work in Progress, September 2007.

[IMAP-種類] 「インターネットメッセージアクセス・プロトコル--拡大を分類して、糸を通す」というクリスピン、M.、およびK.マーチソンは進歩、2007年9月に働いています。

Author's Address

作者のアドレス

   Mark R. Crispin
   Networks and Distributed Computing
   University of Washington
   4545 15th Avenue NE
   Seattle, WA  98105-4527

マークR.クリスピンネットワークと第15分散コンピューティングワシントン大学4545アベニューNeシアトル、ワシントン98105-4527

   Phone: +1 (206) 543-5762
   EMail: MRC@CAC.Washington.EDU

以下に電話をしてください。 +1 (206) 543-5762 メールしてください: MRC@CAC.Washington.EDU

Crispin                     Standards Track                     [Page 6]

RFC 5051                   i;unicode-casemap                October 2007

クリスピンStandards Track[6ページ]RFC5051i; ユニコード-casemap2007年10月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   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, THE IETF TRUST 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.

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

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に情報を記述してください。

Crispin                     Standards Track                     [Page 7]

クリスピン標準化過程[7ページ]