２ｃｈからRFC（STD）を作るプロジェクト

インターネット上に何百という数の仮想世界が存在します。
例えばMMORPG（FF11等）の世界も広い意味での仮想世界でしょう。
ところが現在まで、ある仮想世界と別の仮想世界を結びつける
プロトコルは存在していないようです。その為例え同じ種類の
仮想世界（例えばゲーム）であっても別のサーバーの人とは会話も
できず、他の世界と安全に取引することは非常に困難です。
このままでは仮想世界の発展は望めません。
２ｃｈでInternet　Draftを作ってRFC（STD）を目指しましょう。
writer Team2chのRFCがあってもいいと思いませんか？

>>152

＞RURさんの手元にスーパーコンピューター並のサーバーを置いてもらい、そのサーバーが
＞24時間体制で共通仮想空間の機能を世界中に提供してもらうのはどうですか？

　集中管理（スター）型の最大の欠点は、中央がダウンすると、機
能が停止して仕舞う事です。勿論、プライマリとセカンダリを置く
事である程度稼動性能を上げられますが、地域的に分散させないと
意味がありません。ここ（インターネット）がこれだけ普及してい
る最大の理由は、網（ネット）である事です。

>>155
そうなんですか。それでは難しいですね。
ダウンしないような機構は作れませんかね？
上記の情報を知った以上は多分集中管理（スター）型は
没ですが…。地域分散型で実現できる共通仮想空間は
可能なんでしょうか…？

>>156

　例えば、最近のインターネットエクスプローラでは、アドレス欄
にＵＲＬを指定すると外へ、ローカルパスを指定するとファイラに
変化するのをご存知ですね？

　この様に、内部アーキテクチャが別物でも、操作上シームレスに
する事は、可能だと思います。要するに、基本的な機能を実装する
為の約束毎を幾つも作り、それらを組み合わせて複雑な機能を実現
し、それらをユーザインターフェイスでカプセル化するのです。利
用している人は、共通仮想空間にいる様な錯覚に陥ります。

　例え、何処かの仮想空間でトラブルが発生しても、他の仮想空間
への影響が発生しない様な、普遍的なモデリングを確立できれば、
怖いもの無しです。ちょっと話が抽象的？

>>156
いやぁ、実に素晴らしいですな！！
で、どうゆう風に開発が出来ますかね？
その約束事を。あと何で開発できるかですね。
無知で申し訳ないんですが、ユーザインターフェイスとは
視覚的なものの事ですか？もしそうならユーザー毎に
（ユーザー自身の視野のみの）カスタマイズ出来るものがいいですね。

DNS を立ち上げるってのはどうでしょ？
世界で動いてるのとは別の管轄で。
これなら分散も効いてるし、会社ごとに細かく管轄を分けれるし。
root を RUR さんの会社で持てばいいし。

>>158
あと、UI について話すのはあとじゃない？
これは実装者が考えることだし。

スレタイトルと内容がずれてきたような。
ま、こういう話をし終わってから RFC 作ろうよっていいだすのが
本当なんだけどもん。

>>159

　勿論、ＤＮＳの機構は、有力なメカニズムですが、リアルタイム
性に欠ける面があるのです。詰まり、クライアントがプライマリに
指定するＤＮＳに情報が無い場合、そのＤＮＳが更に上位へ問い合
わせる訳ですが、情報を持っている場合に、その情報が最新かどう
かの問題が発生します。

>>158

＞で、どうゆう風に開発が出来ますかね？ その約束事を。

　例えば、>>160 のリアルタイム性の確保ですが、各仮想世界は、
以下の所作を行いましょうと呼び掛けます。

------------------------------------------------------------

・起動時にhttp://www.xxx.com/xへアクセスし、エージェント探索。

　＜アクセス不能なら、前回アクセス分のエージェントを採用＞

・各エージェントへアクセスし、自世界が稼動している旨通知。

　＜定期的に実施し、住民属性（人数、人種、etc.）を添付＞

・任意エージェントへアクセスし、他世界の稼動状況を照会。

