Path:領域

Path: ヘッダー (ネットニュース)

[3] Path: ヘッダーは、 当該USENETメッセージ配送されてきた経路を記録するためのものでした。

仕様書

構文

[7] ホスト名を ! で区切って連結したものでした。

[8] USEFOR は色々な区切子を使い分けて意味をもたせることを提案していましたが、 互換性を失うおそれがあるとして反対もされていました。 結局 USEFOR が普及する前にネットニュースは壊滅してしまい、 新しい区切子はほとんど使われていないものと思われます。

歴史

[4] RFC 1036 2.1.6. Path

This line shows the path the message took to reach the current system. When a system forwards the message, it should add its own name to the list of systems in the "Path" line. The names may be separated by any punctuation character or characters (except "." which is considered part of the hostname). Thus, the following are valid entries:

この行はメッセージが現在の系統に到達するまでに通った経路を示します。 系統がメッセージを転送する時、「Path」(経路)行の系統の一覧に 自分の名前を追加するべきです。名前は一つあるいは複数の句読点文字 (ホスト名の一部と見なされる「.」は除く) で区切ることが出来ます。 ですから、次に挙げるのは妥当なものです。

                   cbosgd!mhuxj!mhuxt
                   cbosgd, mhuxj, mhuxt
                   @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM
                   teklabs, zehntel, sri-unix@cca!decvax

(The latter path indicates a message that passed through decvax, cca, sri-unix, zehntel, and teklabs, in that order.) Additional names should be added from the left. For example, the most recently added name in the fourth example was teklabs. Letters, digits, periods and hyphens are considered part of host names; other punctuation, including blanks, are considered separators.

(最後の経路はメッセージが decvax, cca, sri-unix, zehntel, teklabs を 順に通ってきたことを示します。) 追加する名前は左に加えるべきです。 例えば、4番目の例で一番最後に追加された名前は teklabs です。 文字 (訳注: A-Za-z のラテン文字), 数字, 句点 (ピリオド), ハイフン がホスト名の一部と見なされます。他の空白を含む句読点は 区切り子と見なされます。

Normally, the rightmost name will be the name of the originating system. However, it is also permissible to include an extra entry on the right, which is the name of the sender. This is for upward compatibility with older systems.

通常、一番右側の名前は生成系統の名前です。しかし、 送信者の名前を余分に右側に入れることも認められます。 これは古い系統との上位互換性のためです。

The "Path" line is not used for replies, and should not be taken as a mailing address. It is intended to show the route the message traveled to reach the local host. There are several uses for this information. One is to monitor USENET routing for performance reasons. Another is to establish a path to reach new hosts. Perhaps the most important use is to cut down on redundant USENET traffic by failing to forward a message to a host that is known to have already received it. In particular, when host A sends a message to host B, the "Path" line includes A, so that host B will not immediately send the message back to host A. The name each host uses to identify itself should be the same as the name by which its neighbors know it, in order to make this optimization possible.

「Path」行は返事(リプライ)には使いませんし、メイルの宛先と 取るべきではありません。これはメッセージが地方(ローカル)ホストに 到達するまでの経路を示すことを意図しています。この情報の使い道は 幾つかあります。一つはパフォーマンスのために USENET 経路選択を 監視することです。あるいは新しいホストに到達する経路を確立するという ものです。おそらく最も重要な用途は既にメッセージを受け取っていると 分かっているホストへメッセージを転送しようとして失敗する 無駄な USENET 混雑を減らすというものです。ホスト A がメッセージを ホスト B に送った時、「Path」行は A を含むので、 ホスト B は直ぐにメッセージをホスト A に送り戻すことが なくなります。各ホストが識別に使う名前はこの最適化が上手く 働くように、隣人が知っているのと同じ名前にするべきです。

A host adds its own name to the front of a path when it receives a message from another host. Thus, if a message with path "A!X!Y!Z" is passed from host A to host B, B will add its own name to the path when it receives the message from A, e.g., "B!A!X!Y!Z". If B then passes the message on to C, the message sent to C will contain the path "B!A!X!Y!Z", and when C receives it, C will change it to "C!B!A!X!Y!Z".

A ホストはメッセージを他のホストから受け取った時に 自分の名前を経路の先頭に加えます。そして、経路「A!X!Y!Z」のメッセージ がホスト A からホスト B に渡されたら、 B はメッセージを A から 受け取った時に経路に自分の名前を加えるので、「B!A!X!Y!Z」となります。 B がメッセージを C に渡せば、 C に送られるメッセージは経路 「B!A!X!Y!Z」で、 C が受け取った時、それを「C!B!A!X!Y!Z」 に変えます。

Special upward compatibility note: Since the "From", "Sender", and "Reply-To" lines are in Internet format, and since many USENET hosts do not yet have mailers capable of understanding Internet format, it would break the reply capability to completely sever the connection between the "Path" header and the reply function. It is recognized that the path is not always a valid reply string in older implementations, and no requirement to fix this problem is placed on implementations. However, the existing convention of placing the host name and an "!" at the front of the path, and of starting the path with the host name, an "!", and the user name, should be maintained when possible.

