Network Working Group E. Wilde
Request for Comments: 5147 UC Berkeley
Updates: 2046 M. Duerst
Category: Standards Track Aoyama Gakuin University
April 2008
URI Fragment Identifiers for the text/plain Media Type
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust.
このメモは、text / plainのMIMEエンティティのURIのフラグメント識別子を定義します。これらのフラグメント識別子は、text / plainのMIMEエンティティの部分を参照することを可能にする、いずれかの文字位置又は範囲によって、またはライン位置または範囲により同定しました。フラグメント識別子はまた、彼らはより堅牢にするために整合性チェックのための情報が含まれていてもよいです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What Is text/plain? . . . . . . . . . . . . . . . . . . . 3
1.2. What Is a URI Fragment Identifier? . . . . . . . . . . . . 4
1.3. Why text/plain Fragment Identifiers? . . . . . . . . . . . 4
1.4. Incremental Deployment . . . . . . . . . . . . . . . . . . 5
1.5. Notation Used in This Memo . . . . . . . . . . . . . . . . 5
2. Fragment Identification Methods . . . . . . . . . . . . . . . 5
2.1. Fragment Identification Principles . . . . . . . . . . . . 6
2.1.1. Positions and Ranges . . . . . . . . . . . . . . . . . 6
2.1.2. Characters and Lines . . . . . . . . . . . . . . . . . 7
2.2. Combining the Principles . . . . . . . . . . . . . . . . . 7
2.2.1. Character Position . . . . . . . . . . . . . . . . . . 7
2.2.2. Character Range . . . . . . . . . . . . . . . . . . . 8
2.2.3. Line Position . . . . . . . . . . . . . . . . . . . . 8
2.2.4. Line Range . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Fragment Identifier Robustness . . . . . . . . . . . . . . 8
3. Fragment Identification Syntax . . . . . . . . . . . . . . . . 9
3.1. Integrity Checks . . . . . . . . . . . . . . . . . . . . . 9
4. Fragment Identifier Processing . . . . . . . . . . . . . . . . 10
4.1. Handling of Line Endings in text/plain MIME Entities . . . 10
4.2. Handling of Position Values . . . . . . . . . . . . . . . 11
4.3. Handling of Integrity Checks . . . . . . . . . . . . . . . 11
4.4. Syntax Errors in Fragment Identifiers . . . . . . . . . . 12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
This memo updates the text/plain media type defined in RFC 2046 [3] by defining URI fragment identifiers for text/plain MIME entities. This makes it possible to refer to parts of a text/plain MIME entity. Such parts can be identified by either character position or range, or by line position or range. Integrity checking information can be added to a fragment identifier to make it more robust, enabling applications to detect changes of the entity.
このメモは、text / plainのMIMEエンティティのURIフラグメント識別子を定義することにより、[3] RFC 2046で定義されたtext / plainのメディアタイプを更新します。これは、text / plainのMIMEエンティティの部分を参照することが可能になります。そのような部品は、文字位置又は範囲、またはライン位置または範囲のいずれかによって同定することができます。情報の整合性チェックは、エンティティの変化を検出するためのアプリケーションを可能にする、それはより堅牢にするために、フラグメント識別子に追加することができます。
This section gives an introduction to the general concepts of text/ plain MIME entities and URI fragment identifiers, and it discusses the need for fragment identifiers for text/plain and deployment issues. Section 2 discusses the principles and methods on which this memo is based. Section 3 defines the syntax, and Section 4 discusses processing of text/plain fragment identifiers. Section 5 shows some examples.
このセクションでは、text / plainのMIMEエンティティとURIのフラグメント識別子の一般的な概念を紹介を与え、そしてそれは、テキスト/平野と展開の問題のためのフラグメント識別子の必要性を論じています。第2節では、このメモの基礎となる原則と方法について説明します。セクション3は、構文を定義し、セクション4は、text / plainのフラグメント識別子の処理について論じています。第5節では、いくつかの例を示します。
Internet Media Types (often referred to as "MIME types"), as defined in RFC 2045 [2] and RFC 2046 [3], are used to identify different types and sub-types of media. RFC 2046 [3] and RFC 3676 [6] specify the text/plain media type, which is used for simple, unformatted text. Quoting from RFC 2046 [3]: "Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks".
RFC 2045で定義されているインターネットメディアタイプは、（しばしば「MIMEタイプ」と呼ぶ）[2]及びRFC 2046 [3]は、異なる種類およびメディアのサブタイプを同定するために使用されます。 RFC 2046 [3]及びRFC 3676 [6]、単純な、フォーマットされていないテキストのために使用されるtext / plainのメディアタイプを指定。 RFC 2046から引用[3]：「プレーンテキストがために提供するか、またはコマンド、フォント属性の仕様、処理命令、解釈ディレクティブ、またはコンテンツのマークアップをフォーマットすることはできませんプレーンテキストは単に文字の線状配列として見られている、おそらくラインによって中断休憩や改ページ」。
The text/plain media type does not restrict the character encoding; any character encoding may be used. In the absence of an explicit character encoding declaration, US-ASCII [13] is assumed as the default character encoding. This variability of the character encoding makes it impossible to count characters in a text/plain MIME entity without taking the character encoding into account, because there are many character encodings using more than one octet per character.
text / plainのメディアタイプは、文字エンコーディングを制限するものではありません。任意の文字エンコーディングを使用することができます。明示的な文字エンコーディング宣言の非存在下で、US-ASCII [13]デフォルトの文字エンコーディングとします。文字エンコーディングのこの変動は、文字ごとに複数のオクテットを使用して多くの文字エンコーディングがあるので、それは不可能、考慮に文字エンコーディングを取ることなくtext / plainのMIMEエンティティ内の文字をカウントすることができます。
The biggest advantage of text/plain MIME entities is their ease of use and their portability among different platforms. As long as they use popular character encodings (such as US-ASCII or UTF-8 [12]), they can be displayed and processed on virtually every computer system. The only remaining interoperability issue is the representation of line endings, which is discussed in Section 4.1.
text / plainのMIMEエンティティの最大の利点は、使用の容易さと、異なるプラットフォーム間で彼らの移植です。限り、彼らは（例えばUS-ASCIIまたはUTF-8 [12]など）の人気の文字エンコーディングを使用して、彼らが表示され、事実上すべてのコンピュータシステムを上に処理することができます。唯一残っている相互運用性の問題は、4.1節で議論されている行末の表現です。
URIs are the identification mechanism for resources on the Web. The URI syntax specified in RFC 3986 [7] optionally includes a so-called "fragment identifier", separated by a number sign ('#'). The fragment identifier consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. The semantics of a fragment identifier are a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type of the retrieval result.
URIは、Web上のリソースの識別メカニズムです。 RFC 3986で指定されたURIの構文は、[7]、任意に番号記号（「＃」）によって分離された、いわゆる「フラグメント識別子」を含みます。フラグメント識別子は、検索アクションが正常に完了した後、ユーザエージェントによって解釈されるべき追加の参照情報から成ります。フラグメント識別子の意味論に関係なく、関連して使用されるURIの種類の、検索行動から生じるデータの性質です。したがって、フラグメント識別子のフォーマット及び解釈は、検索結果のメディアタイプに依存しています。
The most popular fragment identifier is defined for text/html (defined in RFC 2854 [10]) and makes it possible to refer to a specific element (identified by the value of a 'name' or 'id' attribute) of an HTML document. This makes it possible to reference a specific part of a Web page, rather than a Web page as a whole.
最も人気のあるフラグメント識別子（RFC 2854 [10]で定義された）テキスト/ HTML用に定義されたHTML文書の（「名前」または「ID」属性の値によって識別される）特定の要素を参照することができるされています。これは、全体として、Webページの特定の部分ではなく、Webページを参照することが可能となります。
Referring to specific parts of a resource can be very useful because it enables users and applications to create more specific references. Users can create references to the part they really are interested in or want to talk about, rather than always pointing to a complete resource. Even though it is suggested that fragment identification methods are specified in a media type's MIME registration (see [15]), many media types do not have fragment identification methods associated with them.
それは、より具体的な言及を作成するために、ユーザーやアプリケーションが可能になるため、リソースの特定の部分を参照することは非常に役立ちます。ユーザーは、むしろ、常に完全なリソースを指しているよりも、彼らは本当にに興味があるかについて話をしたい部分への参照を作成することができます。それは（[15]参照）フラグメントの識別方法は、メディアタイプのMIME登録で指定されていることが示唆されているにもかかわらず、多くのメディアタイプは、それらに関連付けられているフラグメントの識別方法を持っていません。
Fragment identifiers are only useful if supported by the client, because they are only interpreted by the client. Therefore, a new fragment identification method will require some time to be adopted by clients, and older clients will not support it. However, because the URI still works even if the fragment identifier is not supported (the resource is retrieved, but the fragment identifier is not interpreted), rapid adoption is not highly critical to ensure the success of a new fragment identification method.
クライアントでサポートされている場合、彼らは、クライアントのみによって解釈されるため、フラグメント識別子は、のみ有用です。そのため、新しいフラグメントの識別方法は、クライアントが採用されるようにいくつかの時間が必要になりますし、古いクライアントはそれをサポートしていません。 URIは、依然として（リソースが検索されるが、断片識別子は解釈されない）フラグメント識別子がサポートされていない場合でも動作するためしかし、急速な普及は、新しいフラグメントの識別方法の成功を確実にするために非常に重要ではありません。
Fragment identifiers for text/plain, as defined in this memo, make it possible to refer to specific parts of a text/plain MIME entity, using concepts of positions and ranges, which may be applied to characters and lines. Thus, text/plain fragment identifiers enable users to exchange information more specifically, thereby reducing the time and effort that is necessary to manually search for the relevant part of a text/plain MIME entity.
プレーンテキスト/用断片識別子は、このメモで定義されるように、それが可能な文字や線にも適用することができる位置と範囲の概念を使用して、text / plainのMIMEエンティティの特定の部分を参照するために行います。したがって、text / plainのフラグメント識別子は、それによって手動でtext / plainのMIMEエンティティの関連部分を検索するために必要な時間と労力を低減すること、より具体的に情報を交換することを可能にします。
The text/plain format does not support the embedding of links, so in most environments, text/plain resources can only serve as targets for links, and not as sources. However, when combining the text/plain fragment identifiers specified in this memo with out-of-line linking mechanisms such as XLink [14], it becomes possible to "bind" link resources to text/plain resources and thereby "embed" links into text/plain resources. Thus, the text/plain fragment identifiers specified in this memo open a path for text/plain files to become bidirectionally navigable resources in hypermedia systems such as the Web.
ほとんどの環境では、text / plainのリソースのみをソースとして、リンクのターゲットとして機能し、することはできませんので、text / plainの形式は、リンクの埋め込みをサポートしていません。 [14]そのようなXLinkのようなアウトオブラインリンク機構と、このメモで指定されたtext / plainのフラグメント識別子を組み合わせた場合しかし、それにtext / plainのリソースと、それにより「埋め込み」リンクに「バインド」リンクリソースすることが可能となりますtext / plainのリソース。 text / plainのファイルは、ウェブなどのハイパーメディアシステムにおける双方向航行資源になることのためにこのように、このメモで指定されたtext / plainのフラグメント識別子は、パスを開きます。
As long as text/plain fragment identifiers are not supported universally, it is important to consider the implications of incremental deployment. Clients (for example, Web browsers) not supporting the text/plain fragment identifier described in this memo will work with URI references to text/plain MIME entities, but they will fail to locate the sub-resource identified by the fragment identifier. This is a reasonable fallback behavior, and in general, users should take into account the possibility that a program interpreting a given URI will fail to interpret the fragment identifier part. Since fragment identifier evaluation is local to the client (and happens after retrieving the MIME entity), there is no reliable way for a server to determine whether a requesting client is using a URI containing a fragment identifier.
限り、text / plainのフラグメント識別子は、普遍的サポートされていないとして、増分展開の影響を考慮することが重要です。このメモで記述されたテキスト/平野フラグメント識別子をサポートしていないクライアント（例えば、Webブラウザでは）/無地MIMEエンティティをテキストにURI参照で動作しますが、それらは、フラグメント識別子で識別されるサブリソースを見つけるために失敗します。これは、合理的なフォールバック動作であり、一般的には、ユーザーがアカウントに指定されたURIを解釈するプログラムは、フラグメント識別子の一部を解釈するために失敗する可能性を取る必要があります。フラグメント識別子の評価がクライアントにローカルである（及びMIME実体を検索した後に起こる）ので、サーバは要求しているクライアントは、フラグメント識別子を含むURIを使用しているかどうかを決定するための信頼できる方法がありません。
The capitalized 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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "オプション" [4] RFC 2119に記載されるように解釈されるべきです。
The identification of fragments of text/plain MIME entities can be based on different foundations. Since it is not possible to insert explicit, invisible identifiers into a text/plain MIME entity (for example, as used in HTML documents, implemented through dedicated attributes), fragment identification has to rely on certain inherent properties of the MIME entity. This memo specifies fragment identification using four different methods, which are character positions and ranges, and line positions and ranges, augmented by an integrity check mechanism for improving the robustness of fragment identifiers.
text / plainのMIMEエンティティの断片の同定は異なる基盤に基づくことができます。それは（専用属性を介して実装されたHTML文書で使用されるように、例えば）text / plainのMIMEエンティティに明示的に、不可視の識別子を挿入することができないので、断片識別は、MIMEエンティティの特定の固有の特性に依存しなければなりません。このメモは、フラグメント識別子のロバスト性を改善するための完全性チェックメカニズムによって拡張文字位置および範囲、およびライン位置および範囲、4つの異なる方法を用いて、断片識別を指定します。
When interpreting character or line numbers, implementations MUST take the character encoding of the MIME entity into account, because character count and octet count may differ for the character encoding being used. For example, a MIME entity using the UTF-16 encoding (as specified in RFC 2781 [11]) uses two octets per character in most cases, and sometimes four octets per character. It can also have a leading BOM (Byte-Order Mark), which does not count as a character and thus also affects the mapping from a simple octet count to a character count.
文字や線の番号を解釈すると文字カウントとオクテットカウントが使用されている文字エンコーディングのために異なる場合がありますので、実装は、考慮にMIMEエンティティの文字エンコーディングを取る必要があります。例えば、UTF-16エンコーディング（RFC 2781で指定されるように[11]）を使用してMIMEエンティティは、ほとんどの場合、文字ごとに2つのオクテット、および文字ごと、時には4つのオクテットを使用します。また、文字カウントに数え文字としてカウントし、したがってまた、単純なオクテットからのマッピングに影響を及ぼしていない主要なBOM（バイトオーダーマーク）を、持つことができます。
Fragment identification can be done by combining two orthogonal principles, which are positions and ranges, and characters and lines. This section describes the principles themselves, while Section 2.2 describes the combination of the principles.
断片の同定は、位置および範囲、文字や線である二つの直交原理を組み合わせることにより行うことができます。 2.2節は、原則の組み合わせを説明しながら、このセクションでは、原則そのものを説明しています。
A position does not identify an actual fragment of the MIME entity, but a position inside the MIME entity, which can be regarded as a fragment of length zero. The use case for positions is to provide pointers for applications that may use them to implement functionalities such as "insert some text here", which needs a position rather than a fragment. Positions are counted from zero; position zero being before the first character or line of a text/ plain MIME entity. Thus, a text/plain MIME entity having one character has two positions, one before the first character (position zero), and one after the first character (position 1).
位置は、MIMEエンティティの実際の断片が、長さゼロの断片とみなすことができるMIMEエンティティ、内部の位置を識別しません。位置のためのユースケースは、そのような位置ではなく断片が必要、「ここにテキストを挿入」などの機能を実装するためにそれらを使用することができるアプリケーションのためのポインタを提供することです。位置はゼロからカウントされます。 text / plainのMIMEエンティティの最初の文字または行の前にいる位置はゼロ。したがって、一つの文字を有するtext / plainのMIMEエンティティは、二つの位置、最初の文字（位置ゼロ）一つ前、最初の文字（位置1）の後つを有します。
Since positions are fragments of length zero, applications SHOULD use other methods than highlighting to indicate positions, the most obvious way being the positioning of a cursor (if the application supports the concept of a cursor).
位置は長さゼロのフラグメントであるので、（アプリケーションがカーソルの概念をサポートしている場合）、アプリケーションは、最も明白な方法は、カーソルの位置である、位置を示すために強調表示以外の方法を使用すべきです。
Ranges, on the other hand, identify fragments of a MIME entity that have a length that may be greater than zero. As a general principle for ranges, they specify both a lower and an upper bound. The start or the end of a range specification may be omitted, defaulting to the first or last position of the MIME entity, respectively. The end of a range must have a value greater than or equal to the start. A range with identical start and end is legal and identifies a range of length zero, which is equivalent to a position.
範囲が、一方、ゼロよりも大きくすることができる長さを有しているMIMEエンティティの断片を同定します。範囲のための一般的な原則として、彼らは、下限と上限の両方を指定します。開始または範囲指定の端部は、それぞれ、MIMEエンティティの最初または最後の位置をデフォルト、省略してもよいです。範囲の端部は、開始以上の値を有していなければなりません。同一の開始と終了との範囲が合法である位置に相当する長さゼロの範囲を識別する。
Applications that support a concept such as highlighting SHOULD use such a concept to indicate fragments of lengths greater than zero to the user.
などの強調表示などの概念をサポートするアプリケーションは、ユーザーにゼロより大きい長さの断片を示すために、このような概念を使用すべきです。
For positions and ranges, it is implicitly assumed that if a number is greater than the actual number of elements in the MIME entity, then it is referring to the last element of the MIME entity (see Section 4 for details).
位置および範囲のために、暗黙的に番号がMIMEエンティティ内の要素の実際の数よりも大きい場合、それは（詳細についてはセクション4を参照）MIMEエンティティの最後の要素に言及されているものとします。
The concept of positions and ranges can be applied to characters or lines. In both cases, positions indicate points between these entities, while ranges identify zero or more of these entities by indicating positions.
位置と範囲の概念は、文字や線に適用することができます。範囲は、位置を示すことにより、これらのエンティティのゼロ以上を識別しながら、両方の場合において、位置は、これらのエンティティ間の点を示します。
Character positions are numbered starting with zero (ignoring initial BOM marks or similar concepts that are not part of the actual textual content of a text/plain MIME entity), and counting each character separately, with the exception of line endings, which are always counted as one character (see Section 4.1 for details).
文字位置は、常にカウントさ行末、を除いて、（text / plainのMIMEエンティティの実際のテキストコンテンツの一部ではない最初のBOMマーク又は類似の概念を無視して）ゼロで始まり、そして別々に各文字をカウントする番号が付けられています1つの文字として（詳細はセクション4.1を参照してください）。
Line positions are numbered starting with zero (with line position zero always being identical with character position zero); Section 4.1 describes how line endings are identified. Fragments identified by lines include the line endings, so applications identifying line-based fragments MUST include the line endings in the fragment identification they are using (e.g., the highlighted selection). If a MIME entity does not contain any line endings, then it consists of a single (the first) line.
ライン位置は（常に文字位置ゼロと同じであるライン位置ゼロ）ゼロから始まる番号が付けられています。 4.1節では行末が識別されている方法を説明します。ラインベースのフラグメントを識別するアプリケーションは、それらが（例えば、強調表示された選択）を使用している断片の同定に行末を含まなければならないので、行によって識別されるフラグメントは、行末を含みます。 MIMEエンティティは任意の改行コードが含まれていない場合、それは、単一の（最初の）ラインで構成されています。
In the following sections, the principles described in the preceding section (positions/ranges and characters/lines) are combined, resulting in four use cases. The schemes mentioned below refer to the fragment identifier syntax, described in detail in Section 3.
以下のセクションでは、前のセクション（位置/範囲および文字/行）に記載された原理は、4つのユースケースでは、結果として組み合わされます。下記のスキームは、セクション3で詳細に説明フラグメント識別子構文を指します。
To identify a character position (i.e., a fragment of length zero between two characters), the 'char' scheme followed by a single number is used. This method identifies a position between two characters (or before the first or after the last character), rather than identifying a fragment consisting of a number of characters. Character position counting starts with zero, so the character position before the first character of a text/plain MIME entity has the character position zero, and a MIME entity containing n distinct characters has n+1 distinct character positions, the last one having the character position n.
（2つの文字間の長さゼロの、すなわち、断片）の文字位置を特定するために、単一の数字が続く「チャー」方式が使用されます。この方法ではなく文字の数からなるフラグメントを同定するよりも、2つの文字（または最初または最後の文字前後）との間の位置を特定します。文字位置カウントはゼロから始まるので、text / plainのMIMEエンティティの最初の文字の前の文字位置は、文字位置ゼロを有し、N個の異なる文字を含むMIMEエンティティは、文字を有する最後のN + 1の別個の文字位置を有します位置n。
To identify a fragment of one or more characters (a character range), the 'char' scheme followed by a range specification is used. A character range is a consecutive region of the MIME entity that extends from the starting character position of the range to the ending character position of the range.
一つまたは複数の文字（文字領域）の断片を同定するために、範囲指定に続いて「チャー」方式が使用されます。文字の範囲は、範囲の終了文字位置の範囲の開始文字位置から延びるMIMEエンティティの連続領域です。
To identify a line position (i.e., a fragment of length zero between two lines), the 'line' scheme followed by a single number is used. This method identifies a position between two lines (or before the first or after the last line), rather than identifying a fragment consisting of a number of lines. Line position counting starts with zero, so the line position before the first line of a text/plain MIME entity has the line position zero, and a MIME entity containing n distinct lines has n+1 distinct line positions, the last one having the line position n.
（2線間の長さゼロの、すなわち、断片）ライン位置を特定するために、単一の数字が続く「ライン」方式が使用されます。この方法ではなく行数からなるフラグメントを同定するよりも、二行（または最初または最後の行前後）との間の位置を特定します。ライン位置カウントはゼロから始まるので、text / plainのMIMEエンティティの最初の行の前の行の位置は、ライン位置ゼロを有し、N個の異なる行を含むMIMEエンティティは、ラインを有する最後のN + 1の別個のライン位置を有します位置n。
To identify a fragment of one or more lines (a line range), the 'line' scheme followed by a range specification is used. A line range is a consecutive region of the MIME entity that extends from the starting line position of the range to the ending line position of the range.
一本の以上のライン（ライン幅）の断片を同定するために、範囲指定に続いて「線」方式が使用されます。行範囲は、範囲の終了行の位置までの範囲の開始行位置から延びMIMEエンティティの連続領域です。
It is easily possible that a modification of the referenced resource will break a fragment identifier. If applications want to create more robust fragment identifiers, they may do so by adding integrity-check information to fragment identifiers. Such information is used to detect changes in the resource. Applications can then warn users about the possibility that a fragment identifier might have been broken by a modification of the resource.
参照されるリソースの修正は、フラグメント識別子を破るだろうということは容易に可能です。アプリケーションは、より堅牢なフラグメント識別子を作成したい場合は、フラグメント識別子に整合性チェック情報を付加することによってそれを行うことができます。このような情報はリソースの変化を検出するために使用されます。アプリケーションはその後、フラグメント識別子は、リソースの変更によって破壊されているかもしれないという可能性についてユーザーに警告することができます。
Fragment identifiers are interpreted by clients, and therefore integrity-check information is defined on MIME entities rather than on the resource itself. This means that the integrity-check information is specific to a certain entity. Specifically, content encodings and/or content transfer encodings must be removed before using integrity-check information.
フラグメント識別子は、クライアントによって解釈されているため、整合性チェックの情報は、MIMEエンティティにではなく、リソース自体に定義されます。これは、整合性チェックの情報は、特定のエンティティに固有であることを意味します。具体的には、コンテンツのエンコードおよび/またはコンテンツ転送エンコーディングは、整合性チェックの情報を使用する前に削除する必要があります。
Integrity-check information may specify the character encoding that has been used when creating the information, and if such a specification is present, clients MUST check whether the character encoding specified and the character encoding of the retrieved MIME entity are equal, and clients MUST NOT use the integrity check information if these values differ. However, clients MAY choose to transcode the retrieved MIME entity in the case of differing character encodings, and after doing so, apply integrity checks. Please note that this method is inherently unreliable because certain characters or character sequences may have been lost or normalized due to restrictions in one of the character encodings used.
情報は、情報を作成する際に使用されている文字コードを指定することができる、そのような仕様が存在する場合、クライアントは、指定された文字符号化および検索MIMEエンティティの文字エンコーディングは等しく、クライアントではない必要があるかどうかをチェックしなければなりません整合性チェックこれらの値が異なる場合、整合性チェック情報を使用します。ただし、クライアントは、異なる文字エンコーディングの場合には、検索MIMEエンティティをトランスコードすることを選択することができ、そうすることの後に、整合性チェックを適用します。特定の文字または文字列は、使用される文字エンコーディングのいずれかで、制限のために失われるか、または正規化されている可能性があるため、この方法は、本質的に信頼できないことに注意してください。
The syntax for the text/plain fragment identifiers is straightforward. The syntax defines four schemes, 'char', 'line', and integrity check (which can either be 'length' or 'md5'). The 'char' and 'line' schemes can be used in two different variants, either the position variant (with a single number), or the range variant (with two comma-separated numbers). An integrity check can either use the 'length' or the 'md5' scheme to specify a value. 'length' in this case serves as a very weak but easy to calculate integrity check.
text / plainのフラグメント識別子の構文は簡単です。構文は、4つのスキーム、「文字」、「ライン」、及び（いずれかの「長さ」または「MD5」であることができる）整合性チェックを定義します。 「チャー」と「線」スキームは、二つの異なる変異体のいずれか（単一番号の）位置変種、または（二カンマ区切り番号の）範囲のバリアントで使用することができます。整合性チェックは、値を指定するには、「長さ」または「MD5」スキームを使用することができます。この場合の「長さ」は非常に弱いが、整合性チェックを計算するのは簡単として機能します。
The following syntax definition uses ABNF as defined in RFC 5234 [9], including the rules DIGIT and HEXDIG. The mime-charset rule is defined in RFC 2978 [5].
次の構文定義は、ルールDIGITとHEXDIG含む、[9] RFC 5234で定義されるようにABNFを使用します。 MIME-文字セットのルールは、RFC 2978で定義されている[5]。
NOTE: In the descriptions that follow, specified text values MUST be used exactly as given, using exactly the indicated lower-case letters. In this respect, the ABNF usage differs from [9].
注：正確に示す小文字を使用して、与えられた以下の説明では、指定されたテキスト値が正確に使用しなければなりません。この点では、ABNFの使用は、[9]とは異なります。
text-fragment = text-scheme 0*( ";" integrity-check ) text-scheme = ( char-scheme / line-scheme ) char-scheme = "char=" ( position / range ) line-scheme = "line=" ( position / range ) integrity-check = ( length-scheme / md5-scheme ) [ "," mime-charset ] position = number range = ( position "," [ position ] ) / ( "," position ) number = 1*( DIGIT ) length-scheme = "length=" number md5-scheme = "md5=" md5-value md5-value = 32HEXDIG
テキスト断片=テキストスキーム0 *（「;」整合性チェック）テキストスキーム=（チャー方式/ライン方式）チャースキーム=「CHAR =」（位置/範囲）ライン方式=「行= "（位置/範囲）整合性チェック=（長スキーム/ MD5-方式）"、 "MIME-文字セット】位置=番号範囲=（位置"、 "[位置]）/（"、」位置）数= 1 *（DIGIT）長スキーム= "長さ=" 数のMD5方式= "MD5 =" MD5値MD5値= 32HEXDIG
An integrity check can either specify a MIME entity's length, or its MD5 fingerprint. In both cases, it can optionally specify the character encoding that has been used when calculating the integrity check, so that clients interpreting the fragment identifier may check whether they are using the same character encoding for their calculations. For lengths, the character encoding can be necessary because it can influence the character count. As an example, Unicode includes precomposed characters for writing Vietnamese, but in the windows-1258 encoding, also used for writing Vietnamese, some characters have to be encoded with separate diacritics, which means that two characters will be counted. Applying Unicode terminology, this means that the length of a text/plain MIME entity is computed based on its "code points". For MD5 fingerprints, the character encoding is necessary because the MD5 algorithm works on the binary representation of the text/plain resource.
整合性チェックは、MIMEエンティティの長さ、またはそのMD5フィンガープリントを指定することができます。フラグメント識別子を解釈するクライアントは、彼らが彼らの計算のための同じ文字エンコーディングを使用しているかどうかをチェックすることができるように、両方の場合において、それは、必要に応じて、整合性チェックを算出する際に使用されている文字コードを指定することができます。それは文字カウントに影響を与えることができるので、長さのために、文字エンコーディングが必要になることができます。一例として、Unicodeがベトナム語を書き込むための合成済み文字を含むが、Windows-1258エンコーディングに、またベトナムの書き込みに使用、一部の文字が2つの文字がカウントされることを意味し、別発音区別符号で符号化されなければなりません。ユニコード用語を適用すること、これはtext / plainのMIMEエンティティの長さは、その「符号点」に基づいて計算されることを意味します。 MD5アルゴリズムは、text / plainのリソースのバイナリ表現に取り組んでいますので、MD5フィンガープリントの場合は、文字エンコーディングが必要です。
To allow future changes to this specification to address developments in cryptography, implementations MUST ignore new types of integrity checks, with names other than 'length' and 'md5'. If several integrity checks are present, an application can use whatever integrity checks it understands, and among these, those integrity checks that provide an appropriate trade-off between performance and the need for integrity checking. Please see Section 4.3 for further details.
この仕様の将来の変更は、暗号技術の発展に対処できるようにするために、実装は、「長さ」と「MD5」以外の名前を持つ整合性チェックの新しいタイプを、無視しなければなりません。いくつかの整合性チェックが存在する場合、アプリケーションは、それが理解どんな整合性チェックを使用して、することができ、これらの中で、パフォーマンスと整合性の必要性チェックの間の適切なトレードオフを提供し、それらの整合性をチェックします。詳細については、セクション4.3を参照してください。
The length of a text/plain MIME entity is calculated by using the principles defined in Section 2.1.2. The MD5 fingerprint of a text/ plain MIME entity is calculated by using the algorithm presented in [1], encoding the result in 32 hexadecimal digits (using uppercase or lowercase letters) as a representation of the 128 bits that are the result of the MD5 algorithm. Calculation of integrity checks is done after stripping any potential content-encodings or content-transfer-encodings of the transport mechanism.
text / plainのMIME実体の長さは、セクション2.1.2で定義された原理を用いて算出されます。 text / plainのMIMEエンティティがMD5の結果である128ビットの表現として32桁の16進数（大文字または小文字を使用して）、結果をコードする、[1]に示されたアルゴリズムを用いて算出されるのMD5フィンガープリントアルゴリズム。整合性チェックの計算は、潜在的なコンテンツ・エンコーディングまたはトランスポートメカニズムのコンテンツ転送エンコーディングを剥離した後に行われます。
Applications implementing support for the mechanism described in this memo MUST behave as described in the following sections.
次のセクションで説明するように、このメモで説明するメカニズムのサポートを実装するアプリケーションは動作しますしなければなりません。
In Internet messages, line endings in text/plain MIME entities are represented by CR+LF character sequences (see RFC 2046 [3] and RFC 3676 [6]). However, some protocols (such as HTTP) additionally allow other conventions for line endings. Also, some operating systems store text/plain entities locally with different line endings (in most cases, Unix uses LF, MacOS traditionally uses CR, and Windows uses CR+LF).
インターネットメッセージで、text / plainのMIMEエンティティで行末がCR + LF文字の配列によって表される（RFC 2046参照[3]及びRFC 3676 [6]）。しかしながら、（例えば、HTTPなどの）いくつかのプロトコルは、さらに、行末のための他の規則を可能にします。また、一部のオペレーティング・システムストア異なる行末（ほとんどの場合、UnixはLFを使用して、MacOSのは、伝統的にCRを使用し、WindowsがCR + LFを使用しています）でローカルにtext / plainのエンティティ。
Independent of the number of bytes or characters used to represent a line ending, each line ending MUST be counted as one single character. Implementations interpreting text/plain fragment identifiers MUST take into account the line ending conventions of the protocols and other contexts that they work in.
終了行を表すために使用されるバイト数または文字の数とは無関係に、終了各行は、単一の文字としてカウントされなければなりません。 text / plainのフラグメント識別子を解釈する実装は考慮に入れ、彼らがで働くプロトコルや他のコンテキストの規則を終了ラインを取る必要があります。
As an example, an implementation working in the context of a Web browser supporting http: URIs has to support the various line ending conventions permitted by HTTP. As another example, an implementation used on local files (e.g., with the file: URI scheme) has to support the conventions used for local storage. All implementations SHOULD support the Internet-wide CR+LF line ending convention, and MAY support additional conventions not related to the protocols or systems they work with.
例として、HTTPをサポートしたWebブラウザでの作業の実装：URIは、HTTPで許可され、さまざまな行末規則をサポートする必要があります。別の例として、（ファイルと例えば、：URIスキーム）ローカルファイルで使用される実装は、ローカルストレージに使用規則をサポートする必要があります。すべての実装は大会を終了、インターネット全体のCR + LFのラインをサポートすべきである、と彼らはで動作するプロトコルまたはシステムに関連していない追加の規則をサポートするかもしれません。
Implementers should be aware of the fact that line endings in plain text entities can be represented by other characters or character sequences than CR+LF. Besides the abovementioned CR and LF, there are also NEL and CR+NEL. In general, the encoding of line endings can also depend on the character encoding of the MIME entity, and implementations have to take this into account where necessary.
実装者はプレーンテキストエンティティで行末はCR + LF以外の文字や文字列で表すことができるという事実を知っておく必要があります。上記CRとLF以外に、NELおよびCR + NELもあります。一般的には、行末のエンコーディングも、MIMEエンティティの文字エンコーディングに依存することができ、かつ実装が必要な場合には、このことを考慮しなければなりません。
If any position value (as a position or as part of a range) is greater than the length of the actual MIME entity, then it identifies the last character position or line position of the MIME entity. If the first position value in a range is not present, then the range extends from the start of the MIME entity. If the second position value in a range is not present, then the range extends to the end of the MIME entity. If a range scheme's positions are not properly ordered (i.e., the first number is less than the second), then the fragment identifier MUST be ignored.
任意の位置の値（位置として、または範囲の一部として）実際のMIMEエンティティの長さよりも大きい場合、それは最後の文字位置又はMIMEエンティティのライン位置を特定します。範囲内の最初の位置の値が存在しない場合は、範囲は、MIMEエンティティの開始から延びています。範囲内の第二の位置の値が存在しない場合は、範囲は、MIMEエンティティの端部まで延びています。レンジ方式の位置が適切に（すなわち、最初の数が第2未満である）順序付けされていない場合は、フラグメント識別子を無視しなければなりません。
Clients are not required to implement the handling of integrity checks, so they MAY choose to ignore integrity check information altogether. However, if they do implement integrity checking, the following applies:
クライアントは、整合性チェックの処理を実装するために必要とされていないので、彼らは完全に整合性チェックの情報を無視することを選択するかもしれません。彼らは整合性チェックを実装行う場合は、以下が適用されます。
If a fragment identifier contains one or more integrity checks, and a client retrieves a MIME entity and, using some integrity check(s), detects that the entity has changed (observing the character encoding specification as described in Section 3.1, if present), then the client SHOULD NOT interpret the text/plain fragment identifier. A client MAY signal this situation to the user.
フラグメント識別子は、1つまたは複数の整合性のチェックが含まれており、クライアントは、MIMEエンティティを検索し、いくつかの整合性チェック（複数可）を使用した場合は、（存在する場合、セクション3.1で説明したように文字コード仕様を観察）エンティティが変更されたことを検出し、その後、クライアントは、text / plainのフラグメント識別子を解釈すべきではありません。クライアントは、ユーザにこのような状況を知らせることができます。
If a fragment identifier contains a syntax error (i.e., does not conform to the syntax specified in Section 3), then it MUST be ignored by clients. Clients MUST NOT make any attempt to correct or guess fragment identifiers. Syntax errors MAY be reported by clients.
フラグメント識別子（すなわち、セクション3で指定された構文に準拠していない）構文エラーが含まれている場合、それはクライアントによって無視されなければなりません。クライアントは、フラグメント識別子を修正するかを推測しようとする試みをしてはなりません。構文エラーは、クライアントによって報告されてもよいです。
The following examples show some usages for the fragment identifiers defined in this memo.
次の例では、このメモで定義されたフラグメント識別子のためのいくつかの使用方法を示しています。
http://example.com/text.txt#char=100
ｈっｔｐ：／／えぁｍｐぇ。こｍ／てｘｔ。ｔｘｔ＃ちゃｒ＝１００
This URI identifies the position after the 100th character of the text.txt MIME entity. It should be noted that it is not clear which octet(s) of the MIME entity this will be without retrieving the MIME entity and thus knowing which character encoding it is using (in case of HTTP, this information will be given in the Content-Type header of the response). If the MIME entity has fewer than 100 characters, the URI identifies the position after the MIME entity's last character.
このURIはTEXT.TXTのMIMEエンティティの100番目の文字の後に位置を特定します。 HTTPの場合には、この情報は、たContentに説明する（ただし、これは、それが使用しているコードどの文字MIME実体を検索し、従って知らなくなりMIMEエンティティのどのオクテット（s）は明らかではないことに留意すべきです応答のタイプヘッダ）。 MIMEエンティティが100文字未満を持っている場合は、URIは、MIMEエンティティの最後の文字の後に位置を特定します。
http://example.com/text.txt#line=10,20
ｈっｔｐ：／／えぁｍｐぇ。こｍ／てｘｔ。ｔｘｔ＃ぃね＝１０、２０
This URI identifies lines 11 to 20 of the text.txt MIME entity. If the MIME entity has fewer than 11 lines, it identifies the position after the last line. If the MIME entity has less than 20 but at least 11 lines, it identifies the range from line 11 to the last line of the MIME entity.
このURIはTEXT.TXTのMIMEエンティティの20にライン11を識別する。 MIMEエンティティが11行よりも少ないを持っている場合、それは最後の行の後に位置を特定します。 MIMEエンティティが20未満であるが、少なくとも11行を持っている場合、それはライン11からMIMEエンティティの最後の行までの範囲を特定します。
https://example.com/text.txt#line=,1
ｈっｔｐｓ：／／えぁｍｐぇ。こｍ／てｘｔ。ｔｘｔ＃ぃね＝、１
This URI identifies the first line. Please note that the URI scheme has been changed to https.
このURIは、最初の行を識別します。 URIスキームがhttpsに変更されていることに注意してください。
ftp://example.com/text.txt#line=10,20;length=9876,UTF-8
ｆｔｐ：／／えぁｍｐぇ。こｍ／てｘｔ。ｔｘｔ＃ぃね＝１０、２０；ぇんｇｔｈ＝９８７６、うＴＦー８
As in the second example, this URI identifies lines 11 to 20 of the text.txt MIME entity. The additional length integrity check specifies that the MIME entity has a length of 9876 characters when encoded in UTF-8. If the client supports the length scheme, it may test the retrieved MIME entity for its length, but only if the retrieved MIME entity uses the UTF-8 encoding or has been locally transcoded into this encoding.
第二の例のように、このURIはTEXT.TXTのMIMEエンティティの20にライン11を識別する。追加の長さの整合性チェックは、UTF-8でエンコードされたときにMIMEエンティティは9876文字の長さを持っていることを指定します。クライアントは、長さ・スキームをサポートしている場合、それは、その長さのために取得したMIMEエンティティをテストすることがありますが、取得したMIMEエンティティは、UTF-8エンコーディングを使用するか、またはローカルでこのエンコーディングにトランスコードされている場合のみ。
Please note that the FTP protocol, as well as some other protocols underlying some other URI schemes, do not provide explicit information about the media type of the resource being retrieved. Using fragment identifiers with such URI schemes is therefore inherently unreliable. Current user agents use various heuristics to infer some media type for further processing. Processing of the fragment identifier according to this memo is only appropriate if the inferred media type is text/plain.
FTPプロトコルだけでなく、他のいくつかのURIスキームの基礎となるいくつかの他のプロトコルは、取得されたリソースのメディアタイプについての明示的な情報を提供しないことに注意してください。そのようなURIスキームでフラグメント識別子を使用すると、それゆえ、本質的に信頼できません。現在のユーザーエージェントは、さらなる処理のためのいくつかのメディアタイプを推測するために、さまざまなヒューリスティックを使用します。推論されたメディアタイプがtext / plainである場合、このメモに係るフラグメント識別子の処理は、適切です。
IANA has added a reference to this specification in the text/plain Media Type registration.
IANAは、text / plainのメディアタイプの登録でこの仕様への参照を追加しました。
The fact that software implementing fragment identifiers for plain text and software not implementing them differs in behavior, and the fact that different software may show documents or fragments to users in different ways, can lead to misunderstandings on the part of users. Such misunderstandings might be exploited in a way similar to spoofing or phishing.
プレーンテキストおよびソフトウェアのためのソフトウェア実装フラグメント識別子がそれらを実装していないという事実は、行動に異なり、異なるソフトウェアはさまざまな方法でユーザーに文書またはフラグメントを示し得るという事実は、ユーザーの一部に誤解につながることができます。このような誤解は、なりすましやフィッシングと同様の方法で悪用される可能性があります。
In particular, care has to be taken if fragment identifiers are used together with a mechanism that allows showing only the part of a document identified by a fragment. One scenario may be the use of a fragment identifier to hide small-print legal text. Another scenario may be the inclusion of site-key-like material, which may give the user the impression of using the real site rather than a fake site; other scenarios may also be possible. Possible countermeasures may include but are not limited to displaying the included content within clearly visible boundaries and limiting inclusion to material from the same security realm or from realms that give explicit permission to be included in another realm.
具体的には、ケアは、フラグメント識別子を断片によって識別文書の一部のみを示す可能メカニズムと一緒に使用される場合に注意しなければなりません。 1つのシナリオは、小プリント法的テキストを非表示にするフラグメント識別子を使用してもよいです。別のシナリオは、ユーザーに偽のサイトではなく、本物のサイトを利用しての印象を与えることがあり、サイトの鍵状の材料を含めることであってもよいです。他のシナリオも可能です。可能な対策としては、はっきりと目に見える境界内に含まれるコンテンツを表示し、同じセキュリティ領域から、または別の領域に含まれる明示的な許可を与えるレルムから材料への混入を制限することに限定されないことがあります。
Please note that the above issues all apply to the client side; fragment identifiers are not used when resolving a URI to retrieve the representation of a resource, but are only applied on the client side.
上記の問題は、すべてのクライアント側に適用されますのでご注意ください。フラグメント識別子は、URIを解決するときに、リソースの表現を取得するために使用されていないが、唯一のクライアント側で適用されています。
Implementers and users of fragment identifiers for plain text should also be aware of the security considerations in RFC 3986 [7] and RFC 3987 [8].
プレーンテキストのための実装およびフラグメント識別子のユーザーも、RFC 3986のセキュリティ上の考慮事項に注意する必要があります[7]およびRFC 3987 [8]。
[1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[1]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[2]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[3]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[5]フリード、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2978、2000年10月。
[6] Gellens, R., "The Text/Plain Format and DelSp Parameters", RFC 3676, February 2004.
[6] Gellens、R.、 "text / plainの形式とDelSpパラメータ"、RFC 3676、2004年2月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[7]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[8] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRI)", RFC 3987, January 2005.
[8] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[9]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[10] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[10]コノリー、D.およびL. Masinter、 " 'text / htmlの' メディアの種類"、RFC 2854、2000年6月。
[11] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[11]ホフマン、P.及びF. Yergeau、 "UTF-16、ISO 10646の符号化"、RFC 2781、2000年2月。
[12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[12] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[13] ANSI X3.4-1986, "Coded Character Set - 7-Bit American National Standard Code for Information Interchange", 1986.
1986年 - [13] ANSI X3.4-1986、「情報交換のための7ビットの米国標準コード文字セットをコード化されました」。
[14] DeRose, S., Maler, E., and D. Orchard, "XML Linking Language (XLink) Version 1.0", World Wide Web Consortium Recommendation, June 2001, <http://www.w3.org/TR/xlink/>.
[14] DeRose、S.、MALER、E.、およびD.オーチャード、 "XMLリンク言語（XLinkの）バージョン1.0"、World Wide Web Consortium（W3C）の勧告、2001年6月、<http://www.w3.org/TR / XLINK />。
[15] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[15]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
Appendix A. Acknowledgements
付録A.謝辞
Thanks for comments and suggestions provided by Marcel Baschnagel, Stephane Bortzmeyer, Tim Bray, Iain Calder, John Cowan, Spencer Dawkins, Lisa Dusseault, Benja Fallenstein, Ted Hardie, Sam Hartman, Sandro Hawke, Jeffrey Hutzelman, Cullen Jennings, Graham Klyne, Dan Kohn, Henrik Levkowetz, Chris Newman, Mark Nottingham, Conrad Parker, and Tim Polk.
マルセルBaschnagel、ステファンBortzmeyer、ティム・ブレイ、イアン・カルダー、ジョン・コーワン、スペンサードーキンスリサDusseault、ベンジャFallenstein、テッドハーディー、サム・ハートマン、サンドロ・ホーク、ジェフリーHutzelman、カレン・ジェニングス、グラハムKlyne、ダンが提供する意見やご提案をお寄せいただきありがとうございますコーン、ヘンリクLevkowetz、クリス・ニューマン、マーク・ノッティンガム、コンラッド・パーカー、そしてティムポーク。
Authors' Addresses
著者のアドレス
Erik Wilde UC Berkeley School of Information, 311 South Hall Berkeley, CA 94720-4600 U.S.A.
情報のエリック・ワイルドUCバークレー校、311南ホールバークレー、CA 94720から4600 U.S.A.
Phone: +1-510-6432253 EMail: dret@berkeley.edu URI: http://dret.net/netdret/
電話：+ 1-510-6432253 Eメール：dret@berkeley.edu URI：http://dret.net/netdret/
Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.) Aoyama Gakuin University 5-10-1 Fuchinobe Sagamihara, Kanagawa 229-8558 Japan
マーティンDuerst（注：。、可能な限りのuウムラウトで「Duerstを」書く「D＆＃252; RST」として例えば下さいXMLとHTMLで）青山学院大学5-10-1淵野辺相模原市、神奈川県229から8558日本
Phone: +81 42 759 6329 Fax: +81 42 759 6495 EMail: duerst@it.aoyama.ac.jp URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
電話：+81 42 759 6329ファックス：+81 42 759 6495 Eメール：URI duerst@it.aoyama.ac.jp：http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。