　＜必要時に実施し、住民属性（人数、人種、etc.）を受領＞

------------------------------------------------------------

　ここで、住民からの外部への捜索要求がある場合、条件属性から
存在する可能性のある各仮想世界を割り出し、直接クエリを発行す
る事になるでしょう。

　それと、これは、飽く迄、簡単な約束とは、何ぞや？の例として
上げていますので、プロトコルじゃないです。

============================================================

＞あと何で開発できるかですね。

　この場合、言語（ＣとかＣ＋＋とか）に依存していません。

ここ２日ぐらい非常に忙しく、満足に巡回にこれませんが
少しずつ議論が進んでいるようで嬉しいです。
また見に来ます。あと４日ぐらいは忙しそうです。

> IM機能の実装の場合、無料でゲームサーバーに組み込めるなら可能性はあります
> が、メーカーがIMの会社にお金を払わないといけないなら難しいでしょう。

メーカーさんもそうでしょうが、
むしろ（今のところ）MMORPGを作ってフリーで提供しようなどと考えてる
一個人の私なんかはお金を工面出来ないので参入できなくなるのですが・・・

>>126
また例によって全然関係ないこと言ってます。

>>159
私もRFC の製作の以前に、RURさんの言う仮想世界が
漠然としていたものですから、まずやはりUIからかな、と。
DNSは確かにグッドアイディアだと思います。
私の言う「共通仮想空間」に通じますね。割り振ってくれますから。

>>160
その問題がありますね。しかしリアルタイム性の確保はあくまで、
ユーザーの稼動状況を照らし合わせた上で「ユーザーの接続に
現在進行で呼応するようにできる機構」であると私は理解します。
つまり、各ユーザー同士は様々な事に「同期」を取る事は出来ても
真に同次元の世界を体感したことにはならないのです。（まだ続きます↓）

(続き)
この現実世界、つまり３次元空間には万物に平等の時間作用が
働いています。地球上にいるが為に、全世界の時間は時差があり
その結果、同じ地球上にいても全人類が世界の各所で同時に
同時刻を迎える事が出来ません。分かりやすくいうと全人類
同時に朝と夜は迎えられないということです。しかし、それは
地球上の話しで「宇宙空間にある地球」という見方をすれば、
地球に働いてる時間の流れは平等です。その時間の流れは
宇宙空間内であればどの星でも平等です。いわゆる「パルサー」
です。共通仮想空間はまさに宇宙そのものと同様の性質、
つまり各仮想世界に入るまでは、その共通仮想空間内ではどの
ユーザーにも同一の時間的概念の提供をしてみたいんです。
独自に自空間の時間的概念に流動性を持たせる事により、一つの
次元が完成されます。ユーザーはその共通仮想空間に入る事により
、同期と共に「同次元同時進行」がもたらされるんです。
私はこの様なリアルディメンジョン性を持たせたいんです。
例として、日本のA君、アメリカのB君という異なる場所
異なる時間帯から共通仮想空間にアクセスして空間内で出会い、
空間内で同じ時を過ごして行くとします。AとBは現実世界の時差により
長くは一緒にいられません。Aが空間を抜け出し仮想世界へ、
BはAの6時間後に現実世界へ抜け出したとします。
Bが抜け出した2時間後に再度Aは空間に戻り、
更にAが戻った6時間後にBが戻ったとします。共通仮想空間内では、
Aが8時間どこかでかけて戻ってきて、BはAが抜け出した後も
6時間だけ滞在し、そして8時間ぶりに空間に帰ってきて
AとBはめでたく再会といったところです。
二人の会話はおそらくこんなものになると思います。
A「俺さ8時間も＊＊に行っちゃったよ。でさ戻ってきたらBいないし」
(注)＊＊は仮想空間
B「当然だよ。Aが6時間で用事終わるからって待ってたのに。
学校だから一度抜けたよ。」
A「ゴメン。それでいなかったのか。」
B「まぁお互いさまって事で！！あぁもう朝(OR夜)だよ…。」
A「あホントだ。朝だね(OR夜)。なにしよっか？」
てな感じに例えですが、地球上の国、人種を超えた同次元体験の
一例(予測)です。どうでしょうか？
それから言語に依存しないのはいいですね！

