共通科目情報処理（上級）、インターネットの仕組み、2006年02月14日
電子・情報工学系
新城 靖
<yas@is.tsukuba.ac.jp>
このページは、次の URL にあります。
http://www.coins.tsukuba.ac.jp/~yas/ipe/inet-2005/2006-02-14
/news-hints.html
あるいは、次のページから手繰っていくこともできます。
http://www.coins.tsukuba.ac.jp/~yas/
http://www.cs.tsukuba.ac.jp/~yas/
http://www.ipe.tsukuba.ac.jp/~yshinjo/
「．」で区切られたニュース・グループの名前のうち、一番左のものを トップ・ドメイン(top domain) と呼ぶ。トップ・ドメインが同じニュース・グループは、普通、 配布範囲と AUP (Acceptable Use Policy) が共通である。 fj などの伝統的なニュース・グループは、AUP として「非営利目的の記事の み投稿してよい」という AUP を持っていることが多い。これは、企業か らの商品の広告や宣伝を禁じたものである。ただし、宣伝ではなければ、製品の 話をするのは、まったく問題がない。よい製品の評価が書かれた記事は、 歓迎される。
トップドメインの例:
サーバ限定
local
地域関連（世界に配布されているものもある）
tsukuba
kyushu
okinawa
nara
日本発世界行き
fj
japan
tnn
世界区
comp
news
sci
soc
rec
gnu
ニュース・グループの名前には、普通の英単語が使われるが、 短縮形やニュース・グループ名に使われて特殊な意味を持つものがある。
comp
sys
rec
sci
soc
lang
engr
mail-lists
misc
binaries
general
annouce
Followup-To: を付け、
以後の議論が続けたいニュース・グループを指定する。
マルチポストは、特別な場合を除いて、避けるべきである。い
くら大事で有益な情報でも、何度も同じ記事を読むことを望む人はいない。
Subject: 、大勢の読み手にとって、あなたの記事を読むか読まないかを決め
る大事なキーワードになる。記事を投稿する時には、内容を連想できるような
よい Subject: を付ける。「質問」とか「教えて」というのは、多くの場合、
適切ではない。その理由は、ネットワーク・ニュースの記事の応酬は、最初は、
質問から始まるからである。
署名は、簡潔で短いものが好まれている。「JUNETの手引き第１版」で既に 現われている目安としては、「４行以内」というものがある。
フォローアップやリプライをする時には、ニュース・リーダは、たいてい元記 事の内容がすべて引用された状態を作り出す。この場合、必要な部分だけ を引用し、かつ、引用した部分より、自分が書いた行の方が多くなるようにする。 たとえ記事をキャンセルしたとしても、即座に記事が消えるのは、自分が使っ ているサーバだけである。世界中のサーバで記事が消えるのには、普通の記事の 配送と同じように、時間がかかる。というのも、記事のキャンセルも コントロール・メッセージ と呼ばれる特殊な記事を配送することで行なわれているからである。コントロー ル・メッセージの記事が落ちると、その範囲では記事はキャンセルされずに残 ることになる。また、キャンセルする前に誰かがフォローアップ記事を投 稿している可能性もある。記事のキャンセルをする時（本当は記事を投稿す る時）には、このような仕組みを理解してから行う。フォローアップ記事を投稿するか、電子メールでリプライするかは、内容による。 普通は、フォローアップ記事を投稿することが好まれる。あなたの 返事や、その返事に対する相手からの返事が、あなた以外にも役に立つことで あれば、電子メールでリプライするのではなく、フォローアップ記事にすべき である。ネットワーク・ニュースは、大勢の人が読んでいるので、多数の電子メー ルによる返事が元記事を投稿した人の所に来る可能性がある。そうなると 元記事を投稿した人は、同じ内容の返事を何通も書かないといけなくなるかも しれない。また、元記事を投稿した人よりも他の人の方がもっとよい答えを 持っていることも多い。
◆電子メールをネットワーク・ニュース投稿する前には許可をもらう
電子メールは、紙の手紙と同じように、私信として扱うということになっている。 私信なので、基本的には、個人と個人の間での秘密のものである。他人 に見せる時には、紙の手紙を他人に見せるのと同じ程度の注意が必要である。ネッ トワーク・ニュースに投稿する時には、事前に書いた人の了解を得るべきである。 ネットワーク・ニュースは、Give & Take の精神で成り立って いる。お礼を言うのも大切だが、そりよりも、何か教えてもらったら、次 に同じ話題や自分の得意分野で困っている人を助けてあげることがより大切になる。 お礼だけの記事を読みたい人は、いない。たくさんのフォローアップがあり、 有益な情報が得られた時や、電子メールで送られてきた時には、要約を投稿す ると喜ばれる。 フォローアップ記事の場合、形式上は返事を書くようにして記事を書くが、 これは、形式上の話である。元の記事を書いた人だけではなく他にも大勢の人が 読んでいることを忘れてはならない。揚げ足とりや相手をやり込めるためだけの記事の投稿は、誰の利益にもならない。 投稿した本人の評判も下がり、かつ、大勢の読者の貴重な時間が失 われることになるからである。
ネットワーク・ニュースに出す記事の責任は、投稿者にある。ニュース・ システムの管理者や投稿者が属している組織には関係ない。どんな発言 をするのも自由であるが、この自由は、結果の責任をとることができる人が享受 すべき自由である。 ネットワーク・ニュースの前では、学生も教官も平社員も社長も皆平等になる。 この性質をうまく利用して議論を楽しむことが大切である。一部の 掲示板で見られるような、メッセージの削除の権限をもつような議長はいない。ネットワーク・ニュースでは、ニュース・グループのリストを管理するために 管理人を置いている場合が多い。その場合でも、管理人は、リストの維持 という点では特別な仕事をしているが、普段の活動では、まったく の普通の参加者と平等な立場にある。
ネットワーク・ニュースでは、意見がぶつかり合う所が面白い。 この時、お互いの意見を尊重することを忘れてはならない。説得や教育は、 ネットワーク・ニュースでは、なかなかうまくいいかない。議論の相手の 親でも教師でもない場合は、最終的には、どうすることもできないと思ってよい。
ある時期、記事の内容ではなくて、漢字変換のミス、言葉遣いの間違いなど表 面的なことだけを指摘して、元々の記事の内容につしては何もかかないという ような記事を投稿することが流行した。こういう方法は、ネットワーク・ ニュースのためのソフトウェアの開発の局面や、参加者が少ないうちには有効 だったのかもしれない。しかし今日のように、ネットワーク・ニュースの参 加者が増え、何万人という読者がいるという状況では、もはや有効な方法では なくなっている。にもかかわらず、続けているのは、個人の趣味である。他人 の趣味は尊重するのがネットワーク・ニュースですが、 この講義の受講者には、真似をしてほしくない趣味である。
ネットワーク・ニュースでは、フォローアップがフォローアップを呼んでその 話題が増えていく。投稿される記事を内容を自分が望む方向に進めるため には、この性質をうまく使うとよい。すなわち、自分でも読みたい ような記事を投稿すればよい。また、投稿してほしくないような記事を 見たら、「そんな記事を投稿するな」と投稿するよりも、無視する 方が効果的である。電子メールと共通のヘッダ
From:
Reply-To:
From: に書かれているア
ドレスが使われる、Reply-To: がある場合には、それが優先される。
Subject:
Date:
Message-ID:
Newsgroups:
Followup-To:
Distribution:
Organization:
References:
Message_ID: のリスト。
Path:
Expires:
Control:
Approved:
To: がない。その変わりに
Newsgroups: がある。
フォローアップ記事には、電子メールの返信と同様に、Subject: に
Re:がつく。ネットワーク・ニュースの記事の場合、さら
に、References: ヘッダに、元になった記事の履歴が残されている。
この履歴にそって記事を結んでいる線を
スレッド(thread)
という。ニュース・リーダの中には、１つのニュース・グループをスレッ
ドに添って記事を追いかけて読むことが簡単にできるように、記事を並べ変え
る(ソートする)機能を持っているものがある。
Subject: や From: は、読むべき記事を
選ぶために非常に重要な要素である。この時、ニュース・リーダが自動的に興味
がない記事を消してくれたら便利である。このような機能を
kill file
という。この機能を持つニュース・リーダは、kill file にかかれたパタンにマッ
チした記事を、自動的に既読として扱い、他の既読記事と同様に標準ではユー
ザに提示しなくなる。
一般に、興味がある記事を興味がない記事を自動的に分類する機能を フィルタリングという。最近では、kill file の他に、優先度を付けたり、 NoCeM などを使って spam記事 を自動的に見えないようにする機能をもっているニュー ス・リーダもあります。
Approved: ヘッダに付けられる。
ニュース・リーダには、最初から rot13, rot47 に対応しているものがある。 対応していないニュース・リーダの場合は、 nkf コマンド(サーバで動くプログラム)を使って 暗号化／復号化を行なう。次のように
nkf -r
-r オプションを付けると、標準入力を ASCII は、rot13、漢
字は、rot47 で変換して、標準出力に出する。(サーバで動作する)ニュース・リーダからこの機
能を使うには、ファイルに保存してから行なうか、パイプに対する出力機能を
利用する。
~/.newsrc
である。これは、次のような形式のテキストである。
このように、１つのニュース・グループの未読と既読の情報が１行で表現されている。 ニュース・グループの名前にコロン---------------------------------------------------------------------- news.group.name1: 1-5368 news.group.name2: 1-2978,3159 news.group.name3! ----------------------------------------------------------------------
:が付いている
ものは、サブスクライブされたものである。その後ろには、読んだ記事の番号の
リストが続く。たとえば、1-5368 は、記事番号1から5368
までを読んだことを意味する。連続していない時には、コンマ
,で区切られる。
(Unixサーバで動作する)多くのニュース・リーダで共通の形式を使っているの
で、複数のニュース・リーダを使い分けることもできる。
~/.newsrc には、もう１つ、それぞれのニュース・グループを購読
しているかどうかを記録する機能もある。上の例では、ニュース・グルー
プの名前に!が付いているものが、アンサブスクライブされた
ものである。
ニュース・リーダによっては、ユーザに、~/.newsrc の順にニュー
ス・グループを提示するものがある。このときには、時々このファイルを
sort コマンドでソートしたり、エディタで修正するとよい。
複数のサーバに接続してネットワーク・ニュースを読む場合、
~/.newsrc をサーバごとに用意する必要がある。というのも、
ここに記録される記事番号は、サーバによった異なるからである。この場合、環
境変数 NEWSRC を工夫して切り替えるか、ニュース・リーダ
の実行時のオプションで切り替える。ニュース・リーダの中(mnewsやGNUS)は、次のよう
なファイル名をまず探すものがある。
~/.newsrc-hostname
hostname は、サーバが動いているホスト名である。
Control:
というヘッダが付いた記事で、普通の記事と同じようにサーバ間を伝わってい
く。コントロール・メッセージを受け取ったサーバは、隣のサーバにコピー
するだけでなく、定められた機能を実行する。記事のキャンセルにもコント
ロール・メッセージが使われている。
Spam記事の取り扱いは、ネットワーク・ニュースで非常に大きな問題になっている。 第三者がある基準を設けてspamキャンセルすべきだと主張し、実行し ている人もいれば、第三者によるキャンセルはいかなる場合もやってはならな いとして、個人ごとやサーバごとに対処すべきだとしている人もいる。 たとえば、NoCeM という機能を使えば、ネット ワーク・ニュースに投稿されたspam記事のリストを既読にしてしまうことができる。
匿名による投稿も、問題になっている。ネットワーク・ニュースでは、伝統的に記事 に個人の本名を出すことで、個人の責任を明確にするという習慣がある。 一方で、匿名による新聞の投書と同様に、匿名が必要な局面もある。それ を援助する目的で、匿名による投稿を許しているサーバがある。しかし、 その目的を理解せず、乱用している人もいて、問題になっている。
ネットワークの AUP の他に、ネットワーク・ニュースのニュース・グループ やメーリング・リストにも AUP ある。たとえば、fj.* には、 非営利目的 の記事のみ投稿可能という AUP がある。非営利とは、企業からの広告を禁止 しているという意味で、製品の話題をしてはいけないということではない。た とえば、あるコンピュータのユーザが質問を投稿して、そのメーカの人が答え ることは、問題ないとされている。
Date: