Edit

Page

Page title:

Page body:

[FIG(important)[
[12] 本項の [[Internet Draft]] は古いものです。最新の情報は
[CODE(MIME)@en[[[text/plain]]]] の項を参照してください。
]FIG]

'''URI Fragment Identifiers for the text/plain Media Type <draft-wilde-text-fragment-02>'''
- Network Working Group                                           
- Internet-Draft                               
- Expires: October 3, 2003                                    
- E. Wilde
- Swiss Federal Institute of Technology
- April 4, 2003

* Status of this Memo

> This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

> Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

> Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

> The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

> The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

> This Internet-Draft will expire on October 3, 2003.

* Copyright Notice

* Abstract

> This memo defines URI fragment identifiers for text/plain resources.
These fragment identifiers make it possible to refer to parts of a
text resource, identified by character count or range, line count or
range, or a regular expression. These identification methods can be
combined to identify more than one sub-resource of a text/plain
resource.

このメモは [CODE(MIME)[text/plain]] 資源用 URI 素片識別子を定義します。
この素片識別子は、文資源の一部分を、
文字数や範囲、行数や範囲、あるいは正規表現で識別することを可能にします。
この識別方法は、組合せて [CODE(MIME)[text/plain]] 資源の複数の部文資源を識別できます。

* Table of Contents

>
[PRE[
   1.    Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1   What is text/plain?  . . . . . . . . . . . . . . . . . . . .  3
   2.1.1 Line Endings in text/plain Resources . . . . . . . . . . . .  4
   2.2   What is a URI Fragment Identifier? . . . . . . . . . . . . .  4
   2.3   Why text/plain Fragment Identifiers? . . . . . . . . . . . .  5
   2.4   Incremental Deployment . . . . . . . . . . . . . . . . . . .  5
   3.    Fragment Identification Methods  . . . . . . . . . . . . . .  6
   3.1   Fragment Identification Schemes  . . . . . . . . . . . . . .  6
   3.1.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1.2 Combining the Principles . . . . . . . . . . . . . . . . . .  8
   3.1.3 Regular Expressions  . . . . . . . . . . . . . . . . . . . .  9
   3.1.4 Combining Fragment Identification Scheme Parts . . . . . . .  9
   4.    Fragment Identification Syntax . . . . . . . . . . . . . . .  9
   4.1   Handling of position Values  . . . . . . . . . . . . . . . . 10
   4.2   Non-ASCII Characters in Regular Expressions  . . . . . . . . 10
   5.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 12
   7.    Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.1   From -01 to -02  . . . . . . . . . . . . . . . . . . . . . . 12
   7.2   From -00 to -01  . . . . . . . . . . . . . . . . . . . . . . 12
         Normative References . . . . . . . . . . . . . . . . . . . . 13
         Non-Normative References . . . . . . . . . . . . . . . . . . 13
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
   A.    POSIX BRE Syntax . . . . . . . . . . . . . . . . . . . . . . 14
   B.    Where to send Comments . . . . . . . . . . . . . . . . . . . 14
   C.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
         Intellectual Property and Copyright Statements . . . . . . . 15
]PRE]

* 1. Open Issues

> This section will not be part of the final RFC text, it serves as a
place to collect open issues regarding this memo.

この章は最終的な RFC の文章の一部とはしません。
このメモに関する公開問題を集めておきます。

>
- o  Provide more complex example(s).
- o  Provide short BRE syntax and description in Appendix A (by
inclusion or by reference).
- o  Should regex ranges be allowed (ie, a fragment ranging from one
regex match to another regex match)?
- o  Should a more sophisticated regex mechanism than BREs be used?
- o  Regexes by themselves may identify disjoint sub-resources. Should
there be a mechanism to say something like "the 5th appearance of
the following regex"? Or are users responsible for composing
regexes which do not need this kind of additional mechanism?

- もっと複雑な例を提供する。
- 附属書 A で短い BRE 構文と説明を提供する (含めるか参照するかで)。
- 正規表現範囲を認めるべきか 
(つまりある正規表現に一致するところから別の正規表現に一致するところまでの範囲の素片)。
- BRE より洗練された正規表現機構を使うべきか。
- 正規表現自体がつながっていない分文資源を識別し得る。
[Q[次の正規表現の5番目の出現]]のように言う仕組みを用意するべきか。
それとも利用者がこのような追加の仕組みが要らないように正規表現を構成する責任を持つべきか。

>
- o  Is the concatenation of scheme parts (Section 3.1.4) and its
semantics of joining the individual fragments a good thing? Or a
bad thing?
- o  Should there be more schemes? Or less?
- o  Is it necessary to mention that applications must be able to
transcode characters, because the text file and the fragment
identifier may use different character encodings? What about
character normalization? Should that be addressed or at least
mentioned as being out of scope?

- Scheme 部分の連結と個々の素片の連結のその意味はよいことか。
それとも悪いことか。
- もっと scheme が多いべきか、少ないべきか。
- 応用が文字を転符号化できなければならないことに触れる必要があるか
(文ファイルと素片識別子は異なる文字符号化を使用するかもしれないから)。
文字正規化についてはどうか。言及するべきか、
最低適用範囲外であると触れるべきか。