これはどうですか？
http://fa.puresilk.ac/idol/
http://fa.puresilk.ac/idol/nozoki.html

>>164
Such content includes, but is
not limited to, web pages and images delivered via HTTP, and streaming
or continuous media delivered via RTSP.
のコンテンツを仮想世界も含むと捉えれば、そのものズバリだと思ったのですが
拡大解釈しすぎでしょうか？

失礼…。(注)＊＊は仮想空間
でなく(注)＊＊は仮想世界、でした。
すみません。

このスレはなんか別の世界に言ってしまった様な気がします。
しばらく静観してます。

なんか話が変な方向へ向かっている気がするのでしばらく傍観します‥‥。

とりあえず、今のところ仮想世界＝MMORPG（UOとかFFオンラインとか）だと思った方が良いと思います。
また、一人の人間が複数の仮想世界に入ることは十分あり得る話なのでその辺はお忘れ無く。

…？HTTPとRTSPの左に付いてるviaとは何ですか？

>>172
難しい単語でも無いし、英和辞典で調べなさい

>>171
一人のプレイヤーが複数の世界で遊んでいても、それは別々のキャラクターだという考え方も有り。

>>174
たしかに。それは世界観とも絡んでくるからここでは決めて
考えないほうがいいと思う。規格を決める上では重要な問題では
ないだろうし。（複数の人を一つにグループ化できれば
それが同一人物であってもなくても扱いは変わらない気がする）

>>164
書く前に、CDIって何か？って調べれば、全然関係ない話だということに気づくだろうに。
コンテンツっつったって、動画とかストリーミングの話だぜ？

>>176
少なくとも現在のCDIの想定する範囲からはかなり離れていることが
わかりました。ご指摘ありがとうございます。

>>173
ｽﾏｿです。調べます。あと「リアルディメンジョン性」
は私の造語です。御理解下さい。

RUR ◆sLgvSGbo さん、私の提案する
各仮想世界に出入りするための
リアルディメンジョン性仮想共通空間について
どう思いますか？お考えを是非お聞かせ下さい。
参照>>152　>>165　>>166

>>179
レス遅くなりました。各仮想世界の独自性を保ちつつ、複数の仮想世界を繋げる
為にはいわゆる仮想共通空間を作ることができれば手っ取り早いでしょう。
しかしながら、現在はまだ仮想世界と仮想世界を繋げるという発想すらほとんどない
段階です。物事には順番がありますから、仮想共通空間の発想は、このプロジェクト等
を通して仮想世界と仮想世界が繋がりうるということが示されれば必然的に出てくる
でしょう。尚実現の際には技術的なことよりも政治的なこと（メーカーの主導権争い）
のほうがネックになるでしょうね。

>>163
サーバ/クライアント的アプローチの場合、
メッセージ、または名前空間を管理する中央集権的方法を取るためになるので
それは仕方がないでしょう。
ドメイン運用にはお金かかってますよね？
サーバ運用だって無料じゃすまないし。

>>180
なにをしたいのかよくわからんのですが。
異る仮想世界を繋げるメリットは？
インターネット上でコミュニケーションを取る方法はいくらでもあるのに
それを仮想空間内で完結するメリットは？

キャラクター名でメッセージをやり取りしたいだけだったら、
会社が相当のメールアドレスでも提供すればいい。

最終的に何をどうしたいってのを明確にしないと
よくわからんまま終りますよ。
あなたはよくわかってないみたいだし、黙ってたほうがよろしいような。

とりあえず議論の行方を見守ります。
ちょっと話がそれてるようだし、未来の話をしても
はじまらない。

>異る仮想世界を繋げるメリットは？
仮想世界で流通する通貨を統一してRM取引代行
↓
取引代行会社ｳﾏｰ

まー、このスレつぶれても別にいいんだけど…、あえて一言。
とりあえず、キャラクター間のメッセージ通信だけに絞っておやりなさい。

