D.1. Additions

An ABNF rule for URI has been introduced to correspond to one common usage of the term: an absolute URI with optional fragment.

URI という用語の共通な用法 (絶対 URI と省略可能な素片) に対応して URI の ABNF 規則を導入しました。

IPv6 (and later) literals have been added to the list of possible identifiers for the host portion of an authority component, as described by [RFC2732], with the addition of "[" and "]" to the reserved set and a version flag to anticipate future versions of IP literals. Square brackets are now specified as reserved within the authority component and are not allowed outside their use as delimiters for an IP literal within host. In order to make this change without changing the technical definition of the path, query, and fragment components, those rules were redefined to directly specify the characters allowed.

IPv6 (以降) の生表現を RFC 2732 で説明されているように authority 部品の host 部で使用できる識別子として加えました。 [ と ] を予約集合に追加し、 将来の版の IP 生表現に備えて版の印を加えました。四角括弧は authority 部品内で予約として規定されており、 host 内の IP 生表現の区切子として以外は認められません。 path, query, fragment 部品の技術的定義に変更を加えずにこの変更を行うため、 各々の規則を再定義して認められる文字を直接指定するようにしました。

As [RFC2732] defers to [RFC3513] for definition of an IPv6 literal address, which, unfortunately, lacks an ABNF description of IPv6address, we created a new ABNF rule for IPv6address that matches the text representations defined by Section 2.2 of [RFC3513]. Likewise, the definition of IPv4address has been improved in order to limit each decimal octet to the range 0-255.

RFC 2732 は IPv6 生番地の定義として RFC 3513 を参照していますが、 残念ながら IPv6address の ABNF 定義が欠けているので、 RFC 3513 の2.2節で文章で表現されている定義に一致する IPv6address の ABNF 規則を新しく作りました。 同様に、 IPv4address の定義は 0〜255 の範囲の十進オクテットに制限するように改善しました。

Section 6, on URI normalization and comparison, has been completely rewritten and extended by using input from Tim Bray and discussion within the W3C Technical Architecture Group.

6章の URI の正規化と比較については完全に書き直し、 Tim Bray からの提案と W3C 技術体系部会 での議論により拡張しました。

D.2. Modifications

The ad-hoc BNF syntax of RFC 2396 has been replaced with the ABNF of [RFC2234]. This change required all rule names that formerly included underscore characters to be renamed with a dash instead. In addition, a number of syntax rules have been eliminated or simplified to make the overall grammar more comprehensible. Specifications that refer to the obsolete grammar rules may be understood by replacing those rules according to the following table:

RFC 2396 の特設 BNF 構文は RFC 2234 の ABNF に置き換えました。この変更により以前下線文字を使っていたすべての規則名を代わりにダッシュを使ったものに改名する必要がありました。 加えて、数々の構文規則を除去・簡略化して全体の文法をより理解しやすくしました。 以前の文法規則を参照している仕様書は次の表にしたがって規則を置き換えれば理解できるかもしれません。

   +----------------+--------------------------------------------------+
   | obsolete rule  | translation                                      |
   +----------------+--------------------------------------------------+
   | absoluteURI    | absolute-URI                                     |
   | relativeURI    | relative-part [ "?" query ]                      |
   | hier_part      | ( "//" authority path-abempty /                  |
   |                | path-absolute ) [ "?" query ]                    |
   |                |                                                  |
   | opaque_part    | path-rootless [ "?" query ]                      |
   | net_path       | "//" authority path-abempty                      |
   | abs_path       | path-absolute                                    |
   | rel_path       | path-rootless                                    |
   | rel_segment    | segment-nz-nc                                    |
   | reg_name       | reg-name                                         |
   | server         | authority                                        |
   | hostport       | host [ ":" port ]                                |
   | hostname       | reg-name                                         |
   | path_segments  | path-abempty                                     |
   | param          | *<pchar excluding ";">                           |
   |                |                                                  |
   | uric           | unreserved / pct-encoded / ";" / "?" / ":"       |
   |                |  / "@" / "&" / "=" / "+" / "$" / "," / "/"       |
   |                |                                                  |
   | uric_no_slash  | unreserved / pct-encoded / ";" / "?" / ":"       |
   |                |  / "@" / "&" / "=" / "+" / "$" / ","             |
   |                |                                                  |
   | mark           | "-" / "_" / "." / "!" / "~" / "*" / "'"          |
   |                |  / "(" / ")"                                     |
   |                |                                                  |
   | escaped        | pct-encoded                                      |
   | hex            | HEXDIG                                           |
   | alphanum       | ALPHA / DIGIT                                    |
   +----------------+--------------------------------------------------+