* 2. Introduction

> Compliant software MUST follow this specification. 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 [1].

適合ソフトウェアは、この仕様書に従わなければ'''なりません'''。
この文書の大文字鍵語 [Q['''しなければなりません''']], [Q['''してはなりません''']], 
[Q['''する必要があります''']], [Q['''するべきです''']], 
[Q['''するべきではありません''']], [Q['''推奨します''']],
[Q['''して構いません''']], [Q['''任意選択で''']]は
[[RFC 2119]] で記述されているように解釈します。

[INS[

訳注: このメモでは、[Q[[RUBYB[実体] [entity]]]]という言葉が使われていますが、
MIME などで使われる意味とは異なるようで、非専門用語として使っているようです。
このメモの範囲では、 [CODE(MIME)[text/plain]] 資源を構成する最小単位である
[Q[文字]]を指しているようです。
]INS]

** 2.1 What is text/plain?

> Internet Media 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 2646 [4] 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]] と [[RFC 2046]] で定義されたインターネット媒体型は、
色々な型と亜型を識別するために使われます。 RFC 2046 と [[RFC 2646]]
は、単純で書式付けされていない文章に使用する [CODE(MIME)[[[text/plain]]]] 
媒体型を規定しています。 RFC 2046 から引用すると、
[Q[平文は書式付け命令、フォント属性指定、処理指令、解釈指令や内容マークを提供しませんし、認めもしません。平文は単純に、場合によっては改行や改頁で中断され得る、文字の線形の列です]]。

> 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 is assumed as the default
character encoding. This variability of the character encoding makes
it impossible to count characters in a text/plain resource without
taking the character encoding into account, because there are many
character encodings using more than one octet per character.

[CODE(MIME)[text/plain]] 媒体型は文字符号化を制限しておらず、
どんな文字符号化でも使うことができます。陽文字符号化宣言が明示されていなければ、
既定文字符号化として [CODE(charset)[[[US-ASCII]]]] が仮定されます。
文字符号化が一定しないので、
多くの文字符号化が1文字に複数のオクテットを使っていますから、
文字符号化を考慮せずに [CODE(MIME)[text/plain]] 資源の文字を数えるのは不可能です。

> The biggest advantage of text/plain resources is their portability
among different platforms. As long as they use popular character
encodings (such as US-ASCII), they can be displayed and processed on
virtually every computer system.

[CODE(MIME)[text/plain]] 資源の最大の長所は、
異なる環境への可搬性です。よく使われる文字符号化 (例えば [CODE(charset)[US-ASCII]])
を使う限り、 [CODE(MIME)[text/plain]] 
は実質的にどの計算機システムでも表示・処理できます。

*** 2.1.1 Line Endings in text/plain Resources

> RFC 2046 [3] and RFC 2646 [4] specify that line endings in text/plain
resources are represented by CR+LF character sequences. In
implementation practice, however, text/plain resources use different
conventions, for example depending on the operating system they have
been created with (in most cases, Unix uses LF, MacOS uses CR, and
Windows uses CR+LF). Because of this diversity of conventions,
implementations interpreting text/plain fragment identifiers MUST
take different line ending conventions into account.

RFC 2046 と RFC 2646 は、 [CODE(MIME)[text/plain]] 資源の行末は
[CODE(char)[CR]]+[CODE(char)[LF]] 文字列で表現すると規定しています。
しかし、実際の実装では、 [CODE(MIME)[text/plain]] 資源は異なる方法を使っていて、
作成されたオペレーティング・システムなどに依存しています
(ほとんどの場合、 Unix は [CODE(char)[LF]] を使用し、 Mac OS
は [CODE(char)[CR]] を使用し、 Windows は [CODE(char)[CR]]+[CODE(char)[LF]]
を使用します)。このように行末表現が色々なので、
[CODE(MIME)[text/plain]] 素片識別子を解釈する実装は、
異なる行末表現を考慮しなければ'''なりません'''。

> Line endings in text/plain resources MAY be represented by other
character (sequences) than CR+LF, specifically CR, LF, NEL, and
CR+NEL. All these character (sequences) MUST be interpreted as line
endings. This interpretation MUST affect the evaluation of text/plain
fragment identifiers. All representations of line endings (CR+LF, CR,
LF, NEL, and CR+NEL) MUST be treated as a single character in
character counts. For the purpose of regular expression matching, all
representations of line endings must be treated as single LF
characters. The reason for this is that fragment identifiers should
not be broken by converting a file from one line ending convention to another.

[CODE(MIME)[text/plain]] 資源の行末は [CODE(char)[CR]]+[CODE(char)[LF]]
以外文字(列)、特に [CODE(char)[CR]], [CODE(char)[LF]],
[CODE(char)[NEL]], [CODE(char)[CR]]+[CODE(char)[NEL]]
で表現しても'''構いません'''。
これらの文字(列)すべてを行末と解釈しなければ'''なりません'''。
この解釈は [CODE(MIME)[text/plain]] 素片識別子の評価に影響しなければ'''なりません'''。
すべての行末の表現 ([CODE(char)[CR]]+[CODE(char)[LF]], [CODE(char)[CR]], 
[CODE(char)[LF]], [CODE(char)[NEL]], [CODE(char)[CR]]+[CODE(char)[NEL]])
は文字計数時に1つの文字として扱わなければ'''なりません'''。
正規表現一致においては、すべての行末の表現は1つの [CODE(char)[LF]]
文字として扱わなければなりません。この理由は、
素片識別子はファイルの行末表現を他のものに変換した時に壊れるべきではないからです。

