附属書G 編集上以外の変更のまとめ G. Summary of Non-editorial Changes

訳者注：この附属書は，過去のことを知らないためか，よく分からないところが多い．．． そのために，かなり意訳(？要するに分かっていない！)している箇所がある。

G.1 追加 G.1. Additions

4. URI参照は，"URIとは何か"及び素片識別子の記述方法に関する混乱を取り除き，素片識別子は，URIの一部ではないが，URI構文及び構文解析の対象の一部になるということを与えるために追加された。さらに，URI参照の中の素片識別子の存在を説明するためにURI構文を以前に再定義しようとした他のIETF規定(HTML，HTTPなど)の使用のために，参照定義を提供している。

Section 4 (URI References) was added to stem the confusion regarding "what is a URI" and how to describe fragment identifiers given that they are not part of the URI, but are part of the URI syntax and parsing concerns. In addition, it provides a reference definition for use by other IETF specifications (HTML, HTTP, etc.) that have previously attempted to redefine the URI syntax in order to account for the presence of fragment identifiers in URI references.

2.4は，多くの誤った解釈を明確にして，十分に国際化対応をされたURIに対する余地を残すために書き直された。

Section 2.4 was rewritten to clarify a number of misinterpretations and to leave room for fully internationalized URI.

短縮URLに関する附属書Fは，テレビ及び雑誌の広告でよく見られる短くされた参照を記述し，それらが他の文脈では使用されない理由を説明するために追加された。

Appendix F on abbreviated URLs was added to describe the shortened references often seen on television and magazine advertisements and explain why they are not used in other contexts.

G.2 RFC 1738及びRFC 1808の両方からの修正 G.2. Modifications from both RFC 1738 and RFC 1808

単なるURLの代わりにURI構文に変更された。

Changed to URI syntax instead of just URL.

用語"文字符号化"，URI"文字集合"，及び%<hex><hex>形式の等価なものを用いた文字のエスケープに関する混乱を(希望的ではあるが)軽減した。文字集合に関するBNF規則の名前の多くを，その目的をより正確に示し，単にUS-ASCIIオクテットだけ以外のすべての"文字"を含むように変更した。特に示さない場合には，これらの修正は，URI構文に影響を与えない。

Confusion regarding the terms "character encoding", the URI "character set", and the escaping of characters with %<hex><hex> equivalents has (hopefully) been reduced. Many of the BNF rule names regarding the character sets have been changed to more accurately describe their purpose and to encompass all "characters" rather than just US-ASCII octets. Unless otherwise noted here, these modifications do not affect the URI syntax.

RFC 1738及びRFC 1808の両方は，文字の"reserved"(予約済み)集合を，URIを解釈するソフトウェアが予約済み目的をもつ文字の単一の集合に制限されるものとして(すなわち，文字が対応するデータ以外の何かを意味するものとして)，及びこの集合はURI方式によって固定されているとして，参照している。しかし，これは，実用上は正しくない。エスケープされる場合に異なって解釈されるあらゆる文字が，実効的には，予約済みになる。さらに，HTTPサーバ上の解釈エンジンは，単にURI方式にではなく資源に依存することが多い。予約済み文字の記述は，こうしたことに従って，変更された。

Both RFC 1738 and RFC 1808 refer to the "reserved" set of characters as if URI-interpreting software were limited to a single set of characters with a reserved purpose (i.e., as meaning something other than the data to which the characters correspond), and that this set was fixed by the URI scheme. However, this has not been true in practice; any character that is interpreted differently when it is escaped is, in effect, reserved. Furthermore, the interpreting engine on a HTTP server is often dependent on the resource, not just the URI scheme. The description of reserved characters has been changed accordingly.

プラス"+"，ドル"$"及びコンマ","の文字は，"reserved"(予約済み)集合の中に追加された。これは，問合せ構成要素内で予約済みとして扱われることによる。

The plus "+", dollar "$", and comma "," characters have been added to those in the "reserved" set, since they are treated as reserved within the query component.

チルド"~"文字は，"unreserved"(予約済みではない)集合の中に追加された。これは，幾つかのキーボードではそれを転写するのが困難だが，インターネット上で非常によく使用されることによる。

The tilde "~" character was added to those in the "unreserved" set, since it is extensively used on the Internet in spite of the difficulty to transcribe it with some keyboards.

URI方式のための構文は，すべての方式が"alpha"文字(英文字)で開始することを要求するように変更された。

The syntax for URI scheme has been changed to require that all schemes begin with an alpha character.

以前のBNFにおける"user:password"形式は，"userinfo"トークンに変更され，それが"user:password"になるかもしれない可能性は，方式固有とした。特に，暗号化されない平文でのパスワードは，構文によっては提案されていない。

The "user:password" form in the previous BNF was changed to a "userinfo" token, and the possibility that it might be "user:password" made scheme specific. In particular, the use of passwords in the clear is not even suggested by the syntax.

疑問符"?"文字は，機関構成要素における"userinfo"のために許された文字の集合から取り除かれた。これは，多くの応用がURIの残りから問合せ構成要素を分離するためにその文字を予約済みとして扱っていることが，調査の結果，分かったことによる。

The question-mark "?" character was removed from the set of allowed characters for the userinfo in the authority component, since testing showed that many applications treat it as reserved for separating the query component from the rest of the URI.

セミコロン";"文字は，機関構成要素内で予約済みとされているものに追加された。これは，幾つかの新しい方式が，利用者認証の型を示すために"userinfo"内で分離子としてその文字を使用していることによる。

The semicolon ";" character was added to those stated as being reserved within the authority component, since several new schemes are using it as a separator within userinfo to indicate the type of user authentication.