ゲーム間の貨幣交換とかいうのはその辺がしっかり確定してからでないと
ものになりません。
（もっともメッセージ交換と貨幣交換は全く別物なので、作ったものが
あとで役立つとは言えませんが。）

せっかくRMの話が出てきたので触れておくと
従来別の仮想世界と直接取引きすることができない為
仮想世界Aの物を一回現金にかえてその現金で仮想世界Bの物を
買う人が出てきました（それほど仮想現実世界間の取引ニーズはある）
そんな非効率的かつ危険な方法をこのまま放置しておくことがいいこと
でしょうか？現に詐欺の被害等もではじめています。
異なる仮想世界が繋がればユーザーも安心して取引できるようになり
仮想世界自体の価値もあがります。
取引代行業者なんかも出てくるでしょうが、取引代行会社がいらないほど
ユーザー同士が簡単に安全に取引できれば理想でしょうね。
その為にもまず会話システムぐらいは繋げたいところです。

４月１日だけ真面目な内容を書くＲＦＣがあったら笑えるか？

>>184
はい　そのとおりだと思います。関係のない妄想未来予想は
未来技術板とかの別のスレッドでやる位でもいいと思います。

>>186
よくわからないんですがエイプリルフールにジョークRFCではない
RFCを出すということでしょうか？まさか日記形式のRFC？

仕様からいくんじゃなくて、なにかサンプル実装をつくって、
それをもとに文書つくっっていったほうがはやいんじゃない？

改良点もあるとおもうけど、ますサンプル実装がないと、
なにを改善すればいいかもわからない

最初の実装は、打ち合わせとかじゃなくて、数人以下でとりあえず
作ってしまい、それからみんなでワイワイやって
改善したほうがはやいんじゃないかな？

>>186
サンプルの例として違う種類のチャットAとチャットBを作って
チャットAの参加者がチャットBの参加者に向けてメッセージが送れる
というような形でもいいのでしょうか？

＞皆様
最初に実装を作るとしたらどんな形がいいか、書き込み
いただけないでしょうか？

age

http://pc.2ch.net/test/read.cgi/prog/1010745628/l50

マイクロソフト、自作自演大失敗！！（ぷっ

1 ：東京kitty ：02/01/11 19:40
http://www.zdnet.co.jp/news/0201/10/e_vote.html

MicrosoftのWebサービス技術.NETと，
競合するJavaについてZDNet/UKが独自に実施した調査で，
突如.NETの人気が高まった。

　12月21日の時点で（2001年12月25日の記事参照），
　この調査の回答者の3分の2以上（69.5％）が
　2002年末までにWebサービス経由でいくつかのアプリケーションを
　社員に提供する計画だとし，
　その大部分（回答者全体の半数近く）は
　Javaを使うつもりだと答えていた。
　.NETを採用するつもりだと答えた人は21.5％で，
　どちらも使う予定がないと答えた23.5％を下回っていた。

　だが1月5日に調査を終えた時には形勢が逆転。
　回答者の4分の3以上が.NETを導入する方に投票していた。
　クリスマスをはさんでの突然の変化は，
　組織的な工作が行われた結果のようだ。
　事実，ZDNet/UKがログを解析したところ，
　不正と思われる投票があったことが分かった。

回答者全体に対し，microsoft.comドメインの人が占めた割合が
大きかった。この調査は1度しか投票できないシステムだったが，
1人で複数回投票しようとした人が多く見受けられた。
最も“熱心”だった人は228回で，microsoft.comドメインのビジターだった。
サブジェクトに「PLEASE STOP AND VOTE FOR .NET!」
（ちょっとお時間を。.NETに票を投じてください）と
書かれた電子メール内のリンクをたどって投票したビジターがいた。
ログ解析で，こうして投票した人が全てmicrosoft.comドメインだった。
スクリプトを使って同じ動作を繰り返す自動投票システムが
使われた痕跡が残っている。

microsoft.comドメインから工作するとは、
ヴァカ炸裂（ぷっ
見事な下逸っぷりだね（嘲笑藁