> In general, the line ending conventions used in text/plain resources
depends on the character encoding of the resource. Implementations
SHOULD attempt to be as accurate as possible in recognizing line
ending specific to particular character encodings, and MUST treat all
these line endings as one character in character counts, and single
LF characters for regular expression matching.

一般に、 [CODE(MIME)[text/plain]] 資源で使われる行末表現は資源の文字符号化に依存します。
実装者は、特定文字符号化に特有の行末を可能な限り正確に認識しようと試みる'''べきであり'''、
すべての行末を文字数計数時に1つの文字として扱い、
正規表現一致では1つの [CODE(char)[LF]] 文字として扱わなければ'''なりません'''。

** 2.2 What is a URI Fragment Identifier?

> URIs are the identification mechanism for resources on the Web. The
URI syntax specified in RFC 2396 [5] includes as part of a URI
reference a fragment identifier, which (quoting from RFC 2396 [5])
"consists of additional reference information to be interpreted by
the user agent after the retrieval action has been successfully
completed.  As such, it is not part of a URI, but is often used in
conjunction with a URI. The semantics of a fragment identifier is 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 はウェブの資源を識別する仕組みです。 [[RFC 2396]] で規定されている
URI 構文は、 URI 参照の一部として素片識別子を含んでいます。素片識別子は、
(RFC 2396 から引用すると、) [Q[]取出し動作が成功裏に完了した後に利用者エージェントが解釈する追加の参照情報から成ります。ですから、これは URI の一部ではありませんが、しばしば URI と組合せて使います。素片識別子の意味は取出し動作の結果のデータの特性であり、参照で使われる URI の型には関わりません。従って、素片識別子の書式と解釈は取出し結果の媒体型に依存します。]]

> The most popular fragment identifier is defined for text/html
(defined in RFC 2854 [8]), and makes it possible to refer to a
specific element (identified by a 'name' or 'id' attribute) of an
HTML document.

もっとも良く使われる素片識別子は [CODE(MIME)[text/html]] 用に
([[RFC 2854]] で) 定義されたもので、 HTML 文書の ([CODE(HTMLa)[name]]
属性や [CODE(HTMLa)[id]] 属性で識別される) 特定の要素を参照できます。

** 2.3 Why text/plain Fragment Identifiers?

> Referring to specific parts of a resource can be very useful, because
it enables users to create more specific references. Rather than
pointing to a whole resource, users can create references to the part
they really are interested in or want to talk about. Even though it
is suggested that fragment identification methods are specified in a
media type's MIME registration, many media types do not have fragment
identification methods associated with them.

資源の特定の部分を参照することは、
利用者がより特定的な参照を作成できますから、とても有用であります。
利用者は、資源全体ではなく、実際に関心があったり話題に上げたりしたい部分を参照することができます。
素片識別子方式を MIME 媒体型登録で規定することが提案されているものの、
多くの媒体型は関連付けられた素片識別子方式を持っていません。

> Fragment identifiers are only useful if supported by the client,
because they are only interpreted by the client. Therefore, a new
fragment identification method will require some time to be adopted
by clients, and older clients will not support it. However, because
the URI reference 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 make it possible to refer to
specific parts of a text resource, using concepts of positions and
ranges, which may be applied to characters and lines. The also
support locating a fragment by using a regular expression for
searching for a specific character sequence. Thus, text/plain
fragment identifiers enable users to exchange information more
specifically, thereby reducing time and effort that is necessary to
manually search for the relevant part of a text/plain resource.

[CODE(MIME)[text/plain]] の素片識別子は、
文資源の特定の部分を、文字や行に適用できる位置や範囲の概念を使って参照することを可能とします。
この素片識別子は特定の文字列を検索する正規表現を使った素片の位置付けにも対応しています。
ですから、 [CODE(MIME)[text/plain]] 素片識別子は利用者がより特定的な情報を交換することを可能とし、
[CODE(MIME)[text/plain]] 資源の適当な部分を手動で探すのに必要な時間と労力を削減します。

** 2.4 Incremental Deployment

> As long as support for text/plain fragment identifiers is not
implemented by all programs, 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 resources,
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 reference will fail to interpret the
fragment identifier part. Since fragment identifier evaluation is
local to the client (and happens after retrieving the resource),
there is no way for a server to determine whether a requesting client
is using a URI reference containing a fragment identifier.

[CODE(MIME)[text/plain]] 素片識別子がすべてのプログラムで実装されていない限り、
徐々に配備されていくことの絡み合いを考慮することが重要です。
このメモで説明する [CODE(MIME)[text/plain]] 素片識別子に対応していないクライアント 
(例えばウェブ・ブラウザ) は、 [CODE(MIME)[text/plain]] 資源への URI 
参照は機能するでしょうが、素片識別子で識別される部分資源の位置づけには失敗するでしょう。
これは適度な fallback 動作であり、通常利用者は URI 
参照を解釈するプログラムが素片識別子部分の解釈に失敗する可能性を考慮するべきです。
素片識別子はクライアント局所で評価されます (し資源の取出しの後起こります)
から、要求しているクライアントが素片識別子を含んだ URI 
参照を使っているかどうかを鯖が決定する方法はありません。

