厨子です。

　自宅を空けていたため、遅くなりまして、申し訳ありません。

"IIJIMA Hiromitsu" <delmonta@ht.sakura.ne.jp> wrote in message 
news:42F2941E.BB9FDD07@ht.sakura.ne.jp...
> なんか、私の保留票がいつのまにか賛成票にすり替えられているようで…
> 次回からはこういうときはいたん反対票を投じます。

　一応、私の認識では、保留と示していますが・・・

Message-ID: <dciin8$rn7$1@antre.cala.muzik.gr.jp>
>> 　迷惑の度合い、という基準はどう計測するのでしょうか？
>> また、どうしてもバイナリデータの添付が必要なら、その
>> グループ個々の事情で決定すればよいと思います。
> 
> ここは、結論として同意です。
> とりあえず一旦はバイナリを全面禁止してから、現状に鑑みて許容範囲は何か、
> をひとつひとつ明文化していくほうがいいように思います。

　了解しました。
　実際の運用問題としては、bincancelをどう避けるかですね。

> うーん、ちょっとこの認識は共有できません。
> japan.binaries.* 設立当時の事情は知らないし、たとえ当時はバイナリが不適切
> であったとしても、japan.* の設立から10年近く経って（たしか1996年設立でし
> たよね）ネットワーク事情がいい意味でも悪い意味でも変わってきていますから、
> 当時の結論を無条件で援用するわけにはいかないと思います。

　ここのところをいじろうと思うと、

１）ほとんどのfeederは32KBあたりで配送を制限している
２）binaryは配送しないと明言しているfeederが多い

というところをどうやっていくかですね。
　ここは、実際に、そういうバイナリを許容するグループを運用して、
問題なく運用できることを証明しないと説得は難しいと思います。

＃　記事が穴だらけになったらそれはそれで面倒だし。

　それと個人feederも廃局がこのところ目立ちますし、プロバイダ
もサービス停止したりする状況下、ちょっと色々難しいですね。
　大学系も危ない話を聞いていますし。

　それと確かに使える帯域の拡大していますが、配送や購読事情は
良好になっているかというと、そうでもないと思います。


> 一方で、私が想定しているのは、PCのトラブルの際に、小さなスクリーンショッ
> トを添付して japan.comp.windows* あたりに投稿することです。
> ただ、不用意に「スクリーンショットはOK」としてしまうと、フルスクリーンを
> 24ビットBMP形式で流す人が出てくること必定なので、きちんとしたガイドライン
> の整備（予告なしでの第三者キャンセルを含む）が必要だと思いますが。

　それは私も実際には同じ想定をしています。
　ただ、利用する人が声を上げてくれないとどういうニーズがあるのか
わからない、というのもあります。


-- 
---------------------------------------------------
 Go ride safely by motorcycles around the world !
 Naoto Zushi（厨子　直人） <news-admin@muzik.gr.jp>
---------------------------------------------------