105 ：仕様書無しさん ：02/01/14 01:52
ああ、間違っている部分があるので修正。

ゲームをしませんか？
.Netの詳しい説明や、面白い話を聞かせてください。
それ以外の話題だとブーイングが入って、
Web上の３つのプログラマ系の掲示板を好む人達にも
このスレの趣旨について確認して貰うというのはどうですか？

ルールを守って1000まで言ったらゲーム終了、ルール違反があると
再び挑戦になります。（藁

マターリとやりましょう！

＞くだらん。死ね
ブー！ブー！ブー！
まずは、ヒッキー板とLinux板、もう一つはどこか適当な場所を選びます。

だから、>>1 は黙ってなさいって。
頓珍漢なんだよ。

>>192
黙っててうまくいきそうだったら喜んで黙っています。
今後の展開に期待してしばらく書き込みを控えます。

sage進行でお願いします。
>>193
だから、黙ってても黙ってなくてもうまくいかないんじゃない？

>>194
ならば勉強した上でもっと積極的にかかわるしかないでしょう。

Title : Forwarding MAC Frames over MAPOS
Author(s) : O. Okamoto, M. Maruyama, T. Sajima
Filename : draft-okamoto-mac-over-mapos-02.txt
Pages : 18
Date : 11-Jan-02

はじめて見つけた日本人が作者と思われるInternet　Draftです。

>>196
黙って勉強してたらどうでしょうかね。
あんまりアフォなことばっかり書いてると
協力してくれる人居なくなるよ。

>>197
様々な分野から人を集めてくる役に集中しようと
思うのですがいかがでしょう？
必要な人がいたら言って下さい。

>>198
様々な分野って、このスレが発散してしまっているのは、無闇に
いろいろなネタを、それがどんなものであるかを調べもせずに
言っているからです。ここでさらに発散させないでください。

メッセージ交換をどういうモデルで行いたいか、をしっかりまず
決めましょう。技術的な話はそれからで、使える既存技術があれば
それを応用すればよい。なければ作ればよい。
まだ他人のRFCを読むような段階ではない。

取りまとめ役はどっしりと！
ちなみにこういう話は、最初たたき台となる案をあらかじめを用意
しておいて、みんなに修正してもらう、という方がスムーズに軌道に
乗りますよ。

>>199
力不足で申し訳ありません。様々な分野というのは
誤解を招く言い方だったようですが、こういう人がいたら
作業がはかどる、こういう人がいないと始まらない、という
要望がスレッドの中で出たときに他のところ（２ｃｈ外も勿論含む）
から連れてくるという意味です。
モデルを私が提示できれば理想なんでしょうが、頓珍漢と言われるのが
怖いのでもっと勉強することにします。
アドバイスありがとうございました。

>>200
とりあえず、IRC と既存の IM 技術が利用出来ないか、
出来ないとすれば何故出来ないかを調べてみては?
その上で、スレタイトルを*適切に*してからまた呼掛けたら違った結果になるかも。

ちなみに、会社が独占してうんぬん、ってのを言ってるけど、
貴方が言ってる意見はなんだか共感しにくいのが多いです。
何故かはよくわからないけど。

最後に。これからは sage で行きましょうや。

>>201
スレタイトルは何が良いでしょうかね？
専門知識が無くても覗く気になって
専門知識がある人には何をやりたいかわかる
そんな名前がいいと思います。

>>202
すげ、もう勉強してきたんですか。

スレタイトルは、「オープンな Instant Messaging の規格を作ろう」
とかでいいんでないの？

それとそれと。
取り引きの方に関してなんだけど、
地域通貨の勉強したら結構面白いんじゃないかなと。
http://www3.plala.or.jp/mig/whats-jp.html

とりあえず、これを Web アプリケーション(って正しい用語か？)あたりで実
装したほうが楽しいような気がしないでもない。

通信技術とは違うけどね。どこが適当なんだろ、こういう話題は。

スレタイトルの意見。
現スレタイトルの「2chからRFCを作る」ってのは、結果的に出来る生成物のことであって、プロジェクトの目的ではないわけです。
目的に沿って「仮想世界を繋ぐプロジェクト」
人目を引くよう少し大袈裟に書いてみると「世界中の仮想世界を繋ぐプロジェクト」あたりが妥当ではないかと。