* 3. Fragment Identification Methods

> The identification of resource fragments of text/plain resources can
be based on different foundations. Since it is not possible to insert
explicit, invisible identifiers into a text/plain resource (as for
example used in HTML documents, implemented through special
attributes), fragment identification has to rely on certain inherent
criteria of the resource. This memo specifies fragment identification
using five different methods, character positions and ranges, line
positions and ranges, and regular expression matching.

[CODE(MIME)[text/plain]] 資源の資源素片の識別は、
色々な土台の上で行うことができます。明示的で不可視な識別子を
[CODE(MIME)[text/plain]] 資源に挿入すること
(例えば HTML bunsho で使われているように、特別な属性を通して実装すること) 
は不可能ですから、素片識別は資源の内在的基準に依存せざるを得ません。
このメモは、5つの異なる方式 — 文字位置、文字範囲、
行位置、行範囲、正規表現一致を使った素片識別を規定します。

> When interpreting character or line numbers, implementations MUST
take the character encoding of the resource into account, because
character count and octet count may differ for the character encoding
being used. For example, a resource using UTF-16 encoding (as
specified in RFC 2718 [9]) uses two octets per character, and it may
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.

資源の文字符号化によっては文字数とオクテット数が異なるかもしれませんから、
文字数や行数を解釈する時、実装は、資源の文字符号化を考慮しなければ'''なりません'''。
例えば、 UTF-16 符号化 ([[RFC 2718]] で規定されています。) を使った資源は、
1文字あたり2オクテットを使いますし、先頭に
[CODE(char)[[[BOM]]]] (バイト順マーク) を持つかもしれません。
[CODE(char)[BOM]] は文字として数えませんから、
単純なオクテット数から文字数への写像にも影響します。

** 3.1 Fragment Identification Schemes

> Fragment identification can be done using regular expressions or
combining two orthogonal principles, which are positions and ranges,
and characters and lines. The following section describe the
principles themselves, while Section 3.1.2 describes the combination
of the principles.

素片識別は正規表現や2つの直行する方法、位置と範囲ならびに文字と行を使って行うことができます。
次の節では方法を説明し、3.1.2節では方法の組合せを説明します。

*** 3.1.1 Principles

**** 3.1.1.1 Positions and Ranges

> A position does not identify an actual fragment of the resource, but
a position inside the resource, which could be regarded as a fragment
of zero length. The usa case for positions is to provide pointers for
applications which 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 resource), so that a
text/plain resource having one character has two positions, one
before the first character (position 0), and one after the first
character (position 1).

位置は実際の資源の素片ではなく、資源の中の位置を識別します。
これは長さ零の素片とみなすことができます。
位置を使う場合の例としては、
[Q[文章をここに挿入]]のような機能を実装するために使う指示子の提供で、
この場合素片ではなく位置が必要です。位置は零から数えます
(位置零は [CODE(MIME)[text/plain]] 資源の最初の文字・行の前です)
から、1つの文字を持つ [CODE(MIME)[text/plain]] 資源は2つの位置を持ちます
(1つは最初の文字の前 (位置 [CODE(URI)[0]]) で、もう1つは最初の文字の後
(位置 [CODE(URI)[1]]) です)。

> Since positions are fragments of length zero, applications SHOULD use
other methods than highlighting to indicate positions, the most
reasonable way being the positions of a cursor (if the application
supports the concept of a cursor).

位置は長さ零の素片ですから、応用は位置を示すために強調以外の方法を使う'''べきです'''。
最も合理的な方法は cursor 位置とすることでしょう (応用が cursor
の概念を持っていればの話です)。

> Ranges, on the other hand, identify fragments of a resource that have
a length that may be greater than zero. As a general principle for
ranges, they specify both a lower and a upper bound. The start or the
end of a range specification may be omitted, defaulting to the first
repectively last position of the resource. The ending position of a
range must have a value greater than or equal to the lower position
(consequently, a range with identical lower and upper positions is
legal, and identifies a range of length 0, which is equivalent to a
position). Counting for ranges uses positions, so that a fragment
containing one entity is specified by using a range with two adjacent
positions.

他方、範囲は、零以上の長さを持つ資源の素片を識別します。
範囲の一般原則として、下限と上限の両方を指定します。
範囲の開始や終了の指定は省略でき、それぞれ資源の最初と最後を既定値とします。
範囲の終了位置は開始位置以上の値でなければなりません
(ですから、最小位置と最大位置が同じである範囲も合法であり、
長さ零の範囲を識別しまして、これは位置と等価です)。
範囲の計数には位置を用いますから、一つの実体を含む素片は2つの隣接位置の範囲を使って指定します。

> Since ranges are fragments with a length greater than zero,
applications SHOULD use methods like highlighting to indicate ranges
(if the application supports the concept of highlighting).

