[要約] RFC 5147は、テキスト/プレーンメディアタイプのためのURIフラグメント識別子に関する仕様です。このRFCの目的は、テキスト文書内の特定のフラグメントを識別し、直接リンクするための方法を提供することです。
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
テキスト/プレーンメディアタイプのURIフラグメント識別子
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.
このメモは、テキスト/プレーンMIMEエンティティのURIフラグメント識別子を定義します。これらのフラグメント識別子は、文字の位置または範囲、またはラインの位置または範囲で識別されるテキスト/プレーンマイムエンティティの一部を参照することを可能にします。フラグメント識別子には、整合性チェックの情報が含まれている場合があります。
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.
このメモは、テキスト/プレーンMIMEエンティティのURIフラグメント識別子を定義することにより、RFC 2046 [3]で定義されたテキスト/プレーンメディアタイプを更新します。これにより、テキスト/プレーンマイムエンティティの一部を参照できます。このような部品は、文字位置または範囲、またはラインの位置または範囲で識別できます。整合性チェック情報をフラグメント識別子に追加して、より堅牢にし、アプリケーションがエンティティの変更を検出できるようにすることができます。
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.
このセクションでは、テキスト/プレーンMIMEエンティティとURIフラグメント識別子の一般的な概念の紹介を行い、テキスト/プレーンおよび展開の問題のフラグメント識別子の必要性について説明します。セクション2では、このメモの基礎となる原則と方法について説明します。セクション3では、構文を定義し、セクション4でテキスト/プレーンフラグメント識別子の処理について説明します。セクション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 [2]およびRFC 2046 [3]で定義されているインターネットメディアタイプ（「MIMEタイプ」と呼ばれることが多い）は、さまざまなタイプとサブタイプのメディアを識別するために使用されます。RFC 2046 [3]およびRFC 3676 [6]テキスト/プレーンメディアタイプを指定します。これは、シンプルでフォーマットされていないテキストに使用されます。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.
テキスト/プレーンメディアタイプは、文字エンコードを制限しません。キャラクターエンコーディングを使用できます。宣言をコードする明示的な文字が存在しない場合、us-ascii [13]はデフォルトの文字エンコードとして想定されます。キャラクターエンコードのこの変動性により、文字を考慮せずにテキスト/プレーンマイムエンティティのキャラクターをカウントすることは不可能になります。
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.
テキスト/プレーンマイムエンティティの最大の利点は、それらの使いやすさとさまざまなプラットフォーム間の携帯性です。人気のあるキャラクターエンコーディング（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 [7]で指定されたURI構文には、オプションで、いわゆる「フラグメント識別子」が含まれ、数字符号（ '＃'）で区切られています。フラグメント識別子は、検索アクションが正常に完了した後、ユーザーエージェントによって解釈される追加の参照情報で構成されています。フラグメント識別子のセマンティクスは、参照で使用される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.
最も人気のあるフラグメント識別子は、Text/HTML（RFC 2854 [10]で定義されている）に定義されており、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.
リソースの特定の部分を参照することは、ユーザーとアプリケーションがより具体的な参照を作成できるため、非常に便利です。ユーザーは、常に完全なリソースを指し示すのではなく、本当に興味がある、または話したい部分への参照を作成できます。フラグメント識別方法はメディアタイプのMIME登録で指定されていることが示唆されていますが（[15]を参照）、多くのメディアタイプにはそれらに関連するフラグメント識別方法がありません。
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.
このメモで定義されているテキスト/プレーンのフラグメント識別子は、文字や線に適用される可能性のある位置と範囲の概念を使用して、テキスト/プレーンマイムエンティティの特定の部分を参照することを可能にします。したがって、テキスト/プレーンフラグメント識別子により、ユーザーは情報をより具体的に交換できるようになり、テキスト/プレーンマイムエンティティの関連する部分を手動で検索するために必要な時間と労力を減らすことができます。
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.
テキスト/プレーン形式はリンクの埋め込みをサポートしていないため、ほとんどの環境では、テキスト/プレーンリソースはリンクのターゲットとしてのみ機能し、ソースとしてではありません。ただし、このメモで指定されたテキスト/プレーンフラグメント識別子をXlink [14]などのアウトオブラインリンクメカニズムと組み合わせると、リソースをテキスト/プレーンリソースにリンクする「バインド」し、それによって「リンク」を「埋め込む」ことができます。テキスト/プレーンリソース。したがって、このメモで指定されたテキスト/プレーンフラグメント識別子は、テキスト/プレーンファイルがWebなどのHyperMediaシステムで双方向的に航行可能なリソースになるためのパスを開きます。
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.
テキスト/プレーンフラグメントの識別子が普遍的にサポートされていない限り、増分展開の意味を考慮することが重要です。このメモに記載されているテキスト/プレーンフラグメント識別子をサポートしていないクライアント（たとえば、Webブラウザー）は、テキスト/プレーンマイムエンティティへの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].
このドキュメントの「必須」、「必要」、「必須」、「必要」、「shall」、「shall "、" sulld "、" low "of"、 "bulsed"、 "becomperded"、 "optional」RFC 2119 [4]に記載されているように解釈されるべきです。
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.
テキスト/プレーンマイムエンティティの断片の識別は、さまざまな基礎に基づいています。明示的で見えない識別子をテキスト/プレーンMIMEエンティティ（たとえば、HTMLドキュメントで使用され、専用の属性を介して実装されている）に挿入することはできないため、フラグメント識別は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.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存在内のポジションを識別します。ポジションのユースケースは、フラグメントではなくポジションを必要とする「ここにテキストを挿入する」などの機能を実装するためにそれらを使用する可能性のあるアプリケーションのポインターを提供することです。位置はゼロからカウントされます。ゼロは、テキスト/プレーンマイムエンティティの最初のキャラクターまたはラインの前にあります。したがって、1つのキャラクターを持つテキスト/プレーンマイムエンティティには2つのポジションがあります。1つは最初のキャラクター（位置ゼロ）、もう1つは最初のキャラクター（位置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エンティティの実際の要素の数よりも大きい場合、MIMEエンティティの最後の要素を参照していると暗黙的に想定されています（詳細についてはセクション4を参照）。
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).
キャラクターの位置には、ゼロから始まります（テキスト/プレーンマイムエンティティの実際のテキストコンテンツの一部ではない初期ボムマークまたは同様の概念を無視し、各文字を個別にカウントします。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文字の間の長さゼロの断片）を識別するために、「char」スキームに続く単一の数字が使用されます。このメソッドは、多くの文字で構成されるフラグメントを識別するのではなく、2つの文字の間（または最初の文字の前または最後の文字の前）の間の位置を識別します。キャラクターの位置カウントはゼロで始まるため、テキスト/プレーンマイムエンティティの最初の文字の前の文字位置は文字位置ゼロを持ち、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.
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行の間の長さゼロの断片）を識別するために、「線」スキームに続く単一の数値が使用されます。このメソッドは、多くの行で構成されるフラグメントを識別するのではなく、2行の間の位置を識別します。ライン位置カウントはゼロで始まるため、テキスト/プレーンマイムエンティティの最初の行の前のライン位置にはライン位置がゼロになり、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.
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.
Integrity-Check情報は、情報の作成時に使用された文字エンコードを指定する場合があり、そのような仕様が存在する場合、クライアントは指定されたキャラクターと取得したMIMEエンティティのキャラクターエンコードが等しいかどうかを確認する必要があります。これらの値が異なる場合は、整合性チェック情報を使用します。ただし、クライアントは、異なるキャラクターエンコーディングの場合に検索されたMIMEエンティティをトランスコードすることを選択し、その後、整合性チェックを適用します。特定の文字または文字シーケンスが使用されている文字エンコーディングの1つの制限のために失われたり正規化されたりした可能性があるため、この方法は本質的に信頼できないことに注意してください。
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.
テキスト/プレーンフラグメント識別子の構文は簡単です。構文は、「char」、「line」、および整合性チェック（「長さ」または「md5」のいずれか）の4つのスキームを定義します。「char」および「line」スキームは、位置バリアント（単一の数字を含む）または範囲バリアント（2つのコンマ区切り数）の2つの異なるバリアントで使用できます。整合性チェックは、「長さ」または「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].
次の構文定義では、RFC 5234 [9]で定義されているABNFを使用します。MIME-Charsetルールは、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
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つのキャラクターがカウントされます。Unicode用語を適用すると、これは、テキスト/プレーンMIMEエンティティの長さが「コードポイント」に基づいて計算されることを意味します。MD5の指紋の場合、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.
テキスト/プレーンMIMEエンティティの長さは、セクション2.1.2で定義されている原則を使用して計算されます。テキスト/プレーンマイムエンティティのMD5指紋は、[1]で提示されたアルゴリズムを使用して計算され、MD5の結果である128ビットの表現として、32六分野（大文字または小文字を使用）の結果をエンコードすることで計算されます。アルゴリズム。整合性チェックの計算は、潜在的なコンテンツエンコーディングまたは輸送メカニズムのコンテンツ移動エンコードを削除した後に行われます。
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).
インターネットメッセージでは、テキスト/プレーンMIMEエンティティのラインエンディングは、CR LF文字シーケンスで表されます（RFC 2046 [3]およびRFC 3676 [6]を参照）。ただし、一部のプロトコル（HTTPなど）はさらに、ラインエンディングの他の規則を許可します。また、一部のオペレーティングシステムは、さまざまなラインエンディングを持つテキスト/プレーンエンティティをローカルに保存します（ほとんどの場合、UNIXはLFを使用し、MacOSは従来CRを使用し、WindowsはCR LFを使用します）。
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.
ラインエンディングを表すために使用されるバイトまたは文字の数とは無関係に、各ラインエンディングは1つの文字としてカウントする必要があります。テキスト/プレーンフラグメント識別子の解釈の実装では、プロトコルやその他のコンテキストの継続的な条約を考慮に入れる必要があります。
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：URISをサポートするWebブラウザのコンテキストで動作する実装は、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エンティティの開始から拡張されます。範囲内の2番目の位置値が存在しない場合、範囲は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で説明されているように仕様をエンコードする文字を遵守します）、次に、クライアントはテキスト/プレーンフラグメント識別子を解釈してはなりません。クライアントは、この状況をユーザーに知らせることができます。
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番目の文字の後の位置を識別します。MIMEエンティティのどのオクテットがMIMEエンティティを取得せず、それが使用しているキャラクターを知っていることを明確ではないことに注意する必要があります（HTTPの場合、この情報はコンテンツに記載されます - 応答のヘッダーを入力します）。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エンティティの11〜20行目を識別します。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.
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スキームを使用してフラグメント識別子を使用することは、本質的に信頼できません。現在のユーザーエージェントは、さまざまなヒューリスティックを使用して、さらに処理するためにメディアタイプを推測します。このメモによるフラグメント識別子の処理は、推定されたメディアタイプがテキスト/プレーンである場合にのみ適切です。
IANA has added a reference to this specification in the text/plain Media Type registration.
IANAは、テキスト/プレーンメディアタイプの登録にこの仕様への参照を追加しました。
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] Rivest、R。、「The Md5 Message-Digest Algorithm」、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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[3] Freed、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[5] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、2000年10月。
[6] Gellens, R., "The Text/Plain Format and DelSp Parameters", RFC 3676, February 2004.
[6] Gellens、R。、「The Text/Plain Format and 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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[8] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRI)", RFC 3987, January 2005.
[8] Duerst、M。and M. Suignard、「Internationalized Resource Identifiers（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] Crocker、D.、ed。および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] Connolly、D。およびL. Masinter、「The 'Text/HTML' Media Type」、RFC 2854、2000年6月。
[11] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[11] Hoffman、P。and 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.
[13] ANSI X3.4-1986、「コード化された文字セット-7ビットアメリカ国立標準コードの情報交換」、1986年。
[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. Orchard、「XML Linking Language（Xlink）バージョン1.0」、World Wide Webコンソーシアムの推奨、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] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
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.
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、GrahamningsKohn、Henrik Levkowetz、Chris Newman、Mark Nottingham、Conrad Parker、およびTim Polk。
Authors' Addresses
著者のアドレス
Erik Wilde UC Berkeley School of Information, 311 South Hall Berkeley, CA 94720-4600 U.S.A.
エリックワイルドUCバークレー情報、311サウスホールバークレー、カリフォルニア94720-4600 U.S.A.
Phone: +1-510-6432253
EMail: 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
Martin Duerst（注：可能な限りU-Umlaut、たとえば「D＆＃252; rst」としてu-umlautで「Duerst」を書いてください。
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/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。