>>193>>198
プロジェクトが自然消滅すると思います。

>>200
作業をはかどらせるために人を集めると言いますが、適当に集めれば良いものとは思えない。
人を集めるにしても、まずその作業とかいうものの内容が具体的に示された上で、その時に、それに必要な人だけ集めれば良いのでは。

皆様スレタイトルについてのご意見ありがとうございました。

>>203
＞それとそれと。
＞取り引きの方に関してなんだけど、
＞地域通貨の勉強したら結構面白いんじゃないかなと。
＞http://www3.plala.or.jp/mig/whats-jp.html
もともと地域通貨やLETSを含む決済システムが専門の人間です。
こっちの分野まで進出できれば役に立てそうなんですが、それ以前の
単純なメッセージングをクリアしないとどうしようもないので
まずはこちらをクリアできるように考えたいと思います。

>>206
おぉ、専門を持ってる人だったんですね。
地域通貨による取り引きに特化したメッセージ交換システム、を作るべきなのかな。
仮想世界の接続ってのは個人的にはどうかと思うので、
"〜なメッセージ交換システム"的なところで落ち着いたほうがいいと思います。

久々にお邪魔します。極論としてやはり初めはメッセージ交換
をメジャーとした機能を備えたものになってしまうんですかねー。
まぁ、要は異なる仮想世界同士で何らかしらデーターが行き来
出来れば良い訳で。段階としては、
１、メッセージ取引機能作成
２、上記以外のデーター取引機能作成
３、上記２項目の機能提供により発見、提案、議論、して更新グレードアップ
４、細部に渡る互換性、機構の再検査、機構の拡張や強化、グラフィック仕様決定
５、新機能の開発実装

といった具合に誰かが何かを具体的に作ってこのスレッドで議論を
進めてゆけば、必ず形ある機構が出来上がっていくのではないかと
思います。機構の作成者はスレッドの質問者に対し明確な回答を用意できる
技量を求められます。機構を作る際に分からない事は、ここで質問するのも
ありでは？でも自分で調べられることは自分でしましょう。
ここからは何か作って発表し、その機構について議論進めていきましょう。
ここまでで誰も何も作ってませんし。見当違いなものかどうかは、このスレッド
の住人達が判断するでしょう。ではではなにかキボンします。

>>208
プロトコルを作るって話しじゃないんですか？
さんざんいわれてきたことだけど、
外部にメッセージ交換機構を作るっていうだけだったら
ICQ とかの既存のものがありますね。
「UO の某サーバにログインしている hoge さんにメッセージを送信...」
なんてのを実装しようとするのなら、メーカの協力を仰がないと無理です。

グラフィック仕様決定なんてのが草案に入ってるあたり、
焦点がどっかずれてるなーって思うんですが。
機構ってのはなんなんですか？

そんなにクライアントを作りたいなら、
Jabber のクライアントでも作ってやってください。
Jabber は XML でデータを交換する(らしい)ので、取り引きデータのような
構造を持ったデータを送受信するにはちょうどいいかと。

で、その方向でいくなら、板違いかもしれないです。
ムかマ板が適当かな。

>>209
プロトコルを作る話には間違いないですな。
機構とはシステムのことです。
板違いならんよう進めていきたいですね。

>>210
個人的にはもうここは封印していいような気がするんですけどね。
とりあえず sage てきましょう。

久々に来て見たらあがっていたので書き込んでみました。
板の住人の皆様の意見を尊重して今後を決めたいです。
個人的には勉強した上で別タイトルでスレ立てるに一票です。

あぼーん

sage