範囲は長さ零以上の素片ですから、応用は範囲を示すための強調のような方式を使う'''べきです'''
(応用が強調の概念を持っていればの話です)。

> For positions and ranges it is implicitly assumed that if a number is
greater than the actual number of entities in the resource, then it
is referring to the last entity of the resource.

位置と範囲では、数が資源中の実体の実際の数より大きければ、
資源の最後の実体を参照することを暗に仮定しています。

**** 3.1.1.2 Characters and Lines

> The concept of positions and ranges may be applied to characters and
lines. In both cases, positions indicate points between entities,
while ranges identify zero or more 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 resource), and counting each character
separately, with the exception of line endings, which are always
counted as one character (Section 2.1.1 describes how line endings
MUST be identified).

文字位置は零から数え始め (最初の [CODE(char)[BOM]]
や同様の概念は実際の [CODE(MIME)[text/plain]] 資源の一部ではありません)、
各文字を別個に数えます。ただし行末は、常に1文字として数えます
(2.1.1 節で行末をどう識別しなければ'''ならない'''かを説明しています)。

> Line positions are numbered starting with zero (with line position
zero always being identical with character position zero), with
Section 2.1.1 describing how line endings must be 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 (eg, the
highlighted selection). If a resource does not contain any line
endings, then it consists of a single (the first) line.

行位置は零から数え始めます (行位置零は常に文字位置零と同一です)。
行末をどう識別しなければ'''ならない'''かは2.1.1 節で説明しています。
行によりしい別される素片は行末を含みますから、
行を基にした素片を識別する応用は、使用する素片識別方法
(例えば強調選択) で行末を含めなければ'''なりません'''。
資源が行末を含まない時は、その資源は1つの (最初の) 行だけから成ります。

*** 3.1.2 Combining the Principles

> In the following sections, the principles described in the preceding
section are combined, resulting in four use cases.

以降の節では、以前の節で説明した原則を組合せて、4つの場合について説明します。

**** 3.1.2.1 Character Position

> Using the char scheme followed by a single number, it is possible to
point to a character position (ie, a fragment of length zero between
two characters). Rather than identifying a fragment consisting of a
number of characters, this method identifies a position between two
characters (or before the first or after the last character).
Character position counting starts with 0, so the character position
before the first character of a text/plain resource has the character
position 0, and a resource containing n distinct characters has n+1
distinct character positions.

[CODE(URI)[char]] scheme と1つの数字を使って、
文字位置 (長さ零の、2つの文字の間の素片) を指すことができます。
この方式は、幾つかの文字を含む素片を識別するのではなく、
2つの文字の間の位置 (または最初の文字の前か最後の文字の後)
を識別します。文字位置計数は零からはじめますから、
[CODE(MIME)[text/plain]] 資源の最初の文字の前の文字位置は文字位置
[CODE(URI)[0]] となり、 [CODE(math)[[VAR[n]]]] 個の文字を含む資源は
[CODE(math)[[VAR[n]] + 1]] 個の文字位置を持ちます。

**** 3.1.2.2 Character Range

> If it is necessary to identify a fragment of zero or more characters
using character counting, this can be done by using a character
range, using the char scheme followed by a range specification. A
character range is a consecutive region of the resource that extends
from the starting character position of the range to the ending
character position of the range.

文字計数を使って零個以上の素片を識別することが必要であれば、
[CODE(URI)[char]] scheme と範囲指定により、
文字範囲を使って行うことができます。文字範囲は資源の連続的領域であり、
範囲の開始文字位置から範囲の終了文字位置までです。

**** 3.1.2.3 Line Position

> Using the line scheme followed by a single number, it is possible to
point to a character position (ie, a fragment of length zero between
two lines). Rather than identifying a fragment consisting of a number
of lines, this method identifies a position between two lines (or
before the first or after the last line). Line position counting
starts with 0, so the line position before the first line of a text/plain resource has the line position 0, and a resource containing n
distinct lines has n+1 distinct line positions.

[CODE(URI)[line]] scheme と1つの数字を使って、
文字位置 (2つの行の間の長さ零の素片) を指すことができます。
この方式は、幾つかの行を含む素片を識別するのではなく、
2つの行の間の位置 (または最初の行の前か、
最後の行の後) を識別します。行位置計数は [CODE(URI)[0]]
から始めますから、 [CODE(MIME)[text/plain]] 資源の最初の行の前の行位置は行位置
[CODE(URI)[0]] を持ち、 [CODE(math)[[VAR[n]]]] 個の行を持つ資源は
[CODE(math)[[VAR[n]] + 1]] 個の行位置を持ちます。

**** 3.1.2.4 Line Range

> If it is necessary to identify a fragment of zero or more lines using
line counting, this can be done by using a line range, using the line
scheme followed by a range specification. A line range is a
consecutive region of the resource that extends from the starting
line position of the range to the ending line position of the range.

行計数を使って零個以上の行の素片を識別する必要があれば、
[CODE(URI)[line]] scheme と範囲指定により、
行範囲を使って行うことができます。行範囲は資源の連続敵領域であり、
範囲の開始行位置から範囲の終了行位置までです。

*** 3.1.3 Regular Expressions

