Path: ccsf.homeunix.org!ccsf.homeunix.org!news1.wakwak.com!nf1.xephion.ne.jp!onion.ish.org!gcd.org!news.yamada.gr.jp!newsfeed.media.kyoto-u.ac.jp!oix.u-ryukyu.ac.jp!u-ryukyu.ac.jp!ie.u-ryukyu.ac.jp!not-for-mail From: kono@ie.u-ryukyu.ac.jp (Shinji KONO) Newsgroups: fj.news.policy Subject: Re: =?ISO-2022-JP?B?GyRCNXZNRiQ1JGwka0JoOzA8VCUtJWMlcyU7JWsbKEI=?= =?ISO-2022-JP?B?GyRCJEgkPRsoQiAbJEIkJiRHJEokJCRiJE4bKEI=?= Date: Sat, 23 Apr 2005 07:27:35 +0000 (UTC) Organization: Information Engineering, University of the Ryukyus Lines: 101 Message-ID: <3991740news.pl@rananim.ie.u-ryukyu.ac.jp> References: NNTP-Posting-Host: insigna.ie.u-ryukyu.ac.jp Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Trace: naha.ie.u-ryukyu.ac.jp 1114241255 3995 133.13.48.71 (23 Apr 2005 07:27:35 GMT) X-Complaints-To: news-admin@ie.u-ryukyu.ac.jp NNTP-Posting-Date: Sat, 23 Apr 2005 07:27:35 +0000 (UTC) X-Image-URL: http://www.ie.u-ryukyu.ac.jp/~kono/skono.gif Fcc: send X-Newsreader: news.pl,v 1.11 2003/10/08 11:51:01 Content-ID: <19742.1114240766.1@insigna.ie.u-ryukyu.ac.jp> Xref: ccsf.homeunix.org fj.news.policy:3412 河野真治 @ 琉球大学情報工学です。 第三者キャンセルを受け入れるかどうかは、サーバ単位で判断でき ます。「キャンセルがどうのこうの」とか言ってますけど、fj.news. lists.filters は、既にあるわけだから、既に現実に行われている わけなんですよね。 リーダ単位で処理するのは、経験的にはちょっと重い。でも、misen とか sugawara とかは読む内容がないから、目を通したとしても1 回だけで、他のは*僕でさえ*読まないです。普通の人はリーダで filterringしているだろうから、気づいてもいないでしょう。 だから、問題は、 (fj の読者の大半であろう)初めてfjに触れる人達 だけなんですよね。その時に、 misen misen misen sugawara sugawara sugawara sugawara とか、並んでいるのはどうなのかってことだです。まぁ、2ch も、 そんなものなので、それでいいのかも知れないが、2ch でさえ、ひ どいものは消されてますよね。 In article , Yoshitaka Ikeda writes > 一度、許容される第三者キャンセルとそうでないものについて > コンセンサスを取っておいた方がよいのではないかという気がします。 misen/sugawara を含んだコンセンサスは取れないでしょうね。比 較的小人数で基準をまとめて、キャンセル/フィルタを実行するメ カニズムを提供すれば良いと思います。 > 1.運用上の理由 > 1-1. NetNews配送システムに多大な影響を及ぼす。 > NNTPサーバ等を停止させたり障害を起こすことが目的の記事 > 　1-2. NewsReaderに影響を及ぼす。 > ある種のクライアントを停止させたり障害を起こすことが目的の記事 日本語の記事がそう思われていたこともあった... エスケープシー ケンスで端末を発狂させたりとか... 今は、Net News では、ほと んどないですね。初期の頃はスプールが溢れるとかあったけど。 あと、rmgroup とかだな。 > 2.ネットワークセキュリティ上の理由 > 2-1. ウイルス、ワーム等の含まれた記事 > 　2-2. ある種のクライアントでバッファオーバーフローなどを > 　　　起こさせることが目的の記事 これは、チェックしているところから文句がくる場合があります。 > 3.ニュースグループ運営ポリシー上の理由 > 3-1. 非バイナリグループでのバイナリ投稿 > 　5-2. 著作権のある著作物そのものの投稿 これは明解なんだけど... > 　3-2. 明らかにニュースグループの目的を逸脱した投稿 > 4.個人情報に関する理由 > 4-1. 削除者本人の望まない個人情報の掲載された記事 > 　4-2. 第三者の望まないであろう個人情報の記載された記事 これは判断は難しいですね。 > 5.著作権に関する理由 > 5-1. 著作者本人の望まない転載(引用除く)の記事(著作者本人によるキャン > セル) これは良くわからないです。 > 6.混乱防止 > 　6-1. 削除者本人のメールアドレスで他人から投稿された記事 > 　6-2. 削除者本人を名乗った他人から投稿された記事 > 　6-3. 匿名プロキシ等から投稿された記事 判断できればってところですね。 > 7.AUP上の理由 > 7-1. 営利投稿 これは現状では問題にならないでしょう。なるようになったらすごい。 僕は、営利投稿容認が良いと思います。営利ニュースグループを 作っても良いし。fj.vender.* とか fj.shop.* みたいな。 > 分類もおかしいかもしれませんし、理由の一覧としても充分かどうかはわかり > ませんが、これらの理由におけるキャンセルが > a.「機械的に実行」 > b.「人為的に(合意を取らずに)実行」 > c.「合意の元で実行」 > d.「いかなる場合もキャンセルするべきではない」 > というどれかにマッピングされることになると思います。 読む方に取っては、どれでも差はないですね。 キャンセル組織を作るとして、その受け入れ口を作ると、結構、爆発 しそうだ... --- Shinji KONO @ Information Engineering, University of the Ryukyus 河野真治 @ 琉球大学工学部情報工学科