Use of the above obsolete rules for the definition of scheme-specific syntax is deprecated.

Scheme 規定の構文の定義にこれら廃止された規則を使用するのは非推奨とします。

Section 2, on characters, has been rewritten to explain what characters are reserved, when they are reserved, and why they are reserved, even when they are not used as delimiters by the generic syntax. The mark characters that are typically unsafe to decode, including the exclamation mark ("!"), asterisk ("*"), single-quote ("'"), and open and close parentheses ("(" and ")"), have been moved to the reserved set in order to clarify the distinction between reserved and unreserved and, hopefully, to answer the most common question of scheme designers. Likewise, the section on percent-encoded characters has been rewritten, and URI normalizers are now given license to decode any percent-encoded octets corresponding to unreserved characters. In general, the terms "escaped" and "unescaped" have been replaced with "percent-encoded" and "decoded", respectively, to reduce confusion with other forms of escape mechanisms.

2章の文字に関してはどの文字がいつなぜ (一般構文で区切子として使っていないとしても) 予約されているのかを説明すべく書き直しました。復号したら普通安全でない記号文字、 特に感嘆符 (!)、星印 (*)、単引用符 (')、 括弧 ((、)) は予約集合に移動し、 予約集合と非予約集合の区別を明確化すると共に、 scheme 設計者の最も共通な疑問にも答えることができたと考えています。 同様に、百分率符号化文字についての節も書き直し、 URI 正規化器は非予約文字に対応する任意の百分率符号化オクテットを復号できるとしました。 一般に逃避や非逃避という用語はそれぞれ百分率符号化と 復号に置き換え、他の逃避の仕組みとの混乱を減らすようにしました。

The ABNF for URI and URI-reference has been redesigned to make them more friendly to LALR parsers and to reduce complexity. As a result, the layout form of syntax description has been removed, along with the uric, uric_no_slash, opaque_part, net_path, abs_path, rel_path, path_segments, rel_segment, and mark rules. All references to "opaque" URIs have been replaced with a better description of how the path component may be opaque to hierarchy. The relativeURI rule has been replaced with relative-ref to avoid unnecessary confusion over whether they are a subset of URI. The ambiguity regarding the parsing of URI-reference as a URI or a relative-ref with a colon in the first segment has been eliminated through the use of five separate path matching rules.

URI と URI-reference の ABNF は再設計して LALR 構文解析器との親和性を増すと共に複雑さを減らしました。 結果として配置形の構文記述は削除し、規則 uri, uri_no_slash, opaque_part, net_path, abs_path, rel_path, path_segment, rel_segment, mark も削除しました。すべての不透明な URI への参照はよりよい path 部品を階層について不透明にする方法の説明に改めました。 relativeURI 規則は relative-ref に置き換えて URI の部分集合であるかどうかの不要な混乱を避けるようにしました。 URI-reference を URI として解釈するか最初の segment にコロンが含まれる relative-ref として解釈するかの曖昧さは5つに分けた path 一致規則を使うことによりなくしました。

The fragment identifier has been moved back into the section on generic syntax components and within the URI and relative-ref rules, though it remains excluded from absolute-URI. The number sign ("#") character has been moved back to the reserved set as a result of reintegrating the fragment syntax.

素片識別子は URI の中の一般構文部品の章や URI 規則や relative-ref 規則に戻しました。 但し absolute-URI からは除かれたままです。 数字符 ([CODE(char))[#]]) は fragment 構文を再統合した結果として予約集合に戻っています。

The ABNF has been corrected to allow the path component to be empty. This also allows an absolute-URI to consist of nothing after the "scheme:", as is present in practice with the "dav:" namespace [RFC2518] and with the "about:" scheme used internally by many WWW browser implementations. The ambiguity regarding the boundary between authority and path has been eliminated through the use of five separate path matching rules.

ABNF は path 部品が空でもよいように直しました。 それによって scheme: の後に何もない absolute-URI が認められることになります。この形の URI は実際には dav: 名前空間や多くの WWW ブラウザ実装が内部的に使っている about: scheme で使われています。 authority と path の境界に関する曖昧性は5つに分けた path 一致規則を使うことでなくしました。

Registry-based naming authorities that use the generic syntax are now defined within the host rule. This change allows current implementations, where whatever name provided is simply fed to the local name resolution mechanism, to be consistent with the specification. It also removes the need to re-specify DNS name formats here. Furthermore, it allows the host component to contain percent-encoded octets, which is necessary to enable internationalized domain names to be provided in URIs, processed in their native character encodings at the application layers above URI processing, and passed to an IDNA library as a registered name in the UTF-8 character encoding. The server, hostport, hostname, domainlabel, toplabel, and alphanum rules have been removed.

一般構文を使う登録簿に基づく命名権者は host 規則内で定義することとしました。 この変更によって提供された名前は何であろうと局所名前解決法に渡すという現在の実装が仕様と整合したものとなります。 また、 DNS 名の書式をここで再規定する必要もなくなります。更に、 host 部品が百分率符号化オクテットを含むことも認めました。 これは国際化ドメイン名を URI で提供し、 URI 処理より上の応用層で母文字符号化で処理し、 IDNA ライブラリに UTF-8 文字符号化の登録名として渡すようにするために必要でした。 規則 server, hostport, hostname, domainlabel, toplabel, alphanum は削除しました。

The resolving relative references algorithm of [RFC2396] has been rewritten with pseudocode for this revision to improve clarity and fix the following issues:

RFC 2396 の相対参照解決法は書き直して擬似符号にし、 より明確にすると共に次の問題を修正しました。

• o [RFC2396] section 5.2, step 6a, failed to account for a base URI with no path.
• o Restored the behavior of [RFC1808] where, if the reference contains an empty path and a defined query component, the target URI inherits the base URI's path component.
• o The determination of whether a URI reference is a same-document reference has been decoupled from the URI parser, simplifying the URI processing interface within applications in a way consistent with the internal architecture of deployed URI processing implementations. The determination is now based on comparison to the base URI after transforming a reference to absolute form, rather than on the format of the reference itself. This change may result in more references being considered "same-document" under this specification than there would be under the rules given in RFC 2396, especially when normalization is used to reduce aliases. However, it does not change the status of existing same-document references.
• o Separated the path merge routine into two routines: merge, for describing combination of the base URI path with a relative-path reference, and remove_dot_segments, for describing how to remove the special "." and ".." segments from a composed path. The remove_dot_segments algorithm is now applied to all URI reference paths in order to match common implementations and to improve the normalization of URIs in practice. This change only impacts the parsing of abnormal references and same-scheme references wherein the base URI has a non-hierarchical path.

• RFC 2396 5.2節の手順 6a は path がない基底 URI を考慮に入れていませんでした。
• 参照が path が空で query が定義されている場合、 対象 URI は基底 URI の path 部品を継承するという RFC 1808 の動作に戻しました。
• URI 参照が同文書参照であるかどうかの決定は URI 構文解析器から分離し、応用内の URI 処理界面を実用されている URI 処理実装の内部体系と整合する形で簡単化しました。 同文書参照であるかどうかの決定は参照自体の書式ではなく絶対形に参照を変形した後の比較に基づき行うようになりました。 この変更によって、特に別名を減らすための正規化を行う際に、 RFC 2396 で同文書と考えられていたものよりも多くのものが同文書になります。 しかし、既にどう文書参照であるものの状態は変わりません。
• path 併合ルーチンを基底 URI path の結合を説明する併合ルーチンと合成した path から特別な部分である . と .. をどう削除するかを説明した点部分削除ルーチンに分けました。 点部分削除法はすべての URI 参照の path に適用されるようになり、 広く行われている実装と一致し、実際上の URI の正規化も改善されます。 この変更は委譲な参照と基底 URI が非階層的 path である同じ scheme の参照の構文解析にのみ影響します。