> A common problem with fragment identifiers is their robustness (to
changes in the resource), and character and line counts can be broken
very easily. A more robust way of identifying a fragment is by
searching for a specific pattern. Thus, it is possible to use a Basic
Regular Expression (BRE) as defined by ISO 9945-2 [6] (the POSIX
standard) as a fragment identifier (Appendix A contains a short
summary of the POSIX BRE syntax).

素片識別の共通の問題は (資源の変更に対する) 頑強性であり、
文字数や行数は非常に壊れやすいです。素片を識別するより頑強な方法は、
特定のパターンによる検索によることです。従って、素片識別子として
[[ISO 9945]]‐2 ([[POSIX]] 規格) で定義された基本正規表現 (BRE)
を使うことが可能です (附属書 A に POSIX BRE 構文の短い要約があります)。

*** 3.1.4 Combining Fragment Identification Scheme Parts

> While in most cases only one fragment identification scheme part will
be used, it is possible to combine them. By simply concatenating
different fragment identification scheme parts, separated by a
semicolon, the whole fragment identifier refers to the union of all
fragments of the text resource identified by the individual fragment
identification scheme parts. This way, it is possible to identify
disjoint ranges, such as multiple line ranges.

ほとんどの場合、1つの素片識別 scheme 部分が使われるでしょうが、
scheme 部分を組合せることが可能です。単純に異なる素片識別 scheme
部分をセミコロンで分離して連結すれば、全体の素片識別子は個々の素片識別
scheme 部分が識別する文資源の素片すべての和集合を参照します。
この方法で、つながっていない範囲、例えば複数の行範囲を識別することが可能です。

> It should be noticed that regular expressions by themselves may
identify disjoint fragments, which is true in any case where the
regular expression matches more than one occurrence in the resource.

正規表現自体がつながっていない素片を識別するかもしれないことに注意してください。
これは、資源が複数箇所で正規表現に一致する場合に真となります。

> Since disjoint fragments can be identified, implementations SHOULD
make sure that these fragments are appropriately marked, for example
by highlighting the fragment (rather than only scrolling to some
line, which only identifies a single location in the resource). If an
implementation can not mark disjoint fragments, it MAY resort to
marking only the first of the disjoint fragments. However, the exact
method of how implementations deal with disjoint fragments depends on
the application and interface, and is beyond the scope of this memo.

つながっていない素片を識別できるのですから、実装は、
そのような素片を適切に印付け、たとえば強調できるようにする'''べきです'''
(どこかの行に scroll するだけでは、資源の1つの場所しか識別できません)。
実装がつながっていない素片に印付けできないのであれば、
つながっていない素片の最初だけを印付けすることとしても'''構いません'''。
しかし、実装がつながっていない素片をどう処理するかの正確な方法は応用と界面に依存し、
このメモの適用適用範囲外であるとします。

* 4. Fragment Identification Syntax

> The syntax for the fragment identifiers is straightforward. The
syntax defines three schemes, 'char', 'line', and 'match'. The 'char'
and 'line' can be used in two different variants, either the position
variant (with a single number), or the range variant (with two
comma-separated positions). The 'match' scheme has a regular
expression as parameter, which must be specified as a string with
escaped semicolons (because the semicolon is used to concatenate
multiple fragment identification schem parts).

素片識別子の構文は簡単です。構文は [CODE(URI)[char]], [CODE(URI)[line]],
[CODE(URI)[match]] の3つの scheme を定義します。 [CODE(URI)[char]] scheme
と [CODE(URI)[line]] scheme は、位置 (1つの数) と範囲
(読点で分離した2つの位置) の2種類の書式を使うことができます。
[CODE(URI)[match]] scheme は引数として正規表現を持ちますが、
セミコロンを逃避した文字列として指定しなければなりません
(セミコロンは複数の素片識別 scheme 部分の連結に使います)。

> The following syntax definition uses ABNF as defined in RFC 2234 [7].

次の構文定義は [[RFC 2234]] の [[ABNF]] を使います。

>
[PRE[
   text-fragment =  text-scheme 0*( ";" text-scheme)
   text-scheme   =  ( char-scheme / line-scheme / match-scheme )
   char-scheme   =  "char=" ( position / range )
   line-scheme   =  "line=" ( position / range )
   match-scheme  =  "match=" regex
   position      =  number
   range         =  (position "," [ position ]) / ("," position )
   number        =  1*DIGIT
   regex         =  StringWithEscapedSemicolon
]PRE]

> The StringWithEscapedSemicolon is a string where all characters may
appear literally (except the characters which are required by the URI
syntax to be escaped), with the exception of a semicolon. A semicolon
that should be part of the regular expression must be escaped with a
leading backslash, and implementations MUST make sure to properly
interpret regular expressions, properly dereferencing all escape
mechanisms that apply (ie, URI encoding, semicolon escaping, and BRE
escaping, as well as any additional escaping that may be present due
to the context of the URI reference).

[CODE(ABNF)[StringWithEscapedSemicolon]] は、
セミコロン以外のすべての文字
(URI 構文で逃避する必要のある文字を除きます。)
が生で出現できる文字列です。正規表現の一部となるべきセミコロンは、
直前に逆斜線を加えて逃避しなければなりません。また、
実装は、正規表現を適切に解釈できるように、
適用されているすべての逃避機構 (URI 符号化、セミコロン逃避、
BRE 逃避、 URI 参照の文脈によって存在し得るすべての追加の逃避機構) 
を適切に解決しなければ'''なりません'''。

