From: takagi@center.nitech.ac.jp (TAKAGI Hiromitsu)
Real-Date: Thu, 17 Aug 95 22:21:31 +0900
Subject: [infotalk,05333] Re: Questionnaire about nuclear testing by France
Message-Id: <9508171321.AA06069@oracion.center.nitech.ac.jp>
> > http://www.tv-asahi.co.jp/ から辿れますが
> > Netsacapeでないと飛べないので URL 書いときます。
> > http://www.flex.co.jp/station/
> 有用な情報をありがとうございました。最近、Netscapeじゃないと。。。という
> ページが多くて(;_;)です。
とかいっているまに、ちょうど今、ニュースステーションで紹介されましたね
(tv-asahi の方だけですが)。
＃ 「：」や「//」「.」を久米ちゃんがなんと読むかに興味深いものがあった…
んー今アクセスしてみたら反応が鈍い…。やはりアクセスが殺到している
のでしょうか。
> > まったく 東大より前にやってたらインパクトあったのに。
> インパクトの問題じゃないと思うのですが。。。。
確かに。
＃あ〜また内容がない…。
たかぎひろみつ＠名工大
From: Koji ANDO <chutzpah@race.u-tokyo.ac.jp>
Real-Date: Thu, 17 Aug 1995 21:35:25 +0900
Subject: [infotalk,05332] Re: Questionnaire about nuclear testing by France
Message-Id: <199508171235.VAA28489@shiva>
東大の安東です。
> http://www.tv-asahi.co.jp/ から辿れますが Netsacapeでないと飛べないの
> で URL 書いときます。
> http://www.flex.co.jp/station/
有用な情報をありがとうございました。最近、Netscapeじゃないと。。。という
ページが多くて(;_;)です。
> まったく 東大より前にやってたらインパクトあったのに。
インパクトの問題じゃないと思うのですが。。。。
--------------------------------------------------------------------
Koji ANDO <chutzpah@race.u-tokyo.ac.jp>
Design Science Group, Research into Artifact Center for Engineering,
the Univ. of Tokyo
URL: http://www.race.u-tokyo.ac.jp/users/chutzpah/
Phone: +81-3-5453-5882 FAX: +81-3-3467-0648
From: IIJIMA Akihiro <aki@noc.titech.ac.jp>
Real-Date: Thu, 17 Aug 1995 18:43:24 +0900
Subject: [infotalk,05331] Questionnaire about nuclear testing by France
Message-Id: <199508170943.SAA25845@ns1.noc.titech.ac.jp>
昨日の TV朝日の 「ニュースステーション」で
フランスの核実験に関するアンケート を電話とFAXでやるという
話になったとき、 久米さんが 「Internetでもやりましょう」と
言ったかいわんか知らんが、(伝聞なので)
アンケートのページが出来てました。
http://www.tv-asahi.co.jp/ から辿れますが Netsacapeでないと飛べないの
で URL 書いときます。
http://www.flex.co.jp/station/
まったく 東大より前にやってたらインパクトあったのに。
--
東京工業大学 Titanet 運用センター
飯島 昭博 (Akihiro Iijima) aki@noc.titech.ac.jp
From: Yamada Yutaka <yutaka@tokai.iij.ad.jp>
Real-Date: Thu, 17 Aug 1995 13:27:48 +0900
Subject: [infotalk,05330] Peeping Pages (Re: California Weather serve)
Message-Id: <199508170427.NAA14301@hida.tokai.iij.ad.jp>
> イギリスの大学のコーヒーポットの実況中継のURLを御存知の方、
> いらっしゃましたら教えて下さい。
http://www.cti.co.jp/personal/tss/links/
に各種実況中継ページへのリンクがあります。
一番最後のなんて、人が入っているときはどうなるんだろう。(^^;
いろんなところに悪用されたら嫌ですね。
----
山田 豊(Yamada Yutaka), yutaka@tokai.iij.ad.jp
株式会社 アイアイジェイ東海 運用部
From: Tokio Kikuchi <tkikuchi@is.kochi-u.ac.jp>
Real-Date: Thu, 17 Aug 95 13:28:00 JST
Subject: [infotalk,05329] Re: Domain name
Message-Id: <9508170428.AA03905@notos.is.kochi-u.ac.jp>
菊地＠高知大です。
> という価格体系なのだそうです。(プロバイダの人にもらった情報です)
>
ftp://ftp.nic.ad.jp/pub/jpnic-pub/jpnic-saisoku.txt
というやつですね。
> プロバイダはたぶんこの料金をユーザに転嫁するはずですが、その単価が大口
> プロバイダほど安くなるわけです。１ユーザーしかいなかったら100万課金する
> ことになりますけど、１０００ユーザーなら6000円の課金ですから。
ユーザー全員がドメイン取ったらそういうことですが、
参加組織数ということですから。但し、主たる会員が
個人であるネットワークの会員数でも区分されています。
> ということで、「大口加入のほうが割安」と申しあげました。
ドメインだけを考えれば、例えば「大口」は取得代行
をやってくれたりしますから、（JPNICへの問い合わせ
とか redirect できる）多少の割引は期待するでしょう。
>
> 「ドメイン名称資源の無駄使い」というのが冗談だと知ったのは、投稿したあ
> とでしたので、ああいう反論(？)みたいなのをしてしまったのです。すんませ
> ん。
>
いえ、冗談に聞こえなかったでしょう。こういうものは
食えるものではないので、怒っても冗談でやります。
---------------------------------------------------
<a href="http://www.is.kochi-u.ac.jp/~tkikuchi/">
菊地時夫 tkikuchi@is.kochi-u.ac.jp
高知大学理学部情報科学科 Tel:0888-44-8336(direct)
780 高知市曙町2-5-1 Fax:0888-44-8361 </a>
---------------------------------------------------
高知大学卒業生ＭＬ（鯨ネット）参加者募集中
..............kujira-net-request@is.kochi-u.ac.jp
From: TAKADA Toshihiro <takada@mdma.brl.ntt.jp>
Real-Date: Thu, 17 Aug 1995 13:00:32 +0900
Subject: [infotalk,05328] Re: draft-ietf-html-i18n-00.txt
Message-Id: <199508170400.NAA21468@mdma.brl.ntt.jp>
たかだです。
In article <9508162335.AA21843@dec218.aist-nara.ac.jp> you write:
>まだ中を見てませんが今朝こう言うのが流れてきました。
>タイトルだけに反応して転送することにします。
> ...
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories. This draft is a work item of the HyperText Markup Language
>Working Group of the IETF.
> Title : Internationalization of the Hypertext Markup Language
> Author(s) : F. Yergeau, G. Nicol, G. Adams, M. Duerst
> Filename : draft-ietf-html-i18n-00.txt
> Pages : 42
> Date : 08/15/1995
ざっと目を通しただけですが、要は、
1) 文字集合としてISO 10646 UCS-2を使った場合のHTMLを定義した(DTD付)。
2) で、HTTPの"charset"パラメタで"ISO-10646-UCS-2"が指定されている場
合は、この形式に基づくHTMLとして処理すべし、と言っている。
3) 但しHTML 2.0そのものとしては、ISO 8859-1をat leastでサポートして
いればよい(本当は8859-1＋αだけど詳細は略)、とも言っている。
てなとこでしょうか。
これはこれで完結した世界なので、これに文句付けるとしたら哲学論争し
か残ってないでしょう。:-b
で、ミソは3)で、もしそうならば、ISO-2022-INT-*でも何でもいいから、
まあそういったHTMLを定義して、このinternet-draftと並列させる、とい
う手もあるのではないでしょうか。
＃ そんなものが並列するのが美しい世界かと言われると、そんなことは全
＃ くありませんが、世の為人の為にはそれでもいいんじゃないかと。どの
＃ みちそれらを両方とも理解するようにインプリするのはそれ程難しくな
＃ いし。(最終的にはそれらを両方含んだ形でのspecを決められれば良い
＃ のですが、それもおいといて、と。)
で、(と勝手に話を飛ばしてますが)、そのためには2022-basedなHTMLの仕
様をちゃんと提出しないといけない訳です。もし仮に2022-basedなHTMLの
仕様を記述するとしたら、DTDはどうやって書けば良いのでしょうか。
(質問1) 2022-basedのような状態遷移を含む形態を記述することは、そも
そもSGMLの枠組みで可能なのか？ そんなDTDは書けるのか？
(質問2) もし書けるとしたら、どうやって書けばよい？
(質問3) これから書き方を勉強するとしたら例えば何を読めばよい？
(質問4) 誰か書いてくれる人いますか？ :-)
といった質問へのお答えをお持ちの方、いらっしゃいましたら、ぜひ、教
えてください。
ほいでは。
========================================================================
NTT Basic Research Labs. TAKADA Toshihiro
<http://www.ntt.jp/people/takada/> takada@mdma.brl.ntt.jp
========================================================================
From: Takanori Fumeno <taka@tin.com>
Real-Date: Wed, 16 Aug 1995 23:40:00 -0400
Subject: [infotalk,05327] Re: Domain name
Message-Id: <199508170340.XAA13898@neptune.kdd.net>
冨米野です。
From: masayang@msushi.com
Subject: [infotalk,05326] Re: Domain name
Date: Thu, 17 Aug 95 12:09:20 +0900
> プロバイダはたぶんこの料金をユーザに転嫁するはずですが、その単価が大口
> プロバイダほど安くなるわけです。１ユーザーしかいなかったら100万課金する
> ことになりますけど、１０００ユーザーなら6000円の課金ですから。
これだと、たまりませんね。
ユーザに転嫁するという前提ですが、接続している組織が少ない程
高くなるというのは、なんか矛盾を感じます。
> でも、それなりに頑張っているという事実は認めますが、日米の価格差はすご
> いものがあります。
>
> ここを「しかたない」と諦めるか、「がんばってなんとかする」かは大きな違
> いと思います。
インターネットプロバイダのみの問題でもないように
思えますが、価格差すごいですね。(言ってる自分が悲しいですが。)
余談ですが、月曜から金曜の９時〜１７時の保守でいいから、無茶苦茶
安い専用線サービスとかないかしら。
> 寿司なんかもそうですよね。一般には高いです。でも、そこをなんとかして安
> い流通経路を切り開いているチェーン／フランチャイズのところとか、産地直
> 送のネタのところとか、いろいろ考えているところはあります。(昌寿司も米
> についてはいろいろやっているはず)
>
> が、ことインターネット通信については、仕入が独占ですから。。。。(溜息)
JPNICに対抗する組織ができたりして。
> 寿司もインターネット通信ももっと気軽に楽しめるべきですよね。
そうですね。
冨米野
From: masayang@msushi.com
Real-Date: Wed, 16 Aug 1995 20:06:55 -0700
Subject: [infotalk,05326] Re: Domain name
Message-Id: <199508170306.UAA05616@chirashi.msushi.com>
>>>>> On Thu, 17 Aug 95 01:28:43 +0900, OKI Yukihiro <yoki@beams.nagaokakyo.kyoto.jp> said:
masa> うーん。そういう考えもたしかにありますね。だとしたら、今のJPNICの
masa> 「大口加入のほうが割安」ってのも改めてほしいなぁ。
masa> でも、企業ユーザは安い方に流れると思いますです。
>> 大口加入の方が割安というのはどういう意味ですか？
プロバイダにJPNICが課金する際の話なのですが、JPNICのネームサーバへの登
録料は毎年３月末に接続されている「組織の数」(ドメイン数に相当すると思
う)で決まるそうですが、
1-10 100万
11-20 150万
21-30 200万
31-50 250万
51-100 300万
101-200 400万
301-500 500万
501-700 550万
701-1000 600万
という価格体系なのだそうです。(プロバイダの人にもらった情報です)
プロバイダはたぶんこの料金をユーザに転嫁するはずですが、その単価が大口
プロバイダほど安くなるわけです。１ユーザーしかいなかったら100万課金する
ことになりますけど、１０００ユーザーなら6000円の課金ですから。
ということで、「大口加入のほうが割安」と申しあげました。
「ドメイン名称資源の無駄使い」というのが冗談だと知ったのは、投稿したあ
とでしたので、ああいう反論(？)みたいなのをしてしまったのです。すんませ
ん。
masa> 日本に帰ってからも、なんかのドメイン名を取って、自宅にサーバーを置
masa> こうとしていたのですが、JPNICのこういう規則(？)を知ってからは、
masa> msushi.comを継続して使用していこうと決心しました。
>> これは，自分でドメイン名をJPNICに申請するのが面倒だからということですか？
いえ。msushi.comを使用し続けるのなら、専用線による月額の接続料金を安く
してくれるというプロバイダがいるからです。(月額３万以下ということです)
安くなる根拠は前記のJPNICに払う料金を転嫁しないから、です。
>> 日本のインターネットプロバイダの価格設定はアメリカのそれに対して高いとい
>> う事実はいうまでもありませんが，利用者数の違いや通信料金の違い，ルータな
>> ど通信機器が日本にはいってきた時の値段などを考えるとそれなりに頑張ってい
>> るんじゃないかなぁと思います。（お寿司屋さんではネタの仕入れ値に日米格差
>> なんか感じることはないんでしょうか…）
プロバイダの人達を責める気持はあんまりありません。(いろいろと家内と調
査しましたが、中には「ちょっとひどいんじゃないの？」って言いたくなると
こもありましたが、、、) どこも、あれだけ高い仕入価格でがんばっていると
思います。
でも、それなりに頑張っているという事実は認めますが、日米の価格差はすご
いものがあります。
ここを「しかたない」と諦めるか、「がんばってなんとかする」かは大きな違
いと思います。
寿司なんかもそうですよね。一般には高いです。でも、そこをなんとかして安
い流通経路を切り開いているチェーン／フランチャイズのところとか、産地直
送のネタのところとか、いろいろ考えているところはあります。(昌寿司も米
についてはいろいろやっているはず)
が、ことインターネット通信については、仕入が独占ですから。。。。(溜息)
寿司もインターネット通信ももっと気軽に楽しめるべきですよね。
なかむら
From: eyre@ICSL.UCLA.EDU (Beverley Eyre)
Real-Date: Wed, 16 Aug 1995 19:47:54 -0700 (PDT)
Subject: [infotalk,05325] Re: Netscape SSL Key broken - a report from
Message-Id: <199508170247.AA27072@synergy.icsl.ucla.edu>
From: Kenji Rikitake <kenji@rcac.tdi.co.jp>
Real-Date: Thu, 17 Aug 1995 11:44:36 +0900
Subject: [infotalk,05324] Re: Netscape SSL Key broken - a report from
Message-Id: <199508170244.LAA17693@daemun.rcac.tdi.co.jp>
In message <9508170238.AA15114@alpha211.aist-nara.ac.jp>
youki-k@is.aist-nara.ac.jp (Youki Kadobayashi) writes:
]40bit RC4 だから破られて当然じゃないですか？ 所詮 "exportable" だし。
]メールに署名するときでさえ 1024bit の鍵を使う時代ですからね。。。
まったくその通り。ここにSSLの話を転載したのは、単に破られたという事実
を示したかったからに過ぎません。理論的に弱いというだけでは、なかなか信
じてもらえないのも事実だから。
// Kenji
From: nt@sfc.keio.ac.jp (takenaka naozumi)
Real-Date: Thu, 17 Aug 95 11:40:01 +0900
Subject: [infotalk,05323] Re: Netscape SSL Key broken - a report from France
Message-Id: <v01520d00ac58d95df903@[202.17.214.19]>
At 11:15 8/17/95, Kenji Rikitake wrote:
>SSL challenge -- broken
おおこれは！
40ビット程度じゃ簡単に破れるなあと思ってたら
もう糸口をつかんだ人がいるんだ。
まあ隠されて黙って覗かれるよりもいいですし、メールをポストしたひとも「当局」が
傍受するのを懸念してるわけですから、どちらかというと心配するよりは喜ぶほうがこ
の場合適当なのかもしれませんね。
Netscape社の今後の対応が楽しみです。
というわけで、infotalkにはじめてポストさせていただきました。
たけなかともうします。
URLはhttp://beatbox.sfc.keio.ac.jp/new/です。
今後ともよろしくお願いいたします。
----
-- nt@sdw.com is better than the others when you respond this mail.
----
GCM/TW/O d-- H- s-:- g- !p !au a- w+ v C++ UIS++ UBX++++ P+ L 3+ N+ E+ K-
!W M+ !V -po+ Y+(+) t 5 !j R G+ tv- b++ D+ !B e* u** h---- f? r++(+) n+ y+
From: Youki Kadobayashi <youki-k@is.aist-nara.ac.jp>
Real-Date: Thu, 17 Aug 1995 11:38:00 +0900
Subject: [infotalk,05322] Re: Netscape SSL Key broken - a report from France
Message-Id: <9508170238.AA15114@alpha211.aist-nara.ac.jp>
>>>>> On Thu, 17 Aug 95 11:15:12 +0900,
Kenji Rikitake <kenji@reseau.toyonaka.osaka.jp> said:
> SSL challenge -- broken
40bit RC4 だから破られて当然じゃないですか？ 所詮 "exportable" だし。
メールに署名するときでさえ 1024bit の鍵を使う時代ですからね。。。
// youki
From: Kenji Rikitake <kenji@rcac.tdi.co.jp>
Real-Date: Thu, 17 Aug 1995 11:22:29 +0900
Subject: [infotalk,05321] Re: Domain name
Message-Id: <199508170222.LAA17243@daemun.rcac.tdi.co.jp>
In message <199508160813.RAA22836@azalea.kawasaki.flab.fujitsu.co.jp>
kimai@flab.fujitsu.co.jp (IMAI Yuji) writes:
] そういえば、org,eduや、jpの下のac,co,goなどの、団体の性格による分類
]というのも、結構意味がないですよね。意味がないだけじゃなくて、AUPに関
]する無用の混乱を助長すると、忌み嫌う人もいましたっけ。
忌み嫌っている私です :-) もはやacademicサイトを分離して運用する必要は
なくなったんですから、.jp直下に組織名を持ってくることも可能でしょう。
(日本と同様のpolicyの国は、.au, .kr, .nz, .ukとかけっこうありますけどね)
ntt.jpは既得権の主張じゃないですか。同様にnttdata.jp, kek.jpとありますけど。
] comドメインの爆発問題も、実装と運用の問題に入るんでしょうか？＞力武さん
運用の問題になると思います。.comのserver同士がなんらかの形で密に
integrityを保たないといけないわけですから。
] ところで、上の文は、運用と実装を混同していませんか？それとも、力武さ
]んは、rootのauthority配置方針を含めた運用は、Domain Name Systemの広義
]の「実装」に含まれるという立場を取ってみえるのでしょうか。
確かに運用と実装という言葉の区分けがあいまいですね。私が書きたかったの
は、巨大なDNS全体にとっては、root serverなどの物理的配置は、実装の問題
として議論すべきだろうと思ったからです。一般的には、運用の問題として議
論されるんでしょうけどね。あまり厳格な区別はしていません。
// Kenji
From: Takao KUMAGAI <je1cka@dumpty.nal.go.jp>
Real-Date: Thu, 17 Aug 1995 11:21:47 +0900
Subject: [infotalk,05320] Re: mailbot
Message-Id: <199508170221.LAA24095@dumpty.nal.go.jp>
on 95/08/16, 22406680@people.or.jp writes:
: 長尾＠ｎｅｔｔａｌｋです。
: それから、現在 digiweb 稼動中ですので、早くドメインとりたい人は、
: 申し込まれるとよいでしょう。ドメイン登録は、２５ドル、初期費用が２０ドル
: 毎月が２０ドルですから、人によってはお得です。できるのかどうかしりません
: が、有名な会社のをとって売却すると儲かるかもしれません。
先程 http://digiweb.com/でアクセスできたのですが、そこから
他のページには host unreachableで見ることが出来ません。
８月一杯は、ドメイン取得費用無料だそうです。
T1を使っていると書いてありますが、余りレスポンス良く有りません
し、設定が悪いのか、担当サーバーが夏休みしてるのかわかりません
が、この状態では安かろう／悪かろう、かもしれないという不安があ
ります。
--------
くまがいた！ <je1cka@nal.go.jp>
熊谷隆王 JE1CKA/KH0AM
We are Information Volunteers! Let's Learn & Share!
*nettalk producer* Tadashi Nagao
From: Kenji Rikitake <kenji@reseau.toyonaka.osaka.jp>
Real-Date: Thu, 17 Aug 1995 11:12:54 +0900
Subject: [infotalk,05319] Netscape SSL Key broken - a report from France
Message-Id: <199508170212.LAA14293@reseau.reseau.toyonaka.osaka.jp>
-----BEGIN PGP SIGNED MESSAGE-----
SSL challenge -- broken
This is to announce the solution of the SSL challenge posted by Hal
Finney on July 17, 1995 (message-ID: <3u6kmg$pm4@jobe.shell.portal.com>),
also found at: <URL:http://www.portal.com/~hfinney/sslchal.html>
The 40-bit secret part of the key is 7e f0 96 1f a6. I found it by a brute
force search on a network of about 120 workstations and a few parallel
computers at INRIA, Ecole Polytechnique, and ENS. The key was found after
scanning a little more than half the key space in 8 days.
The cleartext of the encrypted data is as follows:
The SERVER-VERIFY message is:
9C B1 C7 83 D9 BB B7 75 01 6F 19 19 03 58 EC 05 MAC-DATA
05 MSG-SERVER-VERIFY
AF 84 A7 79 F8 13 69 20 25 9B 53 A0 60 AE 75 51 CHALLENGE
The CHALLENGE part is a copy of the challenge sent by the client in its
first message.
The answer is the CLIENT-FINISHED message:
22 BB 23 39 55 B0 7F B6 1A B0 35 85 F7 DB C1 E5 MAC-DATA
03 MSG-CLIENT-FINISHED
BF EB 90 F8 2C 0C E1 EA 18 AC 11 4C 83 14 21 B6 CONNECTION-ID
The next message is SERVER-FINISHED:
D4 CD F3 4E 38 F1 2B 1E DC FD 72 C8 34 02 CD FF MAC-DATA
06 SERVER-FINISHED-BYTE
23 1C 05 40 60 72 49 6E 83 BA D1 28 CC 9B 5F 63 SESSION-ID-DATA
Then comes the data message sent by the client. This is the juicy one.
I have broken the contents into its fields (the body was just one long
line)
72 23 B5 98 0D D0 07 1A DA F1 C7 A4 40 41 5A 10 MAC-DATA
POST /order2.cgi HTTP/1.0
Referer: https://order.netscape.com/order2.cgi
User-Agent: Mozilla/1.1N (Macintosh; I; PPC)
Accept: */*
Accept: image/gif
Accept: image/x-xbitmap
Accept: image/jpeg
Content-type: application/x-www-form-urlencoded
Content-length: 472
source-form=order2-cust.html&
order_number=31770&
prod_80-01020-00_Mac=1&
carrier_code=UM&
ship_first=Cosmic&
ship_last=Kumquat&
ship_org=SSL+Trusters+Inc.&
ship_addr1=1234+Squeamish+Ossifrage+Road&
ship_addr2=&
ship_city=Anywhere&
ship_state=NY&
ship_zip=12345&
ship_country=USA&
ship_phone=&
ship_fax=&
ship_email=&
bill_first=&
bill_last=&
bill_org=&
bill_addr1=&
bill_addr2=&
bill_city=&
bill_state=&
bill_zip=&
bill_country=USA&
bill_phone=&
bill_fax=&
bill_email=&
submit=+Submit+Customer+Data+
This order came from Mr Cosmic Kumquat, SSL Trusters Inc.,
1234 Squeamish Ossifrage Road, Anywhere, NY 12345 (USA).
Unfortunately, Mr Kumquat forgot to give his phone number, and the
server's reply (in two packets) is:
09 12 AD FE A5 A9 BF D1 8C 8C E2 6A A3 48 B9 75 MAC-DATA
HTTP/1.0 200 OK
Server: Netscape-Commerce/1.1
Date: Wednesday, 12-Jul-95 05:40:30 GMT
Content-type: text/html
1C CD C4 3D 80 F1 7B 94 11 AC E8 72 B1 99 BC FA MAC-DATA
<TITLE>Error</TITLE><H1>Error</H1>
The shipping address you supplied is not complete. The street address,
city, state, zip code, country and phone number are mandatory fields.
Please go back and specify the full shipping address. Thank you.
This result was found with a quick-and-dirty distributed search program,
which I wrote when I realized that the cypherpunks were going to be a few
weeks late with their collective effort. When the program was running,
it took little more than one week to find the key (it would have taken about
15 days to sweep the entire key space). I ran it on almost all the machines
I have access to, summarized in the following table:
type speed (keys/s) number notes
- --------------------------------------------------------
DEC (alpha) 18000-33000 34
DEC (MIPS) 2500-7500 11
SPARC 2000-13000 57
HP (HPPA/snake) 15000 3
Sony (R3000) 1100-4000 3
Sun 3 600 2
Sequent B8000 100 x 10 1 (1)
Multimax (NS532) 600 x 14 1 (1)
KSR 3200 x 64 1 (1) (2)
Notes:
1. These are multiprocessor machines
2. The KSR spent only about 2 days on this computation.
The total average searching speed was about 850000 keys/s,
with a maximum of 1350000 keys/s (1150000 without the KSR).
Conclusions:
* Many people have access to the amount of computing power that I used.
The exportable SSL protocol is supposed to be weak enough to be
easily broken by governments, yet strong enough to resist the attempts
of amateurs. It fails on the second count. Don't trust your credit
card number to this protocol.
* Cypherpunks write code, all right, but they shouldn't forget to run it.
I want to thank the people at INRIA, Ecole Polytechnique, and Ecole
Normale Superieure for giving their CPU time. (Most of them are on
vacation anyway...)
You can find a copy of this text at
<URL:http://pauillac.inria.fr/~doligez/ssl/announce.txt>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCSAwUBMDG4dVNZwSQVabihAQGeFAPnUZil4WlauoMke9HaULDNOVf1hLXS0i9U
VJWZsPHcihDbn6nBN9T6f3sW/S08N5YJFSCmuZzqO59c0nOAKILb6a3TsXjFEcu8
W8UfwFsZa6gx7iuYqandhoHBEkkc5NSwMe1f+lPiV2MdclzQ4/VtZ7Oa1VB+RftD
Am4+w/Y=
=Fju1
-----END PGP SIGNATURE-----
**** This is a timestamp of the above message:
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQBVAwUAMDGsOeWrvYiumrHZAQF0QwIAnDWdVVTiVmUTY5lp08yPeLRoFetczb+U
E0WVgTUJ4a16tinOPaJl/6jOpPUUPWMjkDaD2N1xw8lGqm0UgZJiGIkAkgMFATAx
uKJTWcEkFWm4oQEBAQ8D5ixvYrpEAQYfeNXmbB46BTTnBwBPS/JjfVFEEnC0Zsoj
cyh/WELUsZf785b23vEq9JFvZB+bq1UsJTpttl335TrW344ZYof3kl6fdEF2Jf5q
LxQjkuP9s/OQX5iJZpHz4LUxbb+/hOwSdZ2O3LV7ETiHs9AK1+bnKfOGDyei
=qO7V
-----END PGP MESSAGE-----
From: hayakawa@aether.hil.ntt.jp (Kazuhiro Hayakawa)
Real-Date: Thu, 17 Aug 1995 11:15:06 +0900
Subject: [infotalk,05318] VRML Viewer for Mac w/ QD3D
Message-Id: <199508170212.LAA13566@aether.hil.ntt.jp>
早川＠ＮＴＴです。
>> VRMLを見ることができません。（画面に何も出ない。）
>データが全く画面に表示されないことも多く、原因を調べています。
>３次元スキャナーから作った自前のVRMLデータはちゃんと読めましたが。。。。。
その後、正しく見ることができるものもあることがわかりまし
た（http://jaka.eecs.uic.edu/dave/vrml/CAVE/の下のものな
ど。）
一方、見ることができないものでたとえば
http://www.sgi.com/Products/WebFORCE/WebSpace/vrml/Palladio/Palladium.wrl.gz
http://www.sgi.com/VRML/island.wrl.gz
などは、
Content-encoding: x-gzip
で送られきますが、送られてきたデータがgzip1.2.4ではうま
く解凍できないようです。（私のところではdelegatedから
zcatを呼んで解凍してからMacへ送るようにしています。）
解凍できれば、たぶんWhurlwindでも見ることができるでしょ
う。
早川 和宏 (hayakawa@aether.hil.ntt.jp)
ＮＴＴヒューマンインタフェース研究所
映像処理研究部
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Thu, 17 Aug 1995 09:00:47 +0900
Subject: [infotalk,05317] Re: draft-ietf-html-i18n-00.txt
Message-Id: <199508170000.JAA09942@coo.wg.omron.co.jp>
えっと、infotalk ML にさきほど私が出したメールですが、
なぜか Content-Type: の2行目がちょんぎれて返ってきました。
そのため一部の方には正しく読めなくなっていたことと思います。
次のように書き換えれば読めるようになりますです。
誤> Content-Type: Multipart/Mixed;
正> Content-Type: Multipart/Mixed;
正> boundary="--Next_Part(Thu_Aug_17_08:34:17_1995)--"
それでは。
From: Noritoshi Demizu <demizu@nff.ncl.omron.co.jp>
Real-Date: Thu, 17 Aug 1995 08:35:31 +0900
Subject: [infotalk,05316] draft-ietf-html-i18n-00.txt
Message-Id: <9508162335.AA21843@dec218.aist-nara.ac.jp>
----Next_Part(Thu_Aug_17_08:34:17_1995)--
Content-Type: Text/Plain; charset=iso-2022-jp
まだ中を見てませんが今朝こう言うのが流れてきました。
タイトルだけに反応して転送することにします。
----Next_Part(Thu_Aug_17_08:34:17_1995)--
Content-Type: Message/rfc822
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;@IETF.CNRI.Reston.VA.US
cc: html-wg@oclc.org
Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-to: Internet-Drafts@CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-html-i18n-00.txt
Date: Wed, 16 Aug 95 17:32:45 -0400
X-Orig-Sender: cclark@CNRI.Reston.VA.US
Message-ID: <9508161732.aa21503@IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Markup Language
Working Group of the IETF.
Title : Internationalization of the Hypertext Markup Language
Author(s) : F. Yergeau, G. Nicol, G. Adams, M. Duerst
Filename : draft-ietf-html-i18n-00.txt
Pages : 42
Date : 08/15/1995
The Hypertext Markup Language (HTML) is a simple markup language used to
create hypertext documents that are platform independent. Up to the
present time, the application of HTML on the World Wide Web was seriously
restricted by its reliance on the ISO-8859-1 coded character set, which is
appropriate only for Western European languages. Despite this restriction,
HTML has been widely used with other languages, using other coded character
sets or character encodings, through various ad hoc extensions to the
language.
This document is meant to address the issue of the internationalization
of HTML by extending the specification of HTML 2.0 and giving additional
recommendations for proper internationalisation support. A foremost
consideration is to make sure that HTML remains a valid application of SGML,
while enabling its use in all languages of the world.
The "text/html; version=2.x" Internet Media Type [RFC1590] and MIME
Content Type [RFC1521] is defined by this specification, taken together
with the HTML 2.0 specification [HTML-2].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-html-i18n-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-html-i18n-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (192.12.192.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-html-i18n-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19950815163610.I-D@CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-html-i18n-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-html-i18n-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950815163610.I-D@CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
----Next_Part(Thu_Aug_17_08:34:17_1995)----
From: OKI Yukihiro <yoki@beams.nagaokakyo.kyoto.jp>
Real-Date: Wed, 16 Aug 1995 23:16:20 +0900
Subject: [infotalk,05315] Re: Domain name
Message-Id: <199508161416.XAA00258@firework.beams.nagaokakyo.kyoto.jp>
>>>>> "masa" == masayang <masayang@msushi.com> writes:
>> 確かwell.comはwell.sf.ca.usでもあります。ときどき使っている人を見かけ
>> ます。
>>
>>> ドメイン名資源の無駄使いだ。だから、申請手数料は高く設定した方がいい
>>> のだ。
masa> うーん。そういう考えもたしかにありますね。だとしたら、今のJPNICの
masa> 「大口加入のほうが割安」ってのも改めてほしいなぁ。
masa> でも、企業ユーザは安い方に流れると思いますです。
大口加入の方が割安というのはどういう意味ですか？
>>>>> "masa" == masayang <masayang@msushi.com> writes:
masa> 日本に帰ってからも、なんかのドメイン名を取って、自宅にサーバーを置
masa> こうとしていたのですが、JPNICのこういう規則(？)を知ってからは、
masa> msushi.comを継続して使用していこうと決心しました。
これは，自分でドメイン名をJPNICに申請するのが面倒だからということですか？
msushi.comは自分でInterNICに申請したんですか？JPNICからドメイン名取得の
ドキュメントを取り寄せるとわかると思うのですが地域型ドメイン名の取得には
実験ということでお金はかかりませんし，プロバイダに申請代行してもらえば自
分で申請するよりも安くすみますよね。
日本のインターネットプロバイダの価格設定はアメリカのそれに対して高いとい
う事実はいうまでもありませんが，利用者数の違いや通信料金の違い，ルータな
ど通信機器が日本にはいってきた時の値段などを考えるとそれなりに頑張ってい
るんじゃないかなぁと思います。（お寿司屋さんではネタの仕入れ値に日米格差
なんか感じることはないんでしょうか…）
沖 幸弘