RFC 3987//A

RFC 3987//A

Appendix A. Design Alternatives

This section shortly summarizes major design alternatives and the reasons for why they were not chosen.

この章では他の設計案とそれを選ばなかった理由を簡単にまとめます。

Appendix A.1. New Scheme(s)

Introducing new schemes (for example, httpi:, ftpi:,...) or a new metascheme (e.g., i:, leading to URI/IRI prefixes such as i:http:, i:ftp:,...) was proposed to make IRI-to-URI conversion scheme dependent or to distinguish between percent-encodings resulting from IRI-to-URI conversion and percent-encodings from legacy character encodings.

新しい scheme (例えば httpi:, ftpi:) や新しいメタ scheme (例えば URI・IRI の前に i:i:http:i:ftp: のように付ける。) を導入して IRI から URI への変換を scheme 依存にしたり IRI から URI への変換の結果の百分率符号化と遺物文字符号化の百分率符号化を区別できるようにすることが提案されました。

New schemes are not needed to distinguish URIs from true IRIs (i.e., IRIs that contain non-ASCII characters). The benefit of being able to detect the origin of percent-encodings is marginal, as UTF-8 can be detected with very high reliability. Deploying new schemes is extremely hard, so not requiring new schemes for IRIs makes deployment of IRIs vastly easier. Making conversion scheme dependent is highly inadvisable and would be encouraged by separate schemes for IRIs. Using a uniform convention for conversion from IRIs to URIs makes IRI implementation orthogonal to the introduction of actual new schemes.

真の IRI (非 ASCII 文字を含む IRI) と URI を区別するのに新しい scheme は不要です。 UTF-8 は非常に高い確率で検出できるので、 百分率符号化の起源を明かせるようにする利点は取るに足りません。 新しい scheme の供用は極めて難しく、 IRI 用の新しい scheme を必要としないことで IRI の供用は遥かに簡単になります。 変換が scheme 依存になるのは非常に愚かなことであり、 IRI 用の別の scheme を薦めることになります。統一的な IRI から URI への変換を使うことで IRI の実装が実際の新しい scheme の導入と直交したものになります。

Appendix A.2. Character Encodings Other Than UTF-8

At an early stage, UTF-7 was considered as an alternative to UTF-8 when IRIs are converted to URIs. UTF-7 would not have needed percent-encoding and in most cases would have been shorter than percent-encoded UTF-8.

早い段階の案で IRI を URI に変換する時に UTF-8 の代わりに UTF-8 が検討されました。 UTF-7 は百分率符号化不要であり、 ほとんどの場合百分率符号化した UTF-8 より短くなります。

Using UTF-8 avoids a double layering and overloading of the use of the "+" character. UTF-8 is fully compatible with US-ASCII and has therefore been recommended by the IETF, and is being used widely.

UTF-8 を使うと二層化と文字 + の用法の上書きを避けられます。 UTF-8 は US-ASCII と完全互換であり、従って IETF で推奨されており、 広く使われています。

UTF-7 has never been used much and is now clearly being discouraged. Requiring implementations to convert from UTF-8 to UTF-7 and back would be an additional implementation burden.

UTF-7 はそれほど使われることがなく、現在では明らかに非推奨です。 実装に UTF-8 から UTF-7 に変換したり戻したりすることを求めるのは実装の更なる負担となります。

Appendix A.3. New Encoding Convention

Instead of using the existing percent-encoding convention of URIs, which is based on octets, the idea was to create a new encoding convention; for example, to use "%u" to introduce UCS code points.

URI の既存のオクテットに基づく百分率符号化変換を使う代わりに新しい符号化法を作るという考えでした。 例えば %uUCS 符号位置の前に付けます。

Using the existing octet-based percent-encoding mechanism does not need an upgrade of the URI syntax and does not need corresponding server upgrades.

既存のオクテットを基にした百分率符号化法は URI 構文を更新する必要がなく、 それに伴う鯖の更新も不要です。

Appendix A.4. Indicating Character Encodings in the URI/IRI

Some proposals suggested indicating the character encodings used in an URI or IRI with some new syntactic convention in the URI itself, similar to the "charset" parameter for e-mails and Web pages. As an example, the label in square brackets in "http://www.example.org/ros[iso-8859-1]&#xE9"; indicated that the following "&#xE9"; had to be interpreted as iso-8859-1.

電子メイルや Web 頁の charset 引数のように URI や IRI で使う文字符号化を何らかの新しい構文で URI 自体に記述することが提案されました。 例えば札を四角括弧に入れて http://www.example.org/ros[iso-8859-1]é のようにして、その後の éiso-8859-1 として解釈しなければならないことを示します。

If UTF-8 is used exclusively, an upgrade to the URI syntax is not needed. It avoids potentially multiple labels that have to be copied correctly in all cases, even on the side of a bus or on a napkin, leading to usability problems (and being prohibitively annoying). Exclusively using UTF-8 also reduces transcoding errors and confusion.

UTF-8 を排他的に使用すれば URI 構文の更新は不要です。 複数あるかもしれない札がいつ何時でも、たとえバスの側面でもナプキンであっても正しく書き写されなければならず、 可用性の問題を招く (そして極めて困る) というのを避けることができます。 UTF-8 を排他的に使うことで転符号化の誤りと混乱も減ります。

License

RFCのライセンス

メモ