[INS[

訳注: [Q[URI 参照の文脈〜]] というのは、例えば URI 参照を HTML
で使用するときに [CODE(URI)[&]] を [CODE(HTML)[&amp;]]
にしなければ'''ならない'''ことがあるようなものを指しているのだと思われます。

ところで、セミコロン逃避に逆斜線を使っていますが、
その逆斜線も URI 参照では直接使えない文字なので URI 逃避符号化しなければなりません。
(セミコロンを直接 URI 符号化すれば良いのだろうに。)
]INS]

** 4.1 Handling of position Values

> If any position value (as a position or inside a range) is greater
than the value for the actual resource, then it identifies the last
character or line position of the resource. If the first position
value in a range is not present, then the range extends from the
start of the resource. If the second position value in a range is not
present, then the range extends to the end of the resource. If a
range scheme's positions are not properly ordered (ie, the first
number is less than the second), then this scheme part MUST be ignored.

位置値 (位置として、または範囲の中で。) が実際の資源の値よりも大きいのなら、
資源の最後の文字または行位置を識別します。
範囲の最初の位置値が存在しなければ、範囲は資源の開始から始まります。
範囲の2番目の位置値が存在しなければ、範囲は資源の最後で終わります。
範囲 scheme の位置が適切に指示されていなければ (最初の数が2番目の数以下でなければ)、
その scheme 部分は無視しなければ'''なりません'''。

** 4.2 Non-ASCII Characters in Regular Expressions

> RFC 2396 [5] does not define how to use non-ASCII characters in URIs.
Consequently, it is not possible to use non-ASCII characters in URIs
in a standardized and reliable way. However, work on
Internationalized Resource Identifiers (IRI) [10] is in progress, and
as soon as this work results in a published RFC, it will be possible
to use non-ASCII characters in regular expressions, using the
encoding defined by IRI.

RFC 2396 は URI で非 ASCII 文字をどう使うかを定義していません。
ですから、 URI で非 ASCII 文字を標準化された信頼できる方法で使うことは不可能です。
しかし、国際化資源識別子 (IRI) が作業中で、
この作業が RFC として出版されることになれば、 IRI
で定義される符号化を使って、正規表現で非 ASCII
文字を使うことができるようになるでしょう。

* 5. Examples

> The following examples show some usages for the fragment identifiers
defined in this memo.

以降の例はこのメモで定義した素片識別子の用法を示します。

> http://example.com/text.txt#char=100

> This URI reference identifies the position after the 100th character
of the text.txt resource. It should be noted that it is not clear
which octet(s) of the resource this will be without retrieving the
resource and thus knowing which character encoding is it using (in
case of HTTP, this information will be given in the response's
Content-type header). If the resource has fewer than 100 characters,
the URI reference identifies the position after the resource's last
character.

この URI 参照は [CODE(URI)[text.txt]] 資源の100番目の文字の後の位置を識別します。
それが資源のどのオクテットになるのかは、
資源を取出して使用している文字符号化 (HTTP の場合、個の情報は応答の
[CODE(HTTP)[[[Content-Type]]]] 頭で与えられます。) 
を知らないとはっきりしないことに注意してください。
資源が100文字未満しかなければ、この URI
参照は資源の最後の文字の後の位置を識別します。

> http://example.com/text.txt#line=10,20

> This URI reference identifies lines 11 to 20 of the text.txt
resource. If the resource has fewer than 11 lines, it identifies the
position after last line. If the resource has less than 20 but at
least 11 lines, it identifies the lines 11 to the last line of the
resource.

この URI 参照は [CODE(URI)[text.txt]] 資源の11行から20行を識別します。
資源が11行未満しかなければ、最後の行の後の位置を識別します。
資源が11行以上20行未満であれば、11行から資源の最後の行までを識別します。

> http://example.com/text.txt#match=searchterm

> This URI reference identifies all occurrences of the regular
expression 'searchterm' in the resource, ie all occurrences of the
string 'searchterm'. If there is more than one occurrence, then this
URI reference identifies a disjoint fragment, consisting of all of
these occurrences. If there is no occurrence of the search term, the
URI reference does not identify a fragment.

この URI 参照は資源内の正規表現 [SAMP(regex)[searchterm]] 
のすべての出現、すなわち文字列 [SAMP[searchterm]]
のすべての出現を識別します。複数の出現があれば、
この URI 参照は、その出現すべてから成る、つながっていない素片を識別します。
検索語の出現がなければ、この URI 参照は素片を識別しません。

> http://example.com/text.txt#line=,1;match=searchterm

> This URI reference identifies the first line and all occurrences of
the regular expression 'searchterm' in the resource. If there is an
occurrence of 'searchterm' outside of the first line, then this URI
reference identifies a disjoint fragment.

この URI 参照は最初の行と資源中の正規表現 [SAMP(regex)[searchterm]]
のすべての出現を識別します。最初の行以外に [SAMP[searchterm]]
が出現すれば、この URI 参照はつながっていない素片を識別します。

