RFC5147 日本語訳
5147 URI Fragment Identifiers for the text/plain Media Type. E. Wilde,M. Duerst. April 2008. (Format: TXT=37422 bytes) (Updates RFC2046) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Wilde
Request for Comments: 5147 UC Berkeley
Updates: 2046 M. Duerst
Category: Standards Track Aoyama Gakuin University
April 2008
コメントを求めるワーキンググループE.ワイルド要求をネットワークでつないでください: 5147のUCバークレーアップデート: 2046年のM.Duerstカテゴリ: 標準化過程青山学院大学2008年4月
URI Fragment Identifiers for the text/plain Media Type
テキスト/明瞭なメディアTypeのためのURI Fragment Identifiers
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 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断片識別子を定義します。 これらの断片識別子は、欄か範囲によって特定されるか、線位置のどちらかのそばでテキスト/明瞭なMIME実体の部品について言及するのを可能にするか、または及びます。 また、断片識別子は保全チェックがそれらをより強健にする情報を含むかもしれません。
Wilde & Duerst Standards Track [Page 1] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[1ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 どんなIsテキスト/平野? . . . . . . . . . . . . . . . . . . . 3 1.2. URI断片識別子は何ですか? . . . . . . . . . . . . 4 1.3. なぜテキスト/明瞭なFragment Identifiers? . . . . . . . . . . . 4 1.4. 増加の展開. . . . . . . . . . . . . . . . . . 5 1.5。 このメモ. . . . . . . . . . . . . . . . 5 2で使用される記法。 同定法. . . . . . . . . . . . . . . 5 2.1を断片化してください。 識別プリンシプルズ. . . . . . . . . . . . 6 2.1.1を断片化してください。 位置と範囲. . . . . . . . . . . . . . . . . 6 2.1.2。 キャラクターと線. . . . . . . . . . . . . . . . . 7 2.2。 プリンシプルズ. . . . . . . . . . . . . . . . . 7 2.2.1を結合します。 欄. . . . . . . . . . . . . . . . . . 7 2.2の.2。 キャラクター範囲. . . . . . . . . . . . . . . . . . . 8 2.2.3。 位置. . . . . . . . . . . . . . . . . . . . 8 2.2の.4を裏打ちしてください。 範囲. . . . . . . . . . . . . . . . . . . . . . 8 2.3を裏打ちしてください。 識別子丈夫さ. . . . . . . . . . . . . . 8 3を断片化してください。 識別構文. . . . . . . . . . . . . . . . 9 3.1を断片化してください。 保全は.9 4をチェックします。 識別子処理. . . . . . . . . . . . . . . . 10 4.1を断片化してください。 テキスト/明瞭なMIME Entities. . . 10 4.2の線Endingsの取り扱い。 位置の取り扱いは.114.3を評価します。 保全の取り扱いは.114.4をチェックします。 断片識別子. . . . . . . . . . 12 5の構文エラー。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 13 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 14 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 14付録A.承認. . . . . . . . . . . . . . . . . . 16
Wilde & Duerst Standards Track [Page 2] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[2ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
1. Introduction
1. 序論
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.
このメモはRFC2046[3]でテキスト/明瞭なMIME実体のためのURI断片識別子を定義することによって定義されたテキスト/明瞭なメディアタイプをアップデートします。 これで、テキスト/明瞭な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.
このセクションはテキスト/明瞭なMIME実体とURI断片識別子に関する一般概念に序論を与えます、そして、それはテキスト/平野と展開問題のための断片識別子の必要性について議論します。 セクション2はこのメモが基づいている原則と方法を論じます。 セクション3は構文を定義します、そして、セクション4はテキスト/明瞭な断片識別子の処理について議論します。 セクション5はいくつかの例を示しています。
1.1. What Is text/plain?
1.1. どんなIsテキスト/平野?
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".
RFC2045[2]とRFC2046[3]で定義されるインターネットメディアTypes(しばしば「MIMEの種類」と呼ばれる)は、異なったタイプとサブタイプのメディアを特定するのに使用されます。 RFC2046[3]とRFC3676[6]はテキスト/明瞭なメディアタイプを指定します。(タイプは簡単で、非フォーマットされたテキストに使用されます)。 RFC2046[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.
テキスト/明瞭なメディアタイプはキャラクタコード化を制限しません。 どんなキャラクタコード化も使用されるかもしれません。 宣言をコード化する明白なキャラクタがないとき、米国-ASCII[13]はデフォルトキャラクタコード化として想定されます。 キャラクタコード化のこの可変性でキャラクタコード化を考慮に入れないでテキスト/明瞭なMIME実体でキャラクタを数えるのは不可能になります、1キャラクタあたり1つ以上の八重奏を使用する多くのキャラクタencodingsがあるので。
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.
ポピュラーなキャラクタencodingsを使用するとき、長い間、テキスト/明瞭なMIME実体の最も大きい利点は、異なったプラットホームAsの中のそれらの使いやすさと自己の携帯性です。(そのような米国の同じくらいASCIIかUTF-8[12])、実際にはあらゆるコンピュータ・システムにそれらは、表示して、処理できます。 唯一の残っている相互運用性問題が線結末の表現です。(セクション4.1でその表現について議論します)。
Wilde & Duerst Standards Track [Page 3] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[3ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
1.2. What Is a URI Fragment Identifier?
1.2. URI断片識別子は何ですか?
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はウェブに関するリソースのための識別メカニズムです。 RFC3986[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.
最もポピュラーな断片識別子はテキスト/htmlのために定義されます。(HTMLドキュメントでRFCで2854[10])を定義して、特定の要素を示すのを可能にします('名前'か'イド'属性の値で、特定されます)。 これで、全体でウェブページよりむしろウェブページの特定の地域に参照をつけるのは可能になります。
1.3. Why text/plain Fragment Identifiers?
1.3. なぜテキスト/明瞭なFragment Identifiers?
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.
テキスト/明瞭なMIME実体の特定の部品について言及するのはテキスト/平野のためのこのメモで定義される断片識別子で可能になります、キャラクタと線に適用されるかもしれない位置と範囲の概念を使用して。 したがって、テキスト/明瞭な断片識別子は、ユーザが、より明確に情報交換するのを可能にします、その結果、手動でテキスト/明瞭なMIME実体の関連部分を捜し求めるのに必要な時間と努力を短縮します。
Wilde & Duerst Standards Track [Page 4] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[4ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
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]などの法外なリンクメカニズムに結合するとき、テキスト/明瞭なリソースにリンクリソースを「縛っ」て、その結果、リンクがテキスト/明瞭なリソースに「埋め込み」であることは可能になります。 したがって、このメモで指定されたテキスト/明瞭な断片識別子は、テキスト/明瞭なファイルがウェブなどのハイパーメディアシステムの双方向に航海可能なリソースになるように小道を切り開きます。
1.4. Incremental Deployment
1.4. 増加の展開
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.
テキスト/明瞭な断片識別子が一般に支持されない限り、増加の展開の含意を考えるのは重要です。 このメモで説明されたテキスト/明瞭な断片識別子を支持していないクライアント(例えば、ウェブブラウザ)がテキスト/明瞭なMIME実体のURI参照で働くでしょうが、それらは断片識別子によって特定されたサブリソースの場所を見つけないでしょう。 これは合理的な後退の振舞いです、そして、一般に、ユーザは与えられたURIを解釈するプログラムが断片識別子部分を解釈しない可能性を考慮に入れるべきです。 クライアント(そして、MIME実体を検索した後に、起こる)にとって、断片識別子評価がローカルであるので、サーバが、要求しているクライアントが断片識別子を含むURIを使用しているかどうか決定するどんな信頼できる方法もありません。
1.5. Notation Used in This Memo
1.5. このメモで使用される記法
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[4]で説明されるように本書では解釈されることであるべきですか?
2. Fragment Identification Methods
2. 断片同定法
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実体の断片の識別は異なった基礎に基づくことができます。 テキスト/明瞭なMIME実体に明白で、目に見えない識別子を挿入するのが可能でないので(例えばひたむきな属性を通して実行されたHTMLドキュメントで使用されるように)、断片識別はMIME実体のある固有の特性を当てにしなければなりません。 このメモは欄である4つの異なった方法を使用することで断片識別を指定します、そして、範囲、線位置、および範囲は、断片識別子の丈夫さを改良するために保全チェックメカニズムで増大しました。
Wilde & Duerst Standards Track [Page 5] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[5ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年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コード化を使用するMIME実体、(多くの場合、[11])が1キャラクタあたり2つの八重奏に使用するRFC2781、および時々1キャラクタあたり4つの八重奏に指定されるように。 それは、また、主なBOM(マークをバイト命令する)を持つことができて、その結果、また、簡単な八重奏カウントからキャラクタカウントまでマッピングに影響します。(BOMはキャラクタにみなしません)。
2.1. Fragment Identification Principles
2.1. 断片識別原則
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は原則の組み合わせについて説明します。
2.1.1. Positions and Ranges
2.1.1. 位置と範囲
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実体における位置を特定します。(実体を長さゼロの断片と見なすことができます)。 位置へのケースが機能性を実行するそれらを使用するかもしれないアプリケーションのためのポインタを提供することになっている使用は「何らかのテキストをここに挿入する」(断片よりむしろ位置を必要とします)。 位置はゼロから数えられます。 テキスト/明瞭なMIME実体の最初のキャラクタか線の前に存在を置かないでください。 したがって、1つのキャラクタがあるテキスト/明瞭なMIME実体は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).
位置が長さゼロの断片であるので、アプリケーションSHOULDは位置を示すのにハイライト以外の方法を使用します、最も明白な道がカーソルの位置決め(アプリケーションがカーソルの概念を支持するなら)であり。
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実体の断片を特定します。 範囲への一般的な原則として、それらはaが下ろす両方と上限を指定します。 範囲指定の始めか終わりが、1日をデフォルトとして、省略されるか、またはそれぞれMIME実体の位置を持続するかもしれません。 1つの範囲の端で、aは始めをより評価しなければなりません。 同じ始めと終わりがある範囲は、法的であり、さまざまな長さゼロを特定します。(それは、位置に同等です)。
Applications that support a concept such as highlighting SHOULD use such a concept to indicate fragments of lengths greater than zero to the user.
SHOULDを目立たせることなどの概念を支持するアプリケーションは、ゼロ以上の長さの断片をユーザに示すのにそのような概念を使用します。
Wilde & Duerst Standards Track [Page 6] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[6ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
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を見る)とそれとなく思われます。
2.1.2. Characters and Lines
2.1.2. キャラクターと線
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).
欄は、ゼロから始まって、付番されて(テキスト/明瞭なMIME実体の実際の原文の内容の一部でない初期のBOMマークか同様の概念を無視して)、別々に各キャラクタを数えています、線結末を除いて(詳細に関してセクション4.1を見てください)。(結末はいつも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実体がどんな線結末も含んでいないなら、それはただ一つ(1番目)の線から成ります。
2.2. Combining the Principles
2.2. プリンシプルズを合併します。
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で詳細に説明された断片識別子構文を示します。
2.2.1. Character Position
2.2.1. 欄
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つのキャラクタの間の長さゼロの断片)を特定するために、1つの数があとに続いた'炭'計画は使用されています。 この方法は多くのキャラクタから成る断片を特定するよりむしろ2つのキャラクタ(または1番目の前か最後のキャラクタの後に)の間の位置を特定します。 ゼロがある欄の勘定始め、テキスト/明瞭なMIME実体の最初のキャラクタの前の欄には、したがって、欄ゼロがあります、そして、異なったn文字を含むMIME実体はn+1異なった欄を持っています、最後のものには欄nがあって。
Wilde & Duerst Standards Track [Page 7] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[7ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
2.2.2. Character Range
2.2.2. キャラクター範囲
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.
1つ以上のキャラクタ(キャラクタ範囲)の断片を特定するために、範囲指定があとに続いた'炭'計画は使用されています。 キャラクタ範囲は範囲の始めの欄から終わりの範囲の欄に広がるMIME実体の連続した領域です。
2.2.3. Line Position
2.2.3. 線の位置
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つの線の間の長さゼロの断片)を特定するために、1つの数があとに続いた'線'計画は使用されています。 この方法は多くの線から成る断片を特定するよりむしろ2つの線(または1番目の前か最終ラインの後に)の間の見解を特定します。 ゼロがある線位置の勘定始め、線位置には、したがって、線がテキスト/明瞭なMIME実体の最初の線でゼロ、およびn異なった線を含むMIME実体を置く前にn+1異なった線位置があります、最後のものに位置のnの線があって。
2.2.4. Line Range
2.2.4. 線の範囲
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.
1つ以上の線(線範囲)の断片を特定するために、範囲指定があとに続いた'線'計画は使用されています。 線範囲は範囲の仕切り線位置から終わりの範囲の線位置に広がるMIME実体の連続した領域です。
2.3. Fragment Identifier Robustness
2.3. 断片識別子丈夫さ
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実体で定義されます。 これは、保全チェック情報が、ある実体に特定であることを意味します。 明確に、保全チェック情報を使用する前に、内容encodings、そして/または、内容転送encodingsを取り外さなければなりません。
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
情報を作成するとき、保全チェック情報が使用されたキャラクタコード化を指定するかもしれなくて、そのような仕様が存在しているなら、クライアントがチェックしなければならない、キャラクタ
Wilde & Duerst Standards Track [Page 8] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[8ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
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実体のキャラクタコード化は等しいです、そして、これらの値が異なるなら、クライアントは保全チェック情報を使用してはいけません。 クライアントは、異なったキャラクタencodingsに関するケースと、そうした後に、しかしながら、保全チェックを適用するように検索されたMIME実体を「移-コード」に選ぶかもしれません。 確信しているキャラクタかキャラクタシーケンスがencodingsが使用したキャラクタのひとりにおける制限のため迷子になったか、または正常にされたかもしれないので、この方法は本来頼り無いです。
3. Fragment Identification Syntax
3. 断片識別構文
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.
テキスト/明瞭な断片識別子のための構文は簡単です。 '炭'、'線'、および保全は、構文が4つの計画を定義するのをチェックします('長さ'か'md5'のどちらかであることができます)。 2つの異なった異形で'炭'と'線'計画を使用できます、位置の異形(1つの数がある)か範囲異形(2つのコンマで切り離された番号で)のどちらか。 保全チェックは、値を指定するのに'長さ'か'md5'計画を使用できます。 非常に弱いのにもかかわらずの、保全について計算しやすいaとしてのこの場合、'長さ'サーブはチェックします。
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を含むRFC5234[9]で定義されるようにABNFを使用します。 パントマイム-charset規則はRFC2978[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
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
3.1. Integrity Checks
3.1. 保全はチェックします。
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
保全チェックはMIME実体の長さ、またはそのMD5指紋を指定できます。 どちらの場合も、それは任意に保全について計算するとき使用されたキャラクタコード化を指定できます。
Wilde & Duerst Standards Track [Page 9] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[9ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
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.
チェックしてください、断片識別子を解釈するクライアントが、彼らが計算に同じキャラクタコード化を使用しているかどうかチェックできるように。 長さに、キャラクタカウントに影響を及ぼすことができるので、キャラクタコード化が必要である場合があります。 例として、ユニコードはベトナム語を書くための前構成されたキャラクタを含んでいますが、また、ベトナム語を書くのに使用される窓-1258コード化では何人かのキャラクタが別々の特殊記号でコード化されなければなりません。(それは、2つのキャラクタが数えられることを意味します)。 ユニコード用語を適用して、これは、テキスト/明瞭なMIME実体の長さが「コード・ポイント」に基づいて計算されることを意味します。 MD5指紋に、MD5アルゴリズムがテキスト/明瞭なリソースの2進法表示に取り組むので、キャラクタコード化が必要です。
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で定義された原則を使用することによって、計算されます。 テキスト/明瞭なMIME実体のMD5指紋は[1]に提示されたアルゴリズムを使用することによって、計算されます、MD5アルゴリズムの結果である128ビットの表現として32の16進数字(大文字しているか小文字の手紙を使用する)の結果をコード化して。 移送機構のどんな潜在的内容-encodingsか満足している転送encodingsも剥取った後に、保全チェックの計算をします。
4. Fragment Identifier Processing
4. 断片識別子処理
Applications implementing support for the mechanism described in this memo MUST behave as described in the following sections.
このメモで説明されたメカニズムのサポートを実行するアプリケーションは以下のセクションで説明されるように振る舞わなければなりません。
4.1. Handling of Line Endings in text/plain MIME Entities
4.1. テキスト/明瞭なMIME Entitiesの線Endingsの取り扱い
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キャラクタシーケンスによって表されます。(RFC2046[3]とRFC3676[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
バイト数か線結末を表すのに使用されるキャラクタから独立しています、それぞれの線結末を1つのシングルにみなさなければなりません。
Wilde & Duerst Standards Track [Page 10] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[10ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
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.
キャラクタ。 解釈テキスト/明瞭な断片識別子が連れていかなければならない実現は、線結末がそれらが働いているプロトコルと他の文脈のコンベンションであることを説明します。
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を支持しながらウェブブラウザの文脈で働いている実現として: URIはHTTPによって受入れられたコンベンションを終わらせる様々が裏打ちするサポートにそうしました。 別の例として、ローカルファイル(ファイル: 例えば、URI計画を伴う)で使用される実現は地方の格納に使用されるコンベンションを支持しなければなりません。 インターネット全体のCR+LFが裏打ちするすべての実現SHOULDサポートは、コンベンションを終わらせて、追加コンベンションがプロトコルに関係づけなかったサポートかそれらが働いているシステムを終わらせるかもしれません。
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.
ImplementersはCR+LFより他のキャラクタかキャラクタシーケンスでプレーンテキスト実体における線結末を表すことができるという事実を知っているべきです。 上記のCRとLF以外に、NELともCR+NELがあります。 また、一般に、線結末のコード化をMIME実体のキャラクタコード化であることに依存できます、そして、実現は必要であるところでこれを考慮に入れなければなりません。
4.2. Handling of Position Values
4.2. 位置の値の取り扱い
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.
何か位置の値(位置とした、または、1つの範囲の一部とした)が実際のMIME実体の長さより大きいなら、それはMIME実体の最後の欄か線位置を特定します。 範囲の第1ポジション値が存在していないなら、範囲はMIME実体の始まりから広がっています。 範囲における2番目の位置の値が存在していないなら、範囲はMIME実体の終わりに達します。 範囲計画の位置が適切に命令されないなら(すなわち、最初の数は2番目より少ないです)、断片識別子を無視しなければなりません。
4.3. Handling of Integrity Checks
4.3. 保全の取り扱いはチェックします。
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で説明されて、現在として仕様をコード化しているのを観測します)、次に、クライアントSHOULD NOTはテキスト/明瞭な断片識別子を解釈します。 クライアントはこの状況にユーザに合図するかもしれません。
Wilde & Duerst Standards Track [Page 11] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[11ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
4.4. Syntax Errors in Fragment Identifiers
4.4. 断片識別子の構文エラー
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で指定された構文に従わない)を含んでいるなら、クライアントはそれを無視しなければなりません。 クライアントは断片識別子を修正するか、または推測するどんな試みもしてはいけません。 構文エラーはクライアントによって報告されるかもしれません。
5. Examples
5. 例
The following examples show some usages for the fragment identifiers defined in this memo.
以下の例はこのメモで定義された断片識別子のためにいくつかの用法を示しています。
http://example.com/text.txt#char=100
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
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
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
ftp://example.com/text.txt#line=10 、20; 長さは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.
2番目の例のように、このURIはtext.txt MIME実体の線11〜20を特定します。 追加長さの保全チェックは、UTF-8でコード化されるとMIME実体には9876のキャラクタの長さがあると指定します。 クライアントが長さの計画を支持するなら、それは、検索されたMIME実体がUTF-8コード化を使用する場合にだけ長さがないかどうか検索されたMIME実体をテストするかもしれないか、または局所的にこのコード化に移コード化されました。
Wilde & Duerst Standards Track [Page 12] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[12ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
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計画を伴う断片識別子を使用するのは本来頼り無いです。 現在のユーザエージェントは、さらなる処理のためのメディアタイプを推論するのに様々な発見的教授法を使用します。 推論されたメディアタイプがテキスト/明瞭である場合にだけ、このメモに従った断片識別子の処理は適切です。
6. IANA Considerations
6. IANA問題
IANA has added a reference to this specification in the text/plain Media Type registration.
IANAはテキスト/明瞭なメディアType登録におけるこの仕様の参照を加えました。
7. Security Considerations
7. セキュリティ問題
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].
また、プレーンテキストのための断片識別子のImplementersとユーザもRFC3986[7]とRFC3987[8]でセキュリティ問題を意識しているべきです。
Wilde & Duerst Standards Track [Page 13] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[13ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[1] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
解放された[5]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2978、2000年10月。
[6] Gellens, R., "The Text/Plain Format and DelSp Parameters",
RFC 3676, February 2004.
[6]Gellens、R.、「テキスト/明瞭な形式とDelSpパラメタ」、RFC3676、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、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[8] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRI)", RFC 3987, January 2005.
[8]DuerstとM.とM.Suignard、「国際化しているリソース識別子(IRI)」、RFC3987、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"、STD68、RFC5234、2008年1月。
8.2. Informative References
8.2. 有益な参照
[10] Connolly, D. and L. Masinter, "The 'text/html' Media Type",
RFC 2854, June 2000.
[10] コノリーとD.とL.Masinter、htmlテキスト/'メディアタイプ」、RFC2854、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、ISO10646のコード化」RFC2781、2000年2月。
[12] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[12]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変化形式
[13] ANSI X3.4-1986, "Coded Character Set - 7-Bit American National
Standard Code for Information Interchange", 1986.
[13]ANSI X3.4-1986、1986の「コード化文字集合--7ビットのアメリカの国家の標準の情報交換用符号」
Wilde & Duerst Standards Track [Page 14] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[14ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
[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.果樹園、「言語(XLink)バージョン1インチ、ワールドワイドウェブコンソーシアム推薦2001年6月、<http://www.w3.org/TR/xlink/>をリンクするXML。」
[15] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[15]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
Wilde & Duerst Standards Track [Page 15] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[15ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
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、ティムBray、イアン・カルダー、ジョン・カウァン、スペンサー・ダウキンズ、リサDusseault、Benja Fallenstein、テッド・ハーディー、サム・ハートマン、サンドロスホーク、ジェフリーHutzelman、Cullenジョニングス、グラハムKlyne、ダン・コーン、Henrik Levkowetz、クリス・ニューマン、マーク・ノッティンガム、コンラッド・パーカー、およびティム・ポークによって提供されたコメントと提案をありがとうございます。
Authors' Addresses
作者のアドレス
Erik Wilde UC Berkeley School of Information, 311 South Hall Berkeley, CA 94720-4600 U.S.A.
情報のエリックワイルドUCバークレー学校、311の南ホールバークレー、カリフォルニア94720-4600米国
Phone: +1-510-6432253 EMail: dret@berkeley.edu URI: http://dret.net/netdret/
以下に電話をしてください。 +1-510-6432253はメールされます: dret@berkeley.edu ユリ: 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(注意: どこでも、例えば、「Dürst」としてXMLとHTMLで可能であるところにu-ウムラウト符号で"Duerst"を書いてください。) 相模原、青山学院大学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 6329Fax: +81 42 759 6495はメールされます: duerst@it.aoyama.ac.jp ユリ: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Wilde & Duerst Standards Track [Page 16] RFC 5147 text/plain Fragment Identifiers April 2008
ワイルドとDuerst Standards Track[16ページ]RFC5147テキスト/明瞭なFragment Identifiers2008年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントは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に情報を記述してください。
Wilde & Duerst Standards Track [Page 17]
ワイルドとDuerst標準化過程[17ページ]
一覧
スポンサーリンク