特別上位互換性についての注意: 「From」, 「Sender」, 「Reply-To」 行は Internet 式であるので、また多くの USENET ホストは まだ Internet 式を理解できるメイル・ソフトウェアを持っていないので、 「Path」頭と返事機能の関係を完全に無くすと返事を送ることが 出来なくなります。古めの実装では経路は常に妥当な返事の送り先の 文字列では無いと認められ、実装においてはこの問題を直す必要はありません。 しかし、ホスト名と「!」を経路の最初に置く、 経路がホスト名, 「!」, 利用者名で始まるという現在の慣習は可能なら 維持するべきです。

[5] son-of-RFC1036のPath:領域

[6] draft-usefor-article 6 から抜粋
      Path-content        = *( path-identity [FWS] delimiter [FWS] )
                               tail-entry *FWS
      path-identity       = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
      delimiter           = "/" / "?" / "%" / "," / "!"
      tail-entry          = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )

NOTE: A Path-content will inevitably contain at least one path-identity, except possibly in the case of a proto-article that has not yet been injected onto the network.

参考: Path-content (経路内容) は必然的に最低一つの path-identity (経路識別子) を含みます。但しまだネットワークに注入されていない 原記事の場合には一つも含まない可能性もあります。

NOTE: Observe that the syntax does not allow comments within the Path header; this is to simplify processing by relaying and injecting agents which have a requirement to process this header extremely rapidly.

参考: 構文は Path (経路) 頭中に注釈を許していないことに注意して下さい。 これは、この頭をとても速く処理する必要がある中継・注入各代理者が 単純に処理出来るようにするためです。 (以上 5.6.1 より)

   '/' The name immediately to the right is known to be the identity of
       the machine from which the article was received (either because
       the entry was made by that machine and we have verified it, or
       because we have added it ourselves).

「/」 すぐ右にある名前は記事を受信した元の機械の識別子と分かっています。 (エントリーがその機械により作られて我々がそれを確認出来るからか、 我々自身がこれを追加したから。)

   '?' The name immediately to the right is the claimed identity of the
       machine from which the article was received, but we were unable
       to verify it (and have prepended our own view of where it came
       from, and then a '/').

「?」 すぐ右にある名前は記事を受信した元の機械の自称識別子 だけど、我々はそれを確認出来ませんでした (でもって、我々自身の 出所の推測を加えたら、その時は「/」)。

   '%' Everything to the right is the pre-injection region followed by
       the tail-entry.  The name on the left is the FQDN of the
       injecting agent. The presence of two '%'s in a path indicates a
       double-injection (see 8.2.2).

「%」 tail-entry (末尾エントリー) の前までの、右側全ては注入前の領域です。 左の名前は注入代理者の FQDN です。一つの経路情報に二つの「%」 があるということは、重注入 (8.2.2 参照) を示しています。

   '!' The name immediately to the right is unverified. The presence of
       a '!' to the left of the '%' indicates that the identity to the
       left is that of an old-style system not conformant with this
       standard.

「!」 直ぐ右の名前は未確認です。「%」の左側に「!」が来た場合、 左の識別子はこの規格に適合しない古い方式の処理系です。

',' Reserved for future use, treat as '/'.

「,」 将来の利用のために予約しますので、「/」として扱います。

Other その他

       Old software may possibly use other delimiters, which should be
       treated as '!'.  But note in particular that ':', '-' and '_' are
       components of names, not delimiters, and FWS on its own MUST NOT
       be used as the sole delimiter.

古いソフトウェアは他の区切子を使うかもしれませんが、 それは「!」として扱うべきです。しかし、特に「:」, 「-」, 「_」 は名前の部品であって、区切子ではなく、 FWS はそれ単独では 区切子として使ってはいけないことに注意して下さい。

        NOTE: Old Netnews relaying and injecting programs almost all
        delimit Path entries with the '!' delimiter, and these entries
        are not verified. As such, the presence of '%' as a delimiter
        will indicate that the article was injected by software
        conforming to this standard, and the presence of '!' as a
        delimiter to the left of a '%' will indicate that the message
        passed through systems developed prior to this standard. It is
        anticipated that relaying agents will reject articles in the old
        style once this new standard has been widely adopted.

参考: 古い電子ニュース中継・注入プログラムはほとんど全て、 Path エントリーを「!」区切子で区切るので、これらのエントリーは 未確認です。ですから、「%」が区切子として現れればその記事は この規格に適合するソフトウェアにより注入されたことを示し、 「%」の左に「!」が区切子として現れればメッセージが この規格以前に開発された処理系を通過したことを示します。 これは中継代理者が、この規格が広く採用された後に旧式の記事を 却下することを予告するものです。 (以上5.6.4より)