> http://example.com/text.txt#match=hello\;

> This URI reference identifies all occurrences of the regular
expression 'hello;' in the resource. The semicolon with the leading
backslash has to be interpreted as a literal semicolon insode of the
BRE, treating the '\;' as an escaped ';', so that the actual regular
expression is 'hello;'.  If there is more than one occurrence of this
regular expression, then this URI reference identifies a disjoint
fragment, consisting of all of these occurrences.

この URI 参照は資源中の正規表現 [SAMP(regex)[hello;]] のすべての出現を識別します。
逆斜線が前に付いたセミコロンは、 [SAMP(URI)[\;]] を逃避した [SAMP(char)[;]]
として BRE の生のセミコロンとして解釈しなければなりませんから、
実際の正規表現は [SAMP(regex)[hello;]] となります。
この正規表現の出現が複数あれば、この URI
参照はその出現すべてから成る、つながっていない素片を識別します。

> ...

> (more complex example...)

* 6. Security Considerations

> Regular expression matching code is notoriously vulnerable to buffer
overflow security holes, so any implementation supporting text/plain
fragment identifiers MUST make sure that the code being used has been
tested against buffer overflow attacks.

正規表現一致符号はバッファ溢れ保安孔に脆弱であり、 [CODE(MIME)[text/plain]]
素片識別子に対応する実装は使用する符号がバッファ溢れ攻撃について試験したものであることを確かめなければ'''なりません'''。

* 7. Change Log

** 7.1 From -01 to -02

[PRE[
   o  Fundamental change in semantics: counts turn into positions
      (between characters or lines), so in order to identify a character
      or line, ranges must be used (which now use positions to specify
      the upper and lower bounds of the range).
]PRE]

[PRE[
   o  Made the first value of a range optional as well, so that line=,5
      also is legal, identifying everything from the start of the
      resource to the 5th line.
]PRE]

[PRE[
   o  Changed the syntax from paranthesis-style to a more traditional
      style using equals-signs.
]PRE]

** 7.2 From -00 to -01

[PRE[
   o  Made the second count value of ranges optional, so that something
      like line(10,) is legal and properly defined.
]PRE]

[PRE[
   o  Added non-normative reference to Internet draft about non-ASCII
      characters in search strings.
]PRE]

[PRE[
   o  Added Section 2.4 about incremental deployement.
]PRE]

[PRE[
   o  Added more elaborate examples.
]PRE]

[PRE[
   o  Added text about regex buffer overflow problems in Section 6.
]PRE]

[PRE[
   o  Added Section 2.1.1 about line endings in text/plain resources.
]PRE]

[PRE[
   o  Added Section 1 to collect open issues regarding this memo (will
      be deleted in final RFC text).
]PRE]

* Normative References

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

[PRE[
   [2]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.
]PRE]

[PRE[
   [3]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996.
]PRE]

[PRE[
   [4]  Gellens, R., "The Text/Plain Format Parameter", RFC 2646, August
        1999.
]PRE]

[PRE[
   [5]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
]PRE]

[PRE[
   [6]  International Organization for Standardization, "Information
        technology - Portable Operating System Interface (POSIX) - Part
        2: Shell and Utilities", ISO 9945-2, 1993.
]PRE]

[PRE[
   [7]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.
]PRE]

* Non-Normative References

[PRE[
   [8]   Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC
         2854, June 2000.
]PRE]

[PRE[
   [9]   Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
         RFC 2781, February 2000.
]PRE]

[PRE[
   [10]  Duerst, M. and M. Suignard, "Internationalized Resource
         Identifiers (IRI)", draft-duerst-iri-03 (work in progress),
         March 2003.
]PRE]

[PRE[
   [11]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
         1999.
]PRE]

* Author's Address

[PRE[
   Erik Wilde
   Swiss Federal Institute of Technology
   ETH-Zentrum
   8092 Zurich
   Switzerland
]PRE]

[PRE[
   Phone: +41-1-6325132
   EMail: net.dret@dret.net
   URI:   http://dret.net/netdret/
]PRE]

* Appendix A. POSIX BRE Syntax

> This section contains a short (and non-normative) summary of the
POSIX BRE syntax defined in ISO 9945-2 [6]. The definition of BRE
syntax in ISO 9945-2 [6] is the normative reference, and the
following summary is for informative purposes only.

> (tbd - is there some rfc that could be referenced instead?)

* Appendix B. Where to send Comments

> Please send all comments and questions concerning this document to
Erik Wilde.

* Appendix C. Acknowledgements

> This document has been prepared using the IETF document DTD described
in RFC 2629 [11].

> Thanks for comments and suggestions provided by Dan Kohn, John Cowan,
Benja Fallenstein, and Henrik Levkowetz.

* Intellectual Property Statement

[PRE[
   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.
]PRE]

[PRE[
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.
]PRE]

* Full Copyright Statement

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

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

[PRE[
   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
]PRE]

* Acknowledgement

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

* License

[[RFCのライセンス]]

* メモ

[1] この I-D は既に期限が切れています。

原文は <http://dret.net/netdret/docs/draft-wilde-text-fragment-02.txt>
などから入手できます。

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)