RFC 1738は，パスはスラッシュによってURIの機関の部分から分離されると規定していた。RFC 1808は，これに従ったが，構文解析アルゴリズムを示すために，その分離子を"接頭辞"として処理するその場しのぎを行った。RFC 1630は，決してこの問題をもたなかった。これは，スラッシュをパスの一部と考えたことによる。この規定を記述している際に，(実際の運用に対応するように)スラッシュをパスの一部と考えるか，又は単にそのスラッシュを保持するためだけに分離子構成要素を作成するかのいずれかを行わないと，次の二つのURIの間の違いを正確に記述し保持することは不可能であることが分かった。

RFC 1738 specified that the path was separated from the authority portion of a URI by a slash. RFC 1808 followed suit, but with a fudge of carrying around the separator as a "prefix" in order to describe the parsing algorithm. RFC 1630 never had this problem, since it considered the slash to be part of the path. In writing this specification, it was found to be impossible to accurately describe and retain the difference between the two URI 

      <foo:/bar>   及び   <foo:bar>

この規定では，前者を選択している。

without either considering the slash to be part of the path (as corresponds to actual practice) or creating a separate component just to hold that slash. We chose the former.

G.3 RFC 1738からの修正 G.3. Modifications from RFC 1738

特定のURL方式，並びにそれの方式固有な構文及び意味の定義は，別の文書に移動した。

The definition of specific URL schemes and their scheme-specific syntax and semantics has been moved to separate documents.

URLホストは，完全限定ドメイン名として定義されていた。しかし，多くのURLは，(完全限定が必要ない文脈では)完全限定ドメイン名を用いずに，(幾つかのファイルURLにおけるように)ホストを用いずに，又は"localhost"(局所ホスト)のホストを用いて，使用されている。

The URL host was defined as a fully-qualified domain name. However, many URLs are used without fully-qualified domain names (in contexts for which the full qualification is not necessary), without any host (as in some file URLs), or with a host of "localhost".

URLの"port"(ポート)は，この規定では，"1*digit"の代わりに"*digit"としている。これは，"host"と"port"との間の":"分離子が"port"なしで供給される場合を，システムは処理することが期待されることによる。

The URL port is now *digit instead of 1*digit, since systems are expected to handle the case where the ":" separator between host and port is supplied without a port.

"文脈の中でURIを区切ることの推奨"(附属書E)は，現在の実情を反映して調整された。

The recommendations for delimiting URI in context (Appendix E) have been adjusted to reflect current practice.

G.4 RFC 1808からの修正 G.4. Modifications from RFC 1808

RFC 1808(の4.)は，空のURL参照(素片識別子以外には何も含まない参照)を基底URLへの参照として定義していた。不幸なことに，その定義は，そのような参照の選択に関して，その資源上の新しい検索動作として解釈できる。それらの参照の通常の意図は，利用者エージェントが，現在の文書のビューをその文書内の指定された素片の最初に変更することであって，資源に追加的な要求を行うことではないので，空参照を正しく解釈する方法の記述が，4.に追加された。

RFC 1808 (Section 4) defined an empty URL reference (a reference containing nothing aside from the fragment identifier) as being a reference to the base URL. Unfortunately, that definition could be interpreted, upon selection of such a reference, as a new retrieval action on that resource. Since the normal intent of such references is for the user agent to change its view of the current document to the beginning of the specified fragment within that document, not to make an additional request of the resource, a description of how to correctly interpret an empty reference has been added in Section 4.

根拠のないBaseヘッダフィールドの記述は，MHTML [RFC2110]が定義するContent-Locationヘッダフィールドへの参照で置き換えた。

The description of the mythical Base header field has been replaced with a reference to the Content-Location header field defined by MHTML [RFC2110].

RFC 1808は，様々な方式を共通URI構文の特性をもつ又はもたないのいずれかとして記述していた。しかし，唯一の要件は，URI方式に関係なく，相対参照を含む特定の文書は，共通URI構文に従う基底URIをもつということだけなので，関連する記述は，それを反映するように更新された。

RFC 1808 described various schemes as either having or not having the properties of the generic URI syntax. However, the only requirement is that the particular document containing the relative references have a base URI that abides by the generic URI syntax, regardless of the URI scheme, so the associated description has been updated to reflect that.

NBNFの項<net_loc>は，<authority>で置き換えられた。これは，後者が，その使用及び目的をより正確に記述することによる。同様に，機関は，もはやIPサーバ構文に限定されない。

The BNF term <net_loc> has been replaced with <authority>, since the latter more accurately describes its use and purpose. Likewise, the authority is no longer restricted to the IP server syntax.

現在のクライアント応用の集中的な試験によって，配備されたシステムの大多数が後続のパラメタ情報を指示するために";"文字を使用していないこと，及びパス断片の中のセミコロンの存在がその断片の相対的な構文解析に影響しないことが示された。そのために，パラメタは分離構成要素としては取り除かれ，この規定ではあらゆるパス断片に出現してよい。それらの影響が，相対URI参照を解決するためのアルゴリズムから取り除かれた。附属書Cの解決の例は，この変更を反映するために修正された。

Extensive testing of current client applications demonstrated that the majority of deployed systems do not use the ";" character to indicate trailing parameter information, and that the presence of a semicolon in a path segment does not affect the relative parsing of that segment. Therefore, parameters have been removed as a separate component and may now appear in any path segment. Their influence has been removed from the algorithm for resolving a relative URI reference. The resolution examples in Appendix C have been modified to reflect this change.

この規定では，実装は，基底URIと同じ方式が接頭辞となっている正しい形式ではない相対参照(のその正しくない部分)を避けて動作してよいが，これは，<hier_part>構文を使用すると知られている方式に対してだけとする。

Implementations are now allowed to work around misformed relative references that are prefixed by the same scheme as the base URI, but only for schemes known to use the <hier_part> syntax.