こういうのはどうよ？(w

Meaning Of Naming Ascii art Protocol (MONA-P)
アスキーアートの名前付けの意味プロトコル (joke rfc)

４月１日に間に合うかな？笑

2chで4/1に間に合うようにJokeなやつ書こう！

ちなみに他力本願です

>>217
ネタは何にするの？MONA-P？

　時間のある時に、SOAPを勉強して置いて下さい。

　実装が多少難しいですが、拡張性の点で、ピカ一です。

　通訳や取引迄を考えるなら、有力候補になると思います。

　補足すると、SOAP（シンプルオブジェクトアクセスプロトコル）
は、XML（エクステンシブルマークアップランゲージ）を用いてRPC
（リモートプロシジャコール）を実現する為の規格。

　悪名高きマイクロソフトのオブジェクトを、広く一般からも利用
して貰える様に再構成してあるので、Java等とも親和性が高く、色
んな可能性を秘めています。

　この規格に基いて幾つかの必須メソッドと拡張メソッドを規定し
て、>>161 を組み合わせれば、何とかなると思います。

>>221
SOAP はこの場合下の方のレイヤーで使われる問題なんで。
なんでそうすぐ実装に走ろうとするかな。

しかもなんで今更。

>>222

　これは、重要な問題です。

　ここを踏み誤ると、全然違う結果をもたらす事になります。

　今後の話題を何処に置くかが、これで決まります。

　意味をご理解頂けないのは、多分、>>222 さんが、予め用意され
ている教科書や問題集で知識を積んで居られるせいだと思います。
実務をなされば、きっとこの意味がお分かりいただけるでしょう。

　この点でスレッド主は、１年でも実務を経験しているので、きっ
と、ご理解頂けると思います。

>>223
ドーイ

Cye はｶﾝﾁｶﾞｲなんで黙ってたほうが賢く見えるよ。

････････････････！(・A・)！

>>225
アノニ厨房はﾋｯｷｰの証！
でビビリヲタ君！
でインポで候ろう！(・A・)
でワキガ苦作、デブで臭作！
が世の常…駄。
そのコテハンからして宗教ヲタ中毒者っぽくてｷﾓｰｲ

>>227
オマエモキモイ

あげよう。

たまには見てるという証拠に足跡つけておきます。

今年はどんなＪｏｋｅＲＦＣが作られるのだろうか。

IEEEはできたもよう。

http://www.watch.impress.co.jp/pc/docs/2002/0401/uocchi/802.htm
IEEEEE、ワイヤレス電源規格「802.110v」を制定

>>231
JANOGで誰かが流してた

http://www.netarc.jp/doc/april-fool-rfcs.html

>>233
関係ないけど、昨年度１年でRFCが2000個増えたのかな。

やはりMPLSネタというかMPLampSと来ましたか！（笑）という感じです。
用語解説がめちゃくちゃで笑えました。
ISISなんて、“It's not oSpf, yet It somehow Survives” ですから。

もう一方はまだ目を通していないんですが。

とりあえずパールのソケット間通信クライアント。サーバーサイドは知らん
#tcp-client
( $them, $port ) = @ARGV;
$port = 2345 unless $port;
$them = 'localhost' unless $them;
$AF_INET = 2;
$SOCK_STREAM = 1;
$SIG{'INT'} = 'dokill';
sub dokill {
kill 9,$child if $child;
}
$sockaddr = 'S n a4 x8';
#chop($hostname = `変換`);
($name,$aliases,$proto) = getprotobyname('tcp');
($name,$aliases,$port) = getservbyname($port,'tcp')
unless $port =~ /^\d+$/;;
($name,$aliases,$type,$len,$thisaddr) = gethostbyname($hostname);
($name,$aliases,$type,$len,$thataddr) = gethostbyname($them);
###IPを構造体からアドレスにする
@thisaddr = $thisaddr ; @thataddr = $thataddr ;
foreach (@thisaddr) {
@localip = unpack ('C4' , $_ );
print "localaddr = $localip[0] .$localip[1] .$localip[2] .$localip[3]\n";
}
foreach (@thataddr) {
@remoteip = unpack ('C4' , $_ );
print "$them = $remoteip[0] .$remoteip[1] .$remoteip[2] .$remoteip[3]\n";
}
$this = pack($sockaddr, $AF_INET, 0, $thisaddr);
$that = pack($sockaddr, $AF_INET, $port, $thataddr);
if (socket(S, $AF_INET, $SOCK_STREAM, $proto)) {
print "socket ok\n";
}
else {
die $!;
}
if (bind(S, $this)) {
print "bind local :ok\n";
}
else {
die $!;
}
if (connect(S,$that)) {
print "connect $them :ok\n";
}
else {
die $!;
}

>>236
で、それがなにか…
張り間違いか？

ランダムで飛んできますた。
どうなってるのでしょう？

あぼーん

オープンなインスタントメッセージ？
すでに、IETFでは、SIMPLE、PRIM、IMPPとオープンなインスタントメッセージを
つくるためのWGがありますよ？
新しいWGでもつくるつもり？

Jabberもありますな。
しかしJabberのひといじめられててかわいそうだった。。。

とりあえず>>1からだいたい読んでみた。>>1がやろうとしてるのは
TCP/IP Stack over TCP/IP Stackでもやってpseudo stackの
インフラをPhysical App Layerに設けようということでつか？

それとも仮想世界の規格を創ることでつか？それなら・・・

とりあえず>>1は、
「他の仮想世界の人とメッセージをやり取りしたい！！」ということにテーマを絞って
>>1は>>8に対する>>14からやり直す！
まずは仮想世界を定義しる！といってもデカすぎるからとりあえず
仮想世界の中の人を定義しる！あんまインテリジェントな人にしないで
「他の仮想世界の人とメッセージをやり取りしたい！！」というテーマに絞って
定義しる！何を持ってて何ができるのが人かが分かればそれで(･∀･)ｲｲ!!
ちゃんと考えられていなくても良い。角度とか。

考えられていなくても　→　計算されていなくても

この世界のこの人とあの世界のあの人が同一人物である、と
いうような情報は簡単に出回ってはいけない。
ネットストーカーの問題とか、どのサーバからクレジット番号
が漏れるかわからないとか、いろいろと危険な状況になる。
だから個人間の連絡方法としては、いわゆる転送電話方式で、
1.世界AのZさんが世界BのYさんに電話をかける
2.世界BのYさんがいなかった→世界Cにいる世界BのYさんに転送
（世界CにおけるYさんの名前￥とかは隠蔽）
3.そこが世界Cであることを会話中に知る。
4.（そういえば世界CのXがほにゃららを欲しがってたなぁ……）
5.Yさんに聞く→(ﾟдﾟ)ｳﾏｰ
重要なのは世界CにおけるYさんの同一人物の名前ではなく、
世界BのYさんが世界Cにつてを持っていた、ということ。
連絡を取る相手はあくまで世界BのYさん。

続き。

サーバとユーザの名前空間はDNS方式でよいと思います。
さて、ゲームサーバに対しても他のユーザに対してもエイリアス
を隠蔽しつつどうやって相手を捜索するか。

　ユーザYはゲームサーバBに別名リストのサーバ名部分だけ伝え
　ておく。
　ゆえに転送が発生するサーバBはどことどこのサーバに送れば
　いいかだけ知っている。
　転送側サーバBはあて先のユーザYの公開鍵で暗号化。あて先
　ユーザ名は破棄。
　受信側サーバC,D,…は受け取った通信ををそのとき接続していた
　全ユーザにブロードキャスト。
　本人だけが内容を解読して完了。

返事はどうしましょう。Cの￥がAのZに返事を書いていることが
（もちろんZに対しては隠蔽するけど）サーバCに知られるのも
どうかと思います。

とりあえず、RFCの称号がほしいだけなら
なんで、2chの通信仕様をRFC化しようとしないの
独自の方式を使ってて、いくつものインプリメント
があって、ユーザが数十万人もいるなんて
もうばっちりじゃないですか。

>>247
2chって、どっかで独自の方式を使ってたか？

あ

（＾＾）

winnyのプロトコルをinformational RFCにすることは可能

問題はwinnyってプロトコル非公開の信用できないものなんだろ？

2chから四月ばかの規約は提案しなかったのか、、、、

あぼーん

本日の RFC3514 実装しますた
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c