TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
マルチキャスト
IPv6 実現したら、何をつなぎたい？
【IP携帯】WiMAXって知ってる？【次世代通信】
BIND8.2.2 for Win32 論争
【無線LAN】OpenWrt【強化ファーム】16
１００Baseの読み方
■緊急■ネットワークスペシャリストは役に立つの？
DNSの参照
56kモデムをもっと速く！
都内マル秘ホットスポット情報

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


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

2 ：
私は主にネットワークゲームの決済システムを研究している者です。
RFCの為特許出願中の技術も含め、積極的に提供していきますので
なにとぞ２ｃｈの皆様のお力添えを頂きたくお願い申し上げます。

3 ：
手伝いたいと思いますが何ができるんでしょうか？
私は普通のネッターですから何ができるのやら。

4 ：
RFCってなんですか

5 ：
>>3
こういうことが出来たらいいなという意見を出していただければ
ありがたいです。今まで独立した存在だった仮想世界が結びつくと
どんなことが可能になるでしょう、あるいはどんなデメリットが
出てくるでしょう。想像してみてください。
>>4
IETF（The InternetEngineering Task Force）が発行する
インターネットの技術や仕様に関する文書です。
中でもSTD(STANDARD)はインターネットの正式な規格であり、
そのルールに基づいてインターネットの世界が成り立っているのです。

6 ：
SOCK_ADDRでせいいっぱいなんだけど

7 ：
http://rfc-jp.nic.ad.jp/introduction/Std-track.html
RFCがSTDになるまでの過程は上のリンクを参考にしてください。
>>3
追加です。提出されるRFCは英語でなければなりません。そこで
仕様を英語に直す作業やそのチェック等にも人手が必要です。

8 ：
>>5
とりあえず仮想世界をオブジェクト化することから始まるのかな？

9 ：
>>6
具体的な検討はInternet Draftになってからでもできると思います。
RFCになるレベルのInternet　Draftを作成することがまず最低限
必要なことです。RFCになった後は世界から技術者の参加も期待でき
ますので、自分（達）ができること以外は余り考えなくても良いでしょう。

10 ：
>>9
ここでの目標は draft-*-01 ではなくて、あくまでRFCってことですね。

11 ：
じゃぁWinMX++みたいのが生まれたらどうするのですか？
なんか対策とか考えないと

12 ：
>>10
ま、それは進行していくうちに見えてくるだろうということで。
取りまとめ役はRURさんだと思いますが、騙り防止のためトリップは
つけたほうがいいかもしれません。

13 ：
>>11
勝手に想像しているイメージは、仮想世界をモデル化して
相互接続可能にするようなイメージなんだけど、それだと
ファイル交換は関係なさそう。

14 ：
>>8
そうですね。まず仮想世界間でどのようなデータがやり取りされるか
を考えてみましょう。一つの仮想世界を国と考えるとわかりやすいと
思います。まず電話を引いて他の国と話せるようにしたほうがいいで
しょう。貿易も行われるかもしれません。決済の為の外為銀行も
必要でしょう。ビザを発行し相手国が認めれば入国できるように
することも可能かもしれません。
他にも気がついたことがあったらどんどん書き込んでください。

15 ：
トリップつけますね

16 ：
>>10
最終目標はRFC（STD）ですが、まずRFCにして、その後は
現在の状況を報告したり、いい提案（日本語）を英語化して
フィードバックするといった形になると考えています。
RFCにするまでにInternet　Draftを日本語で作成し、それを英語化
する作業が必要ですね。

17 ：
話の範囲が漠然としすぎている。
仮想空間の転送プロトコルなら提案はいくつかある。

18 ：
>>17
オンラインゲーム以外の仮想世界・仮想空間に応用可能な
転送プロトコルと考えています。どこまでをこのスレッドで
扱うことができるかは、ここにどの位の人が集まるのかにも
よりますので、最初から制限をかけることはしませんでした。
是非提案をお聞かせください。

19 ：
２つの仮想空間を結びつけるっつうのは、
phi のゲートみたいなもん？
それか UO のサーバー境界みたいな感じ？
とりあえずスレタイトルが間違ってるかと。

20 ：
Visual Studio.Netが一つの方向を打ち出していると思うのですが．．．
C#などの開発ツールもこれから充実して来るのでは？

21 ：
前にベンチャー板だか経営学板で似たようなことをやってる人がいたな。
簡単に言えば異なるネットゲーム間で金銭をやりとりする為替市場のシステムを作ろうってこと。
自分で稼いだ金を持ち込むこともできるし、異なるゲームの参加者と
交換レートに従って互いの金をやりとりすることも可能。
興味深かったんで途中まで見てたんだけど、今はどうなってるんだろ。
ちょっと見てきてみようかな。

22 ：
>>19
２つのサーバーというより可能ならば全てのサーバーを結びつける
ということです。LANではなくInternet　or　The Internetの
発想です。スレタイトルはどうすべきだったでしょうか？
>>20
RFC化すればVisualStudio.Netもそれに沿った形で協力してくれる
可能性があります。RFCの目的の一つはインターネットの世界で
幅広いコンセンサスを構築することです。
>>21
ベンチャー板ですね。何故知っているかといえばそれは
私の会社だからです。ネットワークゲームの決済に関して
一定の成果とノウハウを蓄積した結果、それを拡張する
プロトコルをアメリカとかの大手企業に作らせるのではなく
インターネット技術らしく、RFCで標準化するべきと考えました。
いきなり身元ばれてしまうとはさすが２ｃｈ。

23 ：
難しいので初心者にわかるように説明してクレと言われたので
少し補足します。
＞つまりネトゲ（ゲームに限らずかもしれんが）同士に互換性を持たせるための標準規格を
＞作ろうって事か。で、それがIFTFとやらに認められれば
＞一般に使われるようになるのね？
＞
＞ド素人的理解としてはこんな感じでいいんでしょうか。
ってことです。

24 ：
＞素朴な疑問として、規格というとえらい人達が集まって作るようなイメージがあるけど、
＞そんなものを本当に２ちゃんねるで作れるのか？
＞それと、仮に出来たとしてみんながそれに従うようになるものなのか？
＞
＞2chの名無し達が作った規格がグローバルスタンダードになるとしたら、確かに面白いんだけどさ。
という質問に対する回答をコピペします。
RFCは広く公開されており、望めば誰でも入手可能です。
そしてインターネットの標準化に関する議論にも
誰もが参加できるのです。
このことから、 RFCはインターネットという広い世界でオープンな
議論をするための仕組みとしても利用されているといえます。
勿論世界でもトップクラスの技術者達がこの仕組みに参加しています。
考え方としては２ｃｈに近いと思いますよ。

25 ：
>>22
おお、成功したんですか。
良かった良かった。
まだあのスレ残ってる？
あと、良かったらあなたの会社のＨＰのURL教えてｸﾀﾞｻｲ。
途中からあのスレは見なくなってしまったけど、個人的には結構印象に残ってるもんで。

26 ：
>>25
過去ログはこちらです。今でも会社のトップから記念にリンク
貼ってあります（笑）
http://yasai.2ch.sc/venture/kako/985/985074870.html
会社のページはこちらです。
http://www.real-unreal.com
一年近く前のことを覚えてくれている人がいるとは嬉しいですね。

27 ：
インターネットでサーバーごとにサーバー管理者がいるように
仮想世界ごとに仮想世界の管理者がいます。サーバーのポート設定を
いじるようなイメージで機能ごとにその機能を利用できるか管理者が
設定できるようにする必要があると思います。また特定のIPからのアクセス
をはじくように、特定の仮想世界からのアクセスを制限する仕組みも
当然考慮に入れるべきでしょう。現在のインターネットプロトコルを
仮想世界に拡張するというイメージでプロトコルを考えるのが近道だと
思います。

28 ：
>>27
んーレイヤ３なんですか？
てっきり基本は over IP かと思っていたので。

29 ：
>>28
通常仮想世界のユーザーと仮想世界のサーバーはTCP/IPかUDPで繋がっています。
ここで問題なのは仮想世界と仮想世界のサーバーをどう繋ぐかですが基本は
TCP/IPでしょう。サーバーまで正確にデータが届けば、そこから先は届かなくても
問題が生じることは少ないでしょうから。
ATMの銀行間ネットワークに近いでしょうね。
つまり銀行まで正しいデータが届けばいいと考えています。
上で言ったことは擬似的に実現できれば良く、いわば管理者の
使い勝手の問題です。擬似的に実現できるかどうかは検討課題
でしょう。

30 ：
やっぱり、漠然としすぎてる。
何がやりたいのかよくわからない。
実装を作らないと、RFCにならない。
２ちゃんねらーが協力して、どういうメリットがあるのかも分からない。

31 ：
>>30
現在の議論ではいきなりRFC（STD）を目指そうというものではありません。
実装を作らないとRFCにならない、という表現は適切ではありません。
現在はInternet　Dragt若しくはRFC（PS）標準への提唱段階を念頭に置いています。
上でもあげたインターネット標準化過程
http://rfc-jp.nic.ad.jp/introduction/Std-track.html
によればPS段階の仕様として要求されることは
安定していること
設計上の方針が確定していること
よく理解されていると考えられること
インターネットコミュニティにおいて十分に検討されていること
インターネットコミュニティにおいて価値があるとみなされ興味を持たれていること
です。まずはこの段階を目指したいと考えています。

32 ：
具体的な仕様や実装を考える際にはInternet　Draftに対する
意見や提案を反映する必要があるでしょう。
この段階では仕様の実装や運用実験は必須ではないとあります。
２ちゃんねらーが協力してどういうメリットがあるのか？ですが
一つはTeam2ch著のRFCができたらそれだけで大ニュースではないか
ということ。そして２ｃｈでの議論自体が日本語とはいえ
インターネットコミュニティにおいて十分に検討されていること
インターネットコミュニティにおいて価値があるとみなされ興味を
持たれていること、というPS段階での条件を補完する意味がある
と考えられます。その為たとえスキルのない人でも興味を持って
書き込みしていただければその人もこのプロジェクトの遂行に
貢献したことになると考えられます。
このようなことができるのは少なくとも日本ではここ
２ｃｈだけです。

33 ：
タイトル見たときは2chでjoke RFCでも出すんかいと
思ったけど、ネタじゃなかったのね。
まず、どういうものを作りたいかまだはっきりしていない時点で
RFC とか言ってるのがわけわからん。
RFC の目的を勘違いしていないか?
> 安定していること
> 設計上の方針が確定していること
> よく理解されていると考えられること
> インターネットコミュニティにおいて十分に検討されていること
> インターネットコミュニティにおいて価値があるとみなされ興味を持たれていること
事実上これらを実現するためには
ある程度ちゃんとした実装が必須だと思われ。

34 ：
RFC リストに載せたいから RFC を作るってのは、東大に入りたいから
東大を目指すってのと同じレベル。あと「仮想世界を繋ぐプロトコル」って
それだけでは抽象的過ぎる。(歯に衣着せずに言えば、リアル厨房っぽい。)
まあ、その辺をさっぴいっても面白い話だとは思うから、真面目にやるん
なら協力するけど。でも、何をやりたいのかもっと明確にしないと駄目
だとは思う。分散オブジェクト間の通信プロトコル？ MUD や MOO 空間を
繋ぐためのプロトコル？ 前者なら CORBA 等、後者なら VRML2 等について
ちゃんとサーベイして、概念を整理してから発案した方がよいと思われ。

35 ：
2chでjoke　RFCも非常に面白いと思います。今ならエイプリルフールに
提出できるかもしれませんね。それは別スレッドに期待するとして（笑）
Internet　DraftのIndividual Submissionsを読んでいてもかなり
完成度の高い文章が出ていますね。ましてやIETF working groupの
推奨を受けるといったことを考えると、ある程度ちゃんとした実装を考える
必要があるでしょう。私の技術力でどこまでちゃんとした実装を考える
ことができるかはかなり不安ですが、良い経験だと思うのでできるだけ
やってみます。

36 ：
>>34
アドバイスありがとうございます。とりあえず英語の勉強だと思って
関連するRFCやIETFのメーリングリストの投稿を読みまくることに
します。

37 ：
>>34
ちなみに私が貢献出来そうなのは前者のほうです。
後者についてはその分野に詳しい神様が降臨なさった時に
検討を開始するという方針でもよろしいでしょうか？

38 ：
>>34
＞　MUD や MOO 空間を繋ぐためのプロトコル？
ただ、「つなぐ」っていわれても、よくわからん。
つなぎいで、何の情報を流すのかわからないから。

39 ：
あなたは、会社にメリットがあるかもしれないけど、
2chにどんなメリットがあるの？

40 ：
>>32
＞たとえスキルのない人でも興味を持って書き込みしていただければ
＞その人もこのプロジェクトの遂行に貢献したことになると考えられます。
だけど、クレジット載らないんじゃあなぁ…

41 ：
>>39
成功すれば2chで標準化の議論が可能であることを証明することが出来る為
他の分野でもコミュニティの合意を形成する際に２ｃｈが有効活用される
ようになるでしょう。成功すれば他の２ｃｈ発のプロジェクト推進者の
参考となるでしょう。２ｃｈの良いイメージが外国のインターネット技術者
の間に広がるでしょう。反対に失敗してもデメリットはありません。
>>40
クレジットはTeam2chで個人名等は出さないほうが良いと思いましたが、
トリップをつけて投稿してもらってInternet　Draft提出の際に希望者は
クレジットに載せることができるようにすることも可能ですね。
私的なプロジェクトだと思われたくないので私は遠慮しますが。

42 ：
要はUOで言うところの別シャードの人とも安全に取り引きできたりなんかする
なんらかの規格、しかもUOにとどまらず他のゲームも同じく利用可能な
”何か”があれば、ってことなんですよね？（ちょっと狭義すぎるかな）
具体的な像が浮かび上がりませんが、ユーザー視点のイメージ的には
数多くある仮想世界にログインする前に共通のロビーのようなものがあって
そこでトレード出来るようになれば、って感じはどうでしょう。
サーバー間通信にロビーを中継するかどうかの違いだと思うので
仕様的には全く意見になっていないかもしれませんが
＞こういうことが出来たらいいなという意見を出していただければ
とあったので。というか本当にそんなのあったらいいなぁ‥‥。

43 ：
>>42
具体例としてはその通りです。本当にそんなのあったら良いなあという
意見はイベント企画板でも頂いたので、
> インターネットコミュニティにおいて価値があるとみなされ興味を持たれていること
はクリアできそうな気がします。
ロビーサーバーは各社が鎬を削っているのでなかなか統一規格は難しいでしょう。
しかしRFCができれば各社乗り遅れないようについてくると思います。
取引の手順については考えていることがありますので明日にでも
書き込みます。そろそろ具体例を出すべき時でしょうし。

44 ：
STDってビョーキの事かとｵﾓﾀﾖ

45 ：
英語板から着ました。面白そうなので参加させてください。
あまり技術的な事は分からないのですが、翻訳なら手伝います。
なにか読むべき（翻訳すべき）ＲＦＣがあればリンク下さい。

46 ：
>>42-43
結局、そういうことなのね。ちゃんとそういうこと書いてよ。
「仮想空間をつなぐ」って言っても、意味が広すぎる。
RUR氏は思いつかないのかもしれないが、
「つなぐ」と一口で言っても、いろいろな形態がありうる。
じゃあ、あとはみなさん頑張ってください。

47 ：
>>45
参加していただきありがとうございます。
まずはRFCって何ってことを知っておいて損はないと思うので
日本語ですが
http://pcweb.mycom.co.jp/career/ityougo/2001/012.html
をオススメします。余裕があればそこからリンクされているRFC
をいくつか実際に読んでみてください。特にRFC2555はRFCの
30年の歴史をまとめたもので読んで損はないと思います。
読んでみた感想を教えてください。（このレベルだと楽勝とか、
専門用語が多くてかなりてこずりそうとか）
更に余裕があればIETFのページ　http://www.ietf.org/
で作成中のInternet　Draftや標準化過程の最中のRFCのレベルを見てください。
文章がどのレベルに達すればいいのかということが大体つかめれば
現段階では十分です。技術がレベルに達しているか判断することは
この板の住人やその他の参加者も出来ますが、文章（英語）がどのレベル
に達すれば良いかはその他の参加者では判断できないでしょう。
その視点からまだまだダメだとハッパをかけてもらえれば
ありがたいです。

48 ：
>>47
４５です。
ざ〜っと読んでみましたが、英語→日本語　は大丈夫です。
Internet Draft も読みましたが、ドラフトと言うだけあって、
書き方は皆様々ですね〜。
皆がどのような書き方をしているのか、ここに書こうと
思ったのですが、余りにもみんな書き方が違うので、
時間があるときにやります。
とりあえず、Instructions to Authors　と言うＲＦＣを
見つけたので、これから日本語に翻訳してみます。

49 ：
>>45
はい、そのRFCの存在は知っています。
どこかで日本語訳がある場合もありますので探してみても
良いと思います。もし新しく翻訳した場合、どこかにアップして
RFC日本語訳リンクサイトからリンクを貼ってもらえれば
それだけでも日本のネットコミュニティに大きな貢献を
したことになると思います。ただ既に日本語訳がネット上にある
場合、2度手間になってしまうと思います。

50 ：
>>48
そのへんはRFCでも同じなので書きやすい形式でいいと思います。
構成は大体似たような感じになると思いますが、文書を複数に分けるか
１つでまとまるかは、実際にどの規模の取り決めになるのかが見えて
から考えればよいでしょう。
現状はあまりに抽象的過ぎて、とてもdraftをどうこう以前のレベルなので
書き方はそんなに急がなくてもいいでしょう。

51 ：
>>49 >>50
う〜ん、とりあえず俺の出番はまだないのかな？
「このＲＦＣを訳して欲しい」とかありませんか？

52 ：
ttp://www.minokasago.org/Linux/RFC/
ここにＲＦＣの日本語訳がありました。
とりあえず暇なので、伝書鳩のジョークＲＦＣでも読んでます。
役に立てそうな時が来たら、呼んでください（定期的に見に来ます）

53 ：
＞お手伝いさん
それではActive IETF Working Groupsの各ワーキンググループの
説明を読んで、関係がありそうなワーキンググループをリストアップ
していただければ助かります。

54 ：
　仮に、仮想貨幣の流通に的を絞る場合、交換を当事者間で行うの
か、取引所（仲介業者？）を通して行うのか、迷ってしまう。
　基本的に、通信パケットの構成や、ネゴシエーションを規定する
前に、周辺を固める必要があるかも。
　前出のロビーは、利用する側からのアプローチだと思うが、提供
する側同士の連携や、参加者のモラルもテーマになりそう。
　例えば、ＳＭＴＰの場合、その名が示す通り、メッセージを簡便
に転送する約束な訳だが、この様な地道なプロトコルを幾つも創出
して、これ等を組み立てる事になると思う。
　現段階では、やろうとしている事だけは、おぼろげながらも伺え
るけど、やらなければならない事が多過ぎる気がする。分科会が必
要になるかも。

55 ：
>>48
RFC2223 Instructions to Authorsの日本語訳はこちらですね。
スレッドの皆様の為にもアドレス貼っておきます。
http://www.minokasago.org/Linux/RFC/text/rfc2223-jp.txt

56 ：
>>54
その通りですね。周辺を固める際には私の今までやってきた
経験や人脈も生かせると思います。似たようなことを既に自社独自で
やろうとしている日本でいえばドワンゴやマルチタームといった会社と
連携してプロジェクトを進めることも可能でしょう。
その場合少なくともそれらの会社名はクレジットにのっける必要が
ありますが、問題ないですよね？
もう少し人数が集まれば分科会を作るとして現状ではまだまだ
人数が少ないので全体の方針を全体で決めていきましょう。
最低でも簡単なメッセージを送信するプロトコルは作りたいですし
作るべきだと思います。

57 ：
イベント板でこのような提案がありました。
どう思われますか？
まずはＵＤの存在を宣伝してみたらどうかな
ある程度パブリックな掲示板とかに書き込んだりして
もちろん２ｃｈ名は伏せてな

58 ：
IP over Fibre Channel こんなのは役に立ちますか？
ファイバーチャネル・トポロジーにＩＰとＡＲＰを利用する。と
言う物です。
高速にどのサーバにもアクセスできる。と言うプロトコルを
標準化しよう！というグループみたいです。
今回、どのような分野が役に立つのか良く俺には分からなんですが、
「どのサーバにもアクセス出来る」と言うのを探していけば
いいんでしょうか？

59 ：
>>58
すげーこといってるな．
Fibre Channelって何か知ってる？

60 ：
>>58
当然それも関係あると思います。まだ具体的なDraftを作る以前の
段階ですので、関係がありそうな分科会をいくつもピックアップしておいて
Draftが半分くらい出来てきた段階でどの分科会に推奨してもらうのが
いいか等を検討すればいいのではないでしょうか。
>>50で文書を複数に分けることになるかもしれないと書かれていましたが
そうなった場合、それぞれの文書を違う分科会が取り扱う可能性が高いです。
基本的に違うサーバーやオブジェクトを結びつけるプロトコルは全て
関連があるともいえますが、ここらへんが漠然としすぎていると
いわれる所以でしょう。プロジェクトで扱う範囲を、ここの分科会で
扱われる範囲と決めてしまうというアプローチも可能かもしれません。

61 ：
>>60
＞当然それも関係あると思います。
あるのー？
だいたい、基本的には、研究開発をやって論文や製品として発表して、
その成果がいいものだったら、それをRFCにしようとするんであって、
最初からRFCの書き方とか英語とか、最後のところを先走って心配しても
なんだか、本末転倒のような気がするんだけど？
まあ、頑張ってくれとしか言いようがないよな。

62 ：
>>59
Fibre Channel って光ファイバーケーブルのことですよね？
この位なら俺でも分かります・・・

63 ：
>>59
クラス２でファブリック・トポロジーやHUBによるループ接続で
世界と世界をつなぐというのも可能性としてはあると思ったのですが
見当違いのことを言っていたら申し訳ありません。

64 ：
アイデアの提出の時点では、これなんかが合っていると思います。
プロトコルが形になる前に「○○を実現させる為の必要条件」とか
色々、違う形で一度発表して見るのも良いと思います。
User Connectivity
（説明）
User Connectivity ワーキンググループは、どのようにして
ネットワークユーザの端末間接続性問題を解決するか、を研究します。
（RFC)
RFC1297 NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist (``NOC TT REQUIREMENTS'') (Informational)

65 ：
>>64
ありがとうございます。最終的にはユーザーとユーザーを繋げる
訳ですからここでも良さそうですね。

66 ：
　ところで、トリップを変える予定ありませんか？

67 ：
う　確かにバレバレ＾＾
上でRFC＋番号のトリップあったけど格好いいなあ。

68 ：
　条件が、RFC[0-9][0-9][0-9][0-9] だと、比較的容易に見つかる
様です。
http://cheese.2ch.sc/test/read.cgi/qa/1010070777/

69 ：
>>63
これってアプリケーション層の話ですよね…

70 ：
>>69
　勿論、要となる部分の大半は、アプリケーション層（セッション
層、プレゼンテーション層、アプリケーション層）です。
　けれども、このプロトコルが具現化すると、その適用分野は、非
常に広範囲に及び、場合によっては、基軸通貨の取引をも巻き込む
可能性があります。その場合、途轍もない情報量を扱う事になり、
その拠り所となる高速ハイウェイをより堅牢で安全なものとする為
の約定も必要にあるでしょう。
　無論、この段階迄来ると、最早、２ちゃんの手に負える領域を逸
脱しています。

71 ：
>>69
なるほど、根本から間違ってたっぽいですね。
まずこのプロジェクトでOSI参照モデルでいうどの層までを
扱えばどの問題が解決できるかということを考えてみて
簡単に扱えそうな問題をまず一個解決することを目指しましょう。
個人的には単純なテキストメッセージを別のサーバー（世界）と
やり取りするプロトコルが一番簡単そうに思えます。
（メーカーの政治的思惑を考えない場合）

72 ：
>>70
この段階になれば世界中の技術者や研究機関がかかわってくれますから
我々はできることを一つ一つやるしかないと思います。
深く入り込めば入り込むほどできることも増えますが、その分作業は
困難になるでしょう。勿論今の段階でも可能性を示すことは出来ますから
可能性を示すことにより、RFC（PS）段階で求められている
インターネットコミュニティにおいて価値があるとみなされ興味を持たれていること
という条件を満たすことができれば良いのではないでしょうか。

73 ：
>>68
３分くらいでした(w

74 ：
>>71
　それと、既存のインターネット技術をどう組み込むかです。例え
ば、取引内容の信頼性を保証する為の認証ですが、現状の個人認証
を行う場合、高額な年会費と手続きの複雑さがネックとなる訳です
が、仮想世界がサイト認証を受け、仮想世界へのログオンで個人の
財産が裏付けされるのですから、比較的リーズナブルに利用出来そ
うです。

75 ：
>>74
はい、仮想世界自体を認証しなければならない
可能性は極めて高いですね。一つの仮想世界のセキュリティが
破られた際にその仮想世界が崩壊することは仕方が無いのですが
全体のネットワークが崩壊するようなことはあってはなりません。
その為一つの世界が崩壊しても他への影響が最小限になるシステムが
必要ですが、その設計に当たっては既存のプロトコルのノウハウが
存分に生かせるのではないかと思います。
反対に仮想世界自体が認証できれば
個人の認証は仮想世界を利用する段階で済んでいるので
比較的楽でしょうね。

76 ：
他の仮想世界にいるプレイヤーにメッセージを送る場合
まずAさんがどこの世界にいるのか？あるいはどこの世界にもいないのか
を探さないといけません。一人が複数の世界にいる可能性も０ではありません。
まずメッセージを届ける相手がどこにいるのか？いないのか？それとも複数世界に
いる為に相手を特定できずメッセージが送れない状態なのか等を判断しなければ
ならないでしょう。これが面倒だとすると、仮想世界にログイン後にその世界内から
自分はここの世界にいますよ、と発信する仕組みと、今誰がどこの世界にいるという情報を
保存してその情報を交換する仕組みが必要になってしまいますね。
他にはいてもいなくてもどこどこの誰それにメッセージを送りたいと
仮想世界のサーバーに許可を求めてメッセージを送るという形式も考えられますが、
どこの世界にいてもメッセージを受け取れるのが理想なのではないかと思います。

77 ：
こんちぁ。仮想世界（MMORPG）を作ろうなどと無謀なことをしつつある一人です。
しばらく見守って、良さげなら微力ながら協力しませう。
実験的にも実装できそうな程度にはまとまってきたら、組み込んでみよう。

78 ：
>>76
簡単に言えばICQやMSNメッセに仮想の位置情報（どの世界にいるか）
をつけるようなイメージですかね？
逆に、どこかのサーバーに入った時点で、システム側でログイン情報を
一元管理するという方法もあるけど、どっちがいいのかな？
システム側で一元管理だと感覚的に嫌う人はいそう。
逆にクライアント側に任せると「本当にいないのか」ってことは
確かめられなくなりそうですね。

79 ：
>>77
こんばんは。２ｃｈでもMMORPGを作ろうスレなんてありましたからね。
しばらく見守っててください＾＾よろしくです。

80 ：
>>78
ＩＲＣがそのへん上手いことやってたような気が・・・。
よく読んでないから知らんけど。

81 ：
>>78
その通りですね。一元管理すると仮想世界の運営会社がこいつはこっちの
世界に行ってるのかとか追跡調査できてしまいますよね。
仮想世界間でプレイヤーの取り合いを助長してしまい、ただでさえ
利害が対立している会社同士の仲が悪くなる可能性がありますね。

82 ：
>>80
IRCはそう考えてみるとうまくやっていそうですね。
おっしゃっているのはチャンネルの重複を防ぐ仕組みですよね？
調べてみますね。相手がどこにいるか調べるプロトコルはどの機能を
実装するとしても絶対に必要になるので、最優先で検討すべき
課題だと思います。

83 ：
過去スレを読んできました（と言っても途中まで＆流し読みですが・・・）。
まだ、趣旨が掴みきれていないんですが、
１.ゲームを変える時、今までのレベルや所持金を移動できる
２.ゲームを止めるとき、今までのレベルや所持品、所持金を他人に売る事が出来る
３.違うゲームのプレイヤーにメッセージを送ったり、オンラインかどうかを確認出来る
という事を目指しているんでしょうか？そうなると、まず必要な物は、
・お金やレベルを変換するためのソフト（ゲームシャークのようなもの？）
・他人が悪用出来ないような、高度な認証システム
・ICQやメッセンジャーのようなソフト
他の製品を借りて、というか既存製品を寄せ集めて作るよりも、やはり独自の
製品を１から作ったほうが、セキュリティー面で安心できます。
やはり、ＲＦＣを作るとなると実現レベルの実装をしなくては行けないと
思うのですが、はたして、「タダ」でやってくれる人が現れるでしょうか？

84 ：
（さらに気になった点）
所持品や所持金を現金に換金するのは如何な物かと思います。やはり、
リスクが高そうだし、イメージが悪くなる気がします。例えば、
ネットゲームにハマルのは学生が多いですよね（時間の面で考えても）
大学生は良いのですが、中高生の場合お金を出しているのは両親の場合が
ほとんどです。アイテムや所持金を現金に変える事が出来るサーバ。と
聞いて、利用代を出してくれる親がいるでしょうか？
普通は「教育上余り良くないのでは？」「現金を扱うなんて、本当に
信頼できるのか？」「聞いた事の無い会社だし、今一心配」と躊躇
する人がほとんどだと思います。
さらに、換金システムを使うと、子供の中に悪意を持った大人が必ず
入って来ます。これで事件でも起こされると、サーバ運用は止めざるを
得ません（世間体もありますし）。
そこで、ゲームを止めるとき、その情報を貯めておき、次回ゲームを
したくなったときに引き続き使える。と言うサービスの方が良いの
ではないでしょうか？
サーバは銀行のような役目をして、クレジット（レベルや所持品、所持金）
をサーバ上に記録し、ユーザはサーバに「記録代」を月払いで払う。という
方が良くないですか？
（あくまで、ネットゲーマーでない、俺個人の意見ですが・・・）
それから「所持金、所持品、レベル」の変換には、お金は取らない方が
良いと思います。そこでお金を払うシステムだと、ユーザは集まらない
気がします（得に中高生やライトユーザ）。あくまで「サーバー利用代」
として月払いにした方が良いと思います。
（これもビジネス専攻でない俺個人の意見です・・・）
世間の信頼を得てはじめて「換金システム」を提案するべきだと思います。

85 ：
（更にもう一つ。しつこい＆長くてすみません）
とりあえず、今回のＲＦＣを作る為に必要なのは
「どのようにしてレベルや所持金を他のサーバのゲームに移行するか」
「どのようにしてメッセージ交換をするか」
「どのようにして使用料をサーバに支払うか（オンライン決済ですよね？）」
などが重要になる思うのですが、過去スレでは「ビジネスモデルの実現化」
という形で話が進んでいましたよね？
ＲＦＣは「インターネットに関係ある○○の標準化」という事でまとめ
られていますが（昨日少し読みました）、となるとビジネスモデルは
関係無いのでは？
もちろん、ＲＦＣ作成のためには（今回の場合）、ビジネスモデルを
考える事も必要不可欠だと思いますが、とりあえずはＲＦＣ作成のため、
もっと技術的な事を考えなければ行けないと思います。
でなければ、「２ｃｈでＲＦＣを作成。」ではなく、「２ｃｈで
ビジネスモデルを作成。」とスレ内容が変わってしまいます・・・

86 ：
＞お手伝いさん
紛らわしかったですが、過去スレは私の会社関連のいわば私的なスレッドで
このプロジェクトとは一切関係ありません。このプロジェクトは私の会社で
やっているような仕事と直接関係はありません。勿論会社で得られたノウハウ等
は（役に立つのであれば）提供しますが。
このプロジェクトを通してゲームの物を現金化するようなことは考えてもいません。
RFCの趣旨から言ってもおっしゃる通りビジネスモデルを考えるのではなく
技術的なことを考えるべきです。そこが過去スレと完全に違うところです。
（過去スレはタイトル通りビジネスモデルを考えるベンチャー板のスレッドでした）
RFCはそれを見た各事業会社が「これでこういうビジネスもできるようになるぞ」
等と考える為にも使われますが、それはRFCの極々一部に過ぎません。
現段階ではどのようにしてメッセージ交換をするのか、という問題を
解決するのかが第一だと思います。
過去スレとは根本的な思想（例えば世界と世界を安全に結びつけようという考え）
で全く関連が無いわけではありませんが、基本的には別物だと思ってもらって
かまいません。

87 ：
良くわからないけど応援あげ（ ● ´ ー ｀ ● ）

88 ：
>>86
なるほど。今回はＲＦＣ作成が最優先なんですね？
今回は「メッセージ交換」を中心に考えると言う事で良いんでしょうか？
上でＩＲＣの話が出ていましたが、ＩＲＣはユーザがサーバに
アクセスし、繋げていないといけないですよね？
メッセージをオフラインの人に送る場合、送信側のＰＣに
メッセージを保存し、相手がオンラインしたら自動で送る。ように
するのか、サーバに一度送信し相手がオンラインになったら、
サーバから送信するようにする。かでも色々変わってきますよね。
ＩＲＣ自体のＲＦＣはあるはずですから、今回は何のＲＦＣを
作成するんですか？
このプロジェクトには、余りにも多くのトピックがありすぎて、
たった一つのＲＦＣを作成する。と言う訳には行かないと思います。
最初にプロジェクトを細かく分け、グループ分けする事が必要だと思います。
まぁ、この辺の議論には、俺は余り役に立てそうも無いので、ＩＲＣの
ＲＦＣでも読んできます・・・

89 ：
技術的なお手伝いはあまり出来ませんので、
ひとりのネットゲーマーとして参加したいんですがよろしいですかねぇ‥‥。
とりあえず
>>85 「どのようにしてレベルや所持金を他のサーバのゲームに移行するか」
他のサーバーに移行する必要は無いかと思います。
仮想世界の住人（具体的にはネットゲーマー）がどのような取引をしたいかと言えば、
またUOを例に出して申し訳ありませんが、
AsukaとHokutoというサーバーがあったとして、
AさんはAsukaのお金をHokutoのお金に、
Bさんはその逆でHokutoのお金をAsukaのお金にしたい、
というような場合に、AさんBさんとでAsuka内とHokuto内で
それぞれトレーディングが行われるわけです。
Asukaサーバー:Aさんはお金をBさんに渡す
Hokutoサーバー:Bさんはお金をAさんに渡す
ということです。
仮想世界間の取引ではありますが、別の世界とデータが交換されることはないですよね？
現状ではこのような取引が安全に行えず、完全な信用取引になってしまっているので
これをシステムとしてサポート出来るようなものを作ろう、という事だと思います。
間違ってたらごめんなさい。

90 ：
>>89
　先の>>42は、なかなか好感の持てる発言です。

91 ：
本日発表されたPS段階のRFC3201なんですが関係ありそうでしょうか？
メーリングリストの案内文をのっけます。
This memo defines an extension of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing the
insertion of interesting Circuit Interfaces into the ifTable. This is
important for circuits that must be used within other MIB modules
which require an ifEntry. It allows for integrated monitoring of
circuits as well as routing to circuits using unaltered, pre-existing
MIB modules.
This document is a product of the Frame Relay Service MIB Working
Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol. Distribution
of this memo is unlimited.

92 ：
>>91
もう…
なんでもかんでも関係付けるの止めれ。
MIBって何か検索すれ。
こんなの書き込むなら、sageでやってくれ。

93 ：
>>89
具体例をあげていただきありがとうございます。
上記のようなサーバー間の安全な取引を可能にする仕組みは
サーバー間のメッセージ送信の目処が立った段階で取り掛かりたいです。
メッセージ送信を行わず例えば通貨の交換を行うのは非現実的でしょうし。

94 ：
>>92
すいません　今度からこういうのはsageで書き込みます。
仮想世界を結びつけた時にそれぞれの仮想世界の状況を
保持する仕組みがMIBと関係あるかと思ったのですが、
電機大の人に否定されたということは全く見当違いだったようですね。

95 ：
別に関係あってもいいですけど、っていうか、
過去ログ見た限り、全部関係するんでしょうね。
コンピュータネットワークに関係しているものなら、
なんでもかんでも全部関係するでしょう。
だけど、技術っていうのは、必要になったときに使うもので、
そのために、規格（規約）があるんでしょう。
必要なときに、必要な分だけ使えばいいんです。

96 ：
　思うのですが、メッセージは、HTTP/HTTPS上でやり取りする方が
中継点やＦＷの透過性を考えるとベストの様な気がします。後は、
例えば、<BODY> </BODY>間にメッセージ本体を収納し、<META>タグ
中にキーワードを埋め込めば、取り違えを防止出来ると思います。
　それと、交換するメッセージも、当事者同士が直接対話するより
も、予め考えられる取引条項全てを網羅する書式を定め、自分が希
望する取引行為をサーバへアップロードし、それ等のプール情報か
ら条件が適合する相手を自動的にサーチし、最終確認を経て、日時
指定に基付く度数譲渡を行えば、基本的な取引が成立する筈です。
　この際、仮想的な銀行や取引所の役割を果たすサーバが存在すれ
ば、ここへ擬似的な口座を開設する事で、オフラインの相手との取
引も行えると思います。但し、この口座は、個々の仮想世界サーバ
とリアルタイムで連携する機能として実装する必要があります。

97 ：
>>95
了解です。重要なものと余り重要でないものを見分ける力が足りない
ようです。
>>96
ふむふむ　その形式で標準化するならXMLでしょうかね？

98 ：
あーすみません、
具体的に何が出来るようになるんですか？

99 ：
XMLやるなら、もうIETFじゃなくてW3Cに行った方がいいんじゃないか?
何となく、通信手段は既存のプロトコルでできちゃうような気がする。
今更、新たな通信プロトコルを考える意味はなさそう。
そもそも、まず言いだしっぺが具体的にやり取りしたい「情報」とその「手段」を
もう少し具体化しなくちゃ始まらないでしょう。RFC作りたいなら、
せめて「コメントをリクエスト」できるような叩き台を提示しないか？

100 ：
>>98
初期段階では仮想世界の異なったアプリケーション間・サーバー間でメッセージの
やり取りが可能になります。さらにプロジェクトが進行すれば
異なったアプリケーション間・サーバー間の取引が安全かつ低コストで可能になり
従来バラバラであった仮想世界の規格がある程度統一され、仮想世界が益々発展する
原動力になる可能性、仮想世界を使った新たなサービスが登場する可能性があります。
>>99
まず　やり取りしたい情報は　現段階ではテキストの会話（日本語等の２バイト文字含む）
です。その後世界間で取引をする為に必要な情報を扱っていきたいです。
手段は現段階ではメッセージ交換のシステムについての提案は３種類位出ています。
>>78　の形式と　>>96　の形式　ですが、どれがいいかメリット、デメリットをあげて
比較検討してみましょうか？

101 ：
あ。テキストの交換はUnicodeかなんかそういう国際化考えた符号化でお願い。
「日本語等の２バイト文字」っつう表現で危機を感じたんで主張してみました。

102 ：
新たなＩＭのプロトコルを考えるのであれば、
公開カギ暗号ベースの認証・否認防止機能を備えた
プロトコルを作ってみるのはどうですか？
マイクロソフトのPassport型ではなく、PGP型で。

103 ：
>>101
了解です。
>>102
とても面白そうですが、まだ無いんですか？無いならそれだけでも
やる価値ありそうですがMSが黙ってないでしょうね。
既に似たものがあるとしたらそれを仮想世界向けに拡張するという形で
提案できるかもしれません。

104 ：
>>99
補足です。仮想世界を通したVoIPでマイクをつけている
異なった仮想世界の参加者同士が音声で会話できるようにする
という方向に拡張することもできるかもしれません。

105 ：
今IETFのMLに参加しているんですがここ２４時間以内にIDが３６件
RFCが２件投稿されています。興味がある物は斜め読みしています。
年始で今までの分が貯まっているからといって多すぎじゃないでしょうか？
それともいつもこのくらいの量が来るのでしょうか？
解説（要約）のわからない言葉を調べるだけでかなり勉強になりそうです。
ある程度英語が読める参加者の方は一度雰囲気をつかむために参加してみては
いかがでしょうか？止めるのは簡単ですし。
申し込み方法が載っているページはこちらです。
http://www.ietf.org/maillist.html
私はIETF Announcementを取っています。

106 ：
手、広げすぎ。

107 ：
>>106
では　とりあえず、仮想世界間でUnicodeを使ってメッセージをやり取り
する仕組みを考え、可能であればやり取りの際の仮想世界間のパケットの
ルーティングについても考えましょう。（テキストだけなら負荷はかからないかな？）
MPLSのワーキンググループが活発にIDを投稿していますので、そちらの
成果次第ではルーティングについては方針を決めておくぐらいでいいかも。

108 ：
>>107
なんでMPLS？やはり手広げすぎです。
とりあえず余計な半端な知識を入力するのをやめたほうがいいです｡
「〜を実現したい」、と一言言えば、あとは周りが考えてくれる、くらいの
意識でいてくれたほうが助かります。
というか本当にルーティングまで手を出すのですか？
何をしたくて何の必要性があってのことかよくわからんです。

109 ：
>>108
わかりました。
「他の仮想世界の人とメッセージをやり取りしたい！！」
そのためにも「知り合いがどこの世界にいるのか知りたい」
大風呂敷を畳んでみましたが、いかがでしょう？

110 ：
>>109
XMLはほとんど名前しか知りませんが、前に出てきたHTTP/HTTPS上でXMLの
やりとりをするのであれば、
１．複数仮想世界サーバ宛てにまず捜索願を出してまず現住所を確認，
　　いなければ行方不明
２．どの仮想世界にいるかわかれば，その世界のその人宛てにメッセージを
　　送信
という感じでしょうかね。世界が増えると１がとんでもないことになるから，
ULSのようなものがあってもいいかも。
捜索願の中身は、人をどうクラス化するか決定して、複数条件で捜索すれば
いいでしょう。したがって仮想世界間で共通のクラスを使用するか、使用可能
な属性をネゴシエーションするような仕組みを考える必要があるかと。
仮想世界サーバ：他世界からの自世界への要求を受け答えるサーバ
捜索願：検索に用いる属性の集合

111 ：
とりっぷ付けてみました。
>>106
Unicodeに限定する必要があるのでしょうか。
プロトコル側で文字コードをあらかじめUnicodeと決めてしまうのではなく
文字列送信時にどんな文字コードなのかを相手側に伝えられるように
なっているだけで十分だと思いますけど‥‥。
>>110　＞１．複数仮想世界サーバ宛てにまず捜索願を出してまず現住所を確認
同じ人が同時に複数の仮想世界に存在することも十分考えられることなので
（ゲームクライアントを同時に何個も立ち上げて全部ログインした場合など）
現住所は常にひとつとは限らないですね。
その場合送信する側の人が、相手が存在する複数の仮想世界の中から
メッセージを送信する世界を選ぶ形になるんでしょうか。
そうだとするとIRCで相手をwhoisして出てきたチャンネルにログインして
その人とチャットする感覚に近そうですね。

112 ：
>>111
>複数の仮想世界の中からメッセージを送信する世界を選ぶ形
実装依存じゃないでしょうか。
捜索願いの応答で何が帰ってくるのかにも依りますが、アイドル時間
とか最終ログオン時刻とかでクライアントが勝手に判断してもいい
でしょうし、ユーザに選択させてもいいでしょう。
ユーザインタフェースはRFCで決めることではないと思います。

113 ：
　仮に、二者間でメッセージ交換を行う場合、対話相手を特定する
根拠が必要になります。例えば、ドメイン名の様に、特定の機関か
ら発行されるコードを利用する場合、このコードと仮想世界内での
ユーザ名とを対応させる事も必要でしょう。
　場面にも拠りますが、伝えたい内容が、ある一人の人物へ届く事
を目的とするなら、どの仮想世界に滞在していようとも構わないで
しょう。逆に、特定の仮想世界に滞在している時にだけ意味を持つ
内容もあるでしょう。
　こう考えると、相手を表現する書式は、二本立てになるかもしれ
ません。

114 ：
>>105
既存のRFCやドラフトも読んでないのに、ITTFのMLに入るのは意味無いと思う。
せめて、上位層のSTDに目を通しておくくらいは必要だと思うが。
でないと、>>107のように、ルーティングやら2.5層のMPLSなんかに
訳もわからず目が行ってしまう。
IP上でメッセージ交換するだけだったら、ルーティングなんて関係ないでしょ。
それとも、BGPの拡張コミュニティでメッセージでも交換しますか?

115 ：
Fibre ChannelからXMLまで決めるんなら、IPも考え直して、
一から十までぜーんぶ独自に設計すりゃいいんじゃない？って感じ。
もちろん、独自世界だから、面倒なRFCなんかにする必要もない。

116 ：
なるほど、インターネットに乗せないで、すべて独自の網を世界的に構築するということか。
それなら、MPLSを使うのもいいかもしれない(w

117 ：
ハードの枠（携帯、PC、ゲームマシンなど）は超えるんですか？
どんなOSにも互換を持たせる予定はあります？
それから無料サービスですよね実現したら？
アクセス過剰が起きて、重たくなった、もしくは停止した場合の回避機構は？
セキュリティのレベルは？
ユーザー名が重なった場合の識別要素は？
不正アクセスの対策は？
色々思いついたこと言ってみました。

118 ：
うわ　しばらく見ない間にレスが貯まってます。
>>111
Unicodeが使えれば良いのでネットゲーマーさんの考え方で
いいと思います。
>>113
いつも客観的な意見や指摘をしてくださって助かっています。
>>114
将来の話を考えすぎました。音声や仮想世界間の取引所のような
構想間で考えると仮想世界間の回線に相当な負荷がかかると思ったので。
>>115
RFCはネットコミュニティでコンセンサスを形成する為
という大事な役目がありますよ。
>>116
Over IPですからインターネットと全く関係なくなることは無いでしょう。

119 ：
>>117
＞ハードの枠（携帯、PC、ゲームマシンなど）は超えるんですか？
当然超えたいですが、検討課題でしょう。
＞どんなOSにも互換を持たせる予定はあります？
視野には入れています。しかし仮想世界にログインできるということは
仮想世界からユーザーにどう伝えるかは仮想世界側で当然考えてくれている
でしょう。
＞それから無料サービスですよね実現したら？
ユーザーは基本的に無料でしょう。仮想世界の運営元からは
その世界の認証をする代金をどこかの機関に納めてもらう形に
なるかもしれません。ペリサインみたいなものでしょうか。
＞アクセス過剰が起きて、重たくなった、もしくは停止した場合の回避機構は？
検討課題ですがメッセージやり取り位なら大丈夫でしょう。
＞セキュリティのレベルは？
メッセージのやり取りならほとんど考えなくて良いでしょう。

120 ：
＞ユーザー名が重なった場合の識別要素は？
各世界に固有の番号を振って各個人にも各世界が固有の番号を振る
各個人が別の世界の固有番号を自分と関連付できるようにする。
という感じでしょうか。検討課題です。
＞不正アクセスの対策は？
各仮想世界の認証と各世界のセキュリティに依存します。
一つの仮想世界のある個人がパスワード盗用等により
他人に侵入されても、その個人以外の財産に被害が及ばなければ
良いと思います。（その個人が被害を受けることは仕方が無い）
今後の検討課題でしょう。
>>117さんの質問は重要なことだと思うので、それぞれの方が
それぞれの立場で考える必要がありそうです。

121 ：
>>1
質問の受け答え読んでると、あなたよりも技術をもった人は、
なかなかプロジェクトに参加しようとしないと思いますよ。
ネットワークプロトコルはなぜ階層設計されているのか、
っていうところから分かってるのか「？」だし。

122 ：
やっぱ、2chでやって、効率のあがることじゃないと思う。
構想すらできてないんだから。
Web+MLでやることでしょ。

123 ：
うむ　勉強不足ですみません。
上位層が下位層から相対的に独立性を保っていれば
議論も開発もやりやすいからではないでしょうか？
何故階層設計されるようになったのかという経緯は
よくわかりませんが、別の標準化の団体かなにかから
いい考えかただから持ってきた、とどこかで見たような・・・

124 ：
もうちょっと、勉強してくれってとこで。
>>119
＞＞セキュリティのレベルは？
＞メッセージのやり取りならほとんど考えなくて良いでしょう。
えーと。
ほんとに考えなくても良いのかどうかよく考えてください。
最終的には取り引きなんかが載っかるプロトコルだよね？

125 ：
>>124
取引を乗っけると膨大なデータが流れることが予想されます。
そこでセキュリティも考えた上でMPLSってどうだろうと書いたところ
手を広げすぎだ！！と言われているのが今の状態です。
要求されるセキュリティレベルに応じてプロトコルが変わるのは
当然ですから、まずは雑談レベルのメッセージのやり取りを考えて
ほとんど考えなくて良いでしょうと書きました。
現在は参加者間の取引も暗号化されていないメールや掲示板上の
誰でも見れるメッセージのやり取りでなされているのが現状です。

126 ：
つい先ほど、非常に関係がありそうなワーキンググループが提案されました。
必要でしたら要約の日本語訳出しますが、いかがでしょうか？
A new IETF working group has been proposed in the Applications
Area. The IESG has not made any determination as yet.
The following Description was submitted, and is provided for
informational purposes only:

Content Distribution Internetworking (cdi)
- ------------------------------------------
Current Status: Proposed Working Group
Description of Working Group:
The goal of this working group is to define protocols to allow the
interoperation of separately-administered content networks.
A content network is an architecture of network elements, arranged for
efficient delivery of digital content. Such content includes, but is
not limited to, web pages and images delivered via HTTP, and streaming
or continuous media delivered via RTSP.
The working group will first define requirements for three modes of
content internetworking: interoperation of request-routing systems,
interoperation of distribution systems, and interoperation of
accounting systems. These requirements are intended to lead to a
follow-on effort to define protocols for interoperation of these
systems.
The working group must clearly distinguish between (and justify)
short-term fixes and requirements to extending the addressing/content
architecture.
In its initial form, the working group is not chartered to deliver
those protocols, but we encourage individual submission of
internet-drafts describing protocols intended to meet the evolving
requirements. We anticipate rechartering of the working group to
specify protocols, after the requirements documents are stable and
rough consensus emerges about the number and relationship of such
protocols.
In addition to defining requirements, the working group will develop a
number of supporting documents. These documents are: a shared
vocabulary for the problem domain, scenarios, an overall architecture
for interoperation, and a summary of request-routing mechanisms
currently in use. The total expected deliverables are as follows,
including the current draft corresponding to each:

127 ：
>>112
うぅ、確かに実装に依存する部分ですね。
というかサーバーごとにその人の存在を問い合わせる事になるんですよね。
「世界が増えると１がとんでもないことになるから」の意味が今理解できました‥‥。
>>119
プロトコルを作るのであれば、一般的にOSやハードウェアに依存するものには
ならない気がするのですがいかがでしょうか。
検討課題ではなくそれを前提にしないと行けない気がします。

128 ：
>>127
OSやハードに依存することなく仮想世界の参加者同士が会話・メッセージのやり取りが
できるようにプロトコルを決めましょう！
という方針で行くべきですね。やっと根本的な方針が固まってきました。

129 ：
>>128
思うんだけど、IP Messenger とか ICQ じゃ駄目なの？
新しくプロトコル作ったらどうせ対応したサーバとかクライアントも作らなきゃいけないし。
それだったら既存のもの使ったほうが遥かに楽だと思うんだが。
Jabber なんていかが？ ICQ な人とも AIM な人とも話せるし。ソースも公開されてるし。
http://www.jabber.org/
とりあえず、RFC を messaging で検索したら RFC 2779 とか RFC 2778 がひっかかった。
って...これって....むむむ。
http://www.microsoft.com/japan/developer/exchange/techart/rvp.asp
にしても...MPLS 関係ないじゃん... 手を広げすぎだ！の意味わかってないですね。
関係ありそう！って思ったら、ここに書くまえにちゃんと RFC 斜め読みぐらいしてね。

130 ：
>>129 自己レス
つーか、e-mail でいいような....
暗号化も出来るし、署名も出来るし。
クライアントもいっぱいあるし。
プロトコルとしてもかなり環境に依存してないし。
現実世界が仮想世界のブリッジとなることに問題はあるだろうか？
誰がどこにいるか？ってのを世界を超えてやり取りしたいっていうなら
またちょっと話は別か。

131 ：
とりあえず、仮想世界に対する統一されたアドレッシングが必要では？
どの仮想世界の誰に対するメッセージが分からないと困るんじゃないですか？
あと、仮想世界アドレス→IPアドレス,ポート番号に変換する機構とか･･･
宛先の仮想世界を特定するのに、IPアドレスとか使ってると不便そうですし･･･
同一ユーザが複数仮想世界に同時に存在する可能性もあるわけですし･･･
そういう時、どの仮想世界にいる、そのユーザに対してメッセージを送るのか、
それを表現できるようなアドレスが必要なんじゃないっすか？
そうしないと、時々刻々と増減する仮想世界間でメッセージをやり取り
するのは難しいのでは？ っとか思ってみたり･･･

132 ：
普段は「ななし」なんだけど，PSOのキャラ名でｗ
面白そうな事やってるなぁ，と思ってるんだけど，
おいらも傍観モードかな？
>RURさん
志自体には賛同するんだけど，スレをざっと見
させてもらったところ，足が地に付いていない
ような気がします。まずは実装の勉強をするべき
じゃないかと。FreeBSD（こういう目的ではLinuxは
あんまりお勧めできない）とかのUNIXをいろいろい
じって勉強するといいよ。ソースとかもついてるし，
改造するだけでもかなりスキルアップできる。
但し，Ｃ言語の知識は必須ね。
おいらもすんごく興味のある分野で，小規模ネット
ゲー向けiDC作りたいと思ってるから，こういう相互
交流システムはいつか手をつけないと，考えてた
から最初は嬉しかったんだけどね…。
まあ頑張ってください。このスレは観察しています
ので，おいらに出来そうなことがあったらまた出て
きます。

133 ：
>>129
仮想世界の一つであるMMORPGの場合、チート行為を防ぐためといった
理由で同時に他のアプリケーションを動かせないことが多いです。
モニター切り替え機等を使って1台でメッセージのやり取り、
もう一台で仮想世界に参加とかやる人もいますけどね。
今考えているメッセージングだけならそういう発想が出てくるのは
よくわかるのですが、将来的に世界間にまたがる商取引等を考えると
仮想世界を通してメッセージをやり取りする仕組みを作ることは
意味のあることだと思います。

134 ：
>>131
必要性に関して同感です。ただこれだけでRFC１個に相当する
内容かもしれませんね。仮想世界間でメッセージをやり取りする
為にどうしても必要であれば、こっちを先にやるべきかもしれません。
>>132
はい、勉強が全然足りないということを痛感しています。
Cの知識は大学のゼミでVC++をいじっていた位ですが同時並行で
FreeBSDも勉強します。とりあえず今のところRFCの英語を
読みまくっています。

135 ：
>>133
それじゃ、他のアプリケーションで実装するんじゃなく、
各社の出してるゲーム上で実装してもらうってことなんですね。
なんていうか、これって RFC にするまえに、
各ゲーム会社に話を持っていって相談するのが先のような。
んで、代表出してもらってグループ作ってそこで規格を練るみたいな。
勝手に RFC 作っても売りこまないと実装してもらえないと思うんだが。
各ゲーム会社がそれを実装するメリットは？ とかも考えないとね。
ユーザの取り合いしてる MMORPG の提供会社はそれを望むだろうか。
UO と EQ 間で取り引き出来るようになることを喜ぶのは誰？
それとですね、商取引にこだわるのはいいんですけど、
商取引とメッセージングはレイヤーが異る問題だと思うんだけど。
なんか目的と手段を取り違えてきてるような気がしないでもない。
RFC にすることはとりあえず忘れたら？

136 ：
>>131
たとえば、urn みたいな感じにするとして。
そんでもって FF11 と UO だったとして。
スクェアが作ってる FF11 で hoge って街の相対座標 (1,3) にいる huga さん。
絶対座標だと (100,29) だとする。
(FF11 の内容しらんからテキトー)
urn:virtual-world:square/final-fantasy-XI/hoge/1,3/huga
または
urn:virtual-world:square/final-fantasy-XI/100,29/huga
Electronic Arts が作ってる UO で
Wakoku サーバの Trammel の Minoc の相対座標 (19,3) にいる Nori さん。
宿屋(名前忘れたからてきとう)henoheno からだと (1,0)。
絶対座標だと (299,3488) だとする。
urn:virtual-world:electronic-arts/ultima-online/wakoku/trammel/minoc/19,3/Nori
または
urn:virtual-world:electronic-arts/ultima-online/wakoku/trammel/minoc/henoheno/1,0/Nori
または
urn:virtual-world:electronic-arts/ultima-online/wakoku/trammel/299,3488/Nori
みたいな感じになるのかな。
なんにしても、標準化する団体が必要。
だって勝手に定義できるようにしたら、ネームスペースが被りまくる。

137 ：
>>136
街内部の座標は関係ないのでは？人に番号を振ってその人に
届くようにすれば、それをどう表示するかは実装側の問題だと
思う。日本の各会社に話を持っていくのは簡単なんだけど
世界で話し合って決めないといけないことだと思う。

138 ：
日本の某社（この分野のシステムでは大手）がロビーサーバー作って
そのロビーサーバーを使ったゲーム同士では会話できるようにしよう
としたけど、違う会社の世界間で会話できる仕組みが採用されたって
話は聞いたことがないです。世界中の会社から代表を出して話し合う
位ならRFCで技術的なことを話し合って決めた上で、RFC（PS）位に
なった段階で世界の各社に検討に加わるように呼びかけたほうが
早いと思います。検討に加わった会社はRFC（STD）になったとしたら
実装してくれるでしょうし、仮想世界のシステムを専門に作る会社
（仮想世界を運営する会社とは別のこともあります）なら、もっと
早い段階で実験的に実装してみようと思うでしょう。

139 ：
>>137
た、たしかに...座標は要りませんな。
番号を振るっていうか、たしかにその人だっていう識別情報が在ればいいのか...
余談だけど、UO で同名が存在出来るじゃない。
あれを無視して、一意に認識できる ID 的なものを導入していいもんなんだろか。
話持ってかなきゃいけないのは、日本の各会社じゃなくて世界の各会社です。
日本がフルスクラッチで書いてる MMORPG は少ないですよね？
そして、話あわなきゃいけないのは、関係のある人達で充分です。
関係のある人達はもちろんユーザも含んでますよ。
で、>>135 での、利害関係については考えてみました？
あと、
・MUA 機能をクライアントに実装して e-mail でやり取り
・ICQ とか Jabber とかの既存の IM の機能をクライアントに実装
ってのが不味い点ってなにかあります？

140 ：
>>139
＞余談だけど、UO で同名が存在出来るじゃない。
＞あれを無視して、一意に認識できる ID 的なものを導入していいもんなんだろか。
同名が存在できる為に取引の場所に同名のキャラクターを先に行かせる
詐欺等が発生できる要因になっています。名前は一つでも個人は識別できた
ほうがいいと思います。
＞話持ってかなきゃいけないのは、日本の各会社じゃなくて世界の各会社です。
＞日本がフルスクラッチで書いてる MMORPG は少ないですよね？
＞そして、話あわなきゃいけないのは、関係のある人達で充分です。
＞関係のある人達はもちろんユーザも含んでますよ。
インターネット上の仮想世界はMMORPG等のゲームだけなんでしょうか？
もしゲームの関係者だけで規格を決めて、それが事実上の標準に
なったとします。別のゲーム以外の仮想世界の運営元はそれに
参加できるでしょうか？あるいは参加しようとするでしょうか？
利害関係についていえば、自分はMMORPGの話しかわかりませんが、
従来一人の人間が同時にやるMMORPGは通常一つでした。
何故なら同じ世界の人としか会話ができない為、いくつもゲームを
掛け持ちしてもコミュニティがバラバラだからです。
ゲーム内から直接他のゲームをやっている人を呼べるようになれば
普段はメインゲームにいて、呼ばれた時だけ別のゲームに参加する
人が増えるでしょう。そうすれば一人の人が平均3つ程度のゲームに
毎月料金を払ってくれるようになるでしょう。ゲーム会社の収入は
増え、しかもサーバーの負担は従来と大差ないと思います。

141 ：
・MUA 機能をクライアントに実装して e-mail でやり取り
・ICQ とか Jabber とかの既存の IM の機能をクライアントに実装
の返事を書こうと思ったんですが、外出しなければなりません。
また後ほど。

142 ：
>同名が存在できる為に取引の場所に同名のキャラクターを先に行かせる
>詐欺等が発生できる要因になっています。名前は一つでも個人は識別できた
>ほうがいいと思います。
わざわざそういう仕様だとしたら？
ベンダーがどう思ってるか聞いとかないと頓珍漢なものが出来ると思いますね。
>インターネット上の仮想世界はMMORPG等のゲームだけなんでしょうか？
>もしゲームの関係者だけで規格を決めて、それが事実上の標準に
>なったとします。別のゲーム以外の仮想世界の運営元はそれに
>参加できるでしょうか？あるいは参加しようとするでしょうか
その規格がオープンだったら全然問題ないでしょう。
>ゲーム内から直接他のゲームをやっている人を呼べるようになれば
>普段はメインゲームにいて、呼ばれた時だけ別のゲームに参加する
>人が増えるでしょう。そうすれば一人の人が平均3つ程度のゲームに
>毎月料金を払ってくれるようになるでしょう。ゲーム会社の収入は
>増え、しかもサーバーの負担は従来と大差ないと思います。
あなたがそう思うのは勝手ですけど、
企業側はどう思ってるか調べてみてからでも遅くはないのでは？
ほんとにユーザは普段やりもしないゲームの料金を払うの？
MMORPG の世界の住人と他のそうでもない人々との温度差を調べてみては？
最初にやるべきことは
2ch で RFC 作ろうなんてのたまうことじゃないと思うぞ。絶対。

143 ：
>>142
＞2ch で RFC 作ろうなんてのたまうことじゃないと思うぞ。絶対。
　今、我々がこうしてインターネットを気軽に楽しめるのは、世界
中の多くの人々の努力の賜物です。例え、（内容が）チッポケな掲
示板であろうと、そこの参加者は、彼らに敬意を払うべきです。そ
して、手を伸ばせば届く場所に、その感謝の気持ちを形で表す機会
が横たわっているのなら、…。
　それと、技術者の方々にとっても、ＲＦＣの発起を、その起源か
ら成長過程まで全て目の当たりに出来る事は、決して損にならない
と思います。何だかんだ言いながら、結構、多くの人が、このスレ
に口を挟まないでいられない現実を見れば、然もありなんです。

144 ：
>>143
べつに 2ch でのたまうなっていってるんじゃなく、
最初にやるべきことは市場調査だっていいたいんですが。

145 ：
+--------------------+----------------------------+
| アプリケーション層 | 取引やチャット等の仮想世界 |
|--------------------| 間の具体的なサービス |
|プレゼンテーション層|----------------------------|
|--------------------| 統一された転送プロトコルや |
| セッション層 | 仮想世界のアドレス解決等 |
|--------------------|----------------------------|
| トランスポート層 | |
|--------------------| |
| ネットワーク層 | 下位層 |
|--------------------| (既存プロトコル) |
| データリンク層 | 規定しない |
|--------------------| |
| フィジカル層 | |
+--------------------+----------------------------+

146 ：
ｽﾍﾟｰｽが･･･ｳﾞｧｶやってしまった･･･ｽﾏｿ。
鬱だし、逝ってきます。

147 ：
　この掲示板へテキストベースの表を書き込む場合、ワードパッド
等を利用して、[ＭＳ Ｐゴシック:12]で体裁を整えます。
　但し、以下の点に注意して下さい。
・行頭の半角空白は、全て取り除かれます。
・何処に現れようとタブコードは、全て取り除かれます。
・改行が<BR>に、<>が<>に自動変換され、修正不要です。

148 ：
訂正：<>が<>→<>が&lt;&gt;

149 ：
追伸：ネットスケープユーザさん、マックユーザさん、すいません。

150 ：
・MUA 機能をクライアントに実装して e-mail でやり取り
・ICQ とか Jabber とかの既存の IM の機能をクライアントに実装
メッセージのやり取りだけならメールを使うのはかなり有力でしょう。
欠点といえば遅いのでチャットに向かないこと位でしょう。
少なくともこれが実現されるだけで今よりは全然便利になります。
IM機能の実装の場合、無料でゲームサーバーに組み込めるなら可能性はあります
が、メーカーがIMの会社にお金を払わないといけないなら難しいでしょう。
一から仮想世界向けにIMを作るというならここでやったほうがいいかも
しれません。
>>142
来週はちょっと忙しいので再来週あたりいくつかネットゲーム会社の人に
会ってきますね。

151 ：
＞アドレス解決
これなんですが、各サーバーにユーザーの存在を問い合わせる形ではなく、
クライアント側のマシンに直接その仮想世界にいるのか
どうか問い合わせる形というのはどうでしょう。
pingの仮想世界存在確認版みたいな感じ（？）です。
それならIPを使ってユーザーを特定できそうですし。
IPアドレスとハンドルネーム（識別名）の名前解決はIRCのようにして
サーバー名（仮想世界のサーバーではなく名前解決用のサーバーです）と
ニックネームから個人が特定出来ればよろしいかと。

152 ：
世界中のサーバーが互いにオートで接続を確立できる機構、それから
ユーザーが簡易に各サーバーからサーバーへと出入りできる機構、どうですか？
管理するのを一定のソフトウェアにするのか、既存の多種多様な接続機構に共通のプラグイン
を設けて異なる機構間でもどうようの効果を持たせるのか、それとも極端な話し「世の全ての
機構に通じる仮想世界OS」を作るのか、いかがでしょうか？
私思うんですけど、異なるサーバー間の仮想世界を統合するものではなく、各サーバー
の仮想世界が実在できる共通仮想空間、この世界で言う「宇宙」の概念を持ったもの
なんか作れないんですかね？言わばサーバー一つ一つが惑星に見たてられるような物です。
だから、その共通仮想空間に存在するユーザーはどの仮想世界でも通じるステータス
（この現実世界で言うなら、個々が人間というステータス）を持たなければなりません。
視覚的なプログラミングは後でも提案できますから置いておきましょう。
RURさんの手元にスーパーコンピューター並のサーバーを置いてもらい、そのサーバーが
24時間体制で共通仮想空間の機能を世界中に提供してもらうのはどうですか？
代表者がRURさんだと判断しての発言です。気を悪くしたら申し訳ありません。

153 ：
すみません。改行箇所間違えました(>_<)

154 ：
RUR ◆sLgvSGbo さんへ
ここも結構進んできてるみたいですね。
がんばってください。
http://yasai.2ch.sc/test/read.cgi/event/1009637702/
イベント板にある
「２ｃｈでいいことをしてニュースに」というスレッドも
だいぶ話が進んできました。
2chのパワーをつかって
世の中の役にたとうという点では
どちらの企画も通じるものがあると思います。
おたがい頑張っていきましょう。
僕はRFCのこととかはまったくわからないので
何のお手伝いもできず、ROMるだけ（読んでてもよくわからなかったりする。）
ですが、応援しています。

155 ：
>>152
＞RURさんの手元にスーパーコンピューター並のサーバーを置いてもらい、そのサーバーが
＞24時間体制で共通仮想空間の機能を世界中に提供してもらうのはどうですか？
　集中管理（スター）型の最大の欠点は、中央がダウンすると、機
能が停止して仕舞う事です。勿論、プライマリとセカンダリを置く
事である程度稼動性能を上げられますが、地域的に分散させないと
意味がありません。ここ（インターネット）がこれだけ普及してい
る最大の理由は、網（ネット）である事です。

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

157 ：
>>156
　例えば、最近のインターネットエクスプローラでは、アドレス欄
にＵＲＬを指定すると外へ、ローカルパスを指定するとファイラに
変化するのをご存知ですね？
　この様に、内部アーキテクチャが別物でも、操作上シームレスに
する事は、可能だと思います。要するに、基本的な機能を実装する
為の約束毎を幾つも作り、それらを組み合わせて複雑な機能を実現
し、それらをユーザインターフェイスでカプセル化するのです。利
用している人は、共通仮想空間にいる様な錯覚に陥ります。
　例え、何処かの仮想空間でトラブルが発生しても、他の仮想空間
への影響が発生しない様な、普遍的なモデリングを確立できれば、
怖いもの無しです。ちょっと話が抽象的？

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

159 ：
DNS を立ち上げるってのはどうでしょ？
世界で動いてるのとは別の管轄で。
これなら分散も効いてるし、会社ごとに細かく管轄を分けれるし。
root を RUR さんの会社で持てばいいし。
>>158
あと、UI について話すのはあとじゃない？
これは実装者が考えることだし。
スレタイトルと内容がずれてきたような。
ま、こういう話をし終わってから RFC 作ろうよっていいだすのが
本当なんだけどもん。

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

161 ：
>>158
＞で、どうゆう風に開発が出来ますかね？ その約束事を。
　例えば、>>160 のリアルタイム性の確保ですが、各仮想世界は、
以下の所作を行いましょうと呼び掛けます。
------------------------------------------------------------
・起動時にhttp://www.xxx.com/xへアクセスし、エージェント探索。
　＜アクセス不能なら、前回アクセス分のエージェントを採用＞
・各エージェントへアクセスし、自世界が稼動している旨通知。
　＜定期的に実施し、住民属性（人数、人種、etc.）を添付＞
・任意エージェントへアクセスし、他世界の稼動状況を照会。
　＜必要時に実施し、住民属性（人数、人種、etc.）を受領＞
------------------------------------------------------------
　ここで、住民からの外部への捜索要求がある場合、条件属性から
存在する可能性のある各仮想世界を割り出し、直接クエリを発行す
る事になるでしょう。
　それと、これは、飽く迄、簡単な約束とは、何ぞや？の例として
上げていますので、プロトコルじゃないです。
============================================================
＞あと何で開発できるかですね。
　この場合、言語（ＣとかＣ＋＋とか）に依存していません。

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

163 ：
> IM機能の実装の場合、無料でゲームサーバーに組み込めるなら可能性はあります
> が、メーカーがIMの会社にお金を払わないといけないなら難しいでしょう。
メーカーさんもそうでしょうが、
むしろ（今のところ）MMORPGを作ってフリーで提供しようなどと考えてる
一個人の私なんかはお金を工面出来ないので参入できなくなるのですが・・・

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

165 ：
>>159
私もRFC の製作の以前に、RURさんの言う仮想世界が
漠然としていたものですから、まずやはりUIからかな、と。
DNSは確かにグッドアイディアだと思います。
私の言う「共通仮想空間」に通じますね。割り振ってくれますから。
>>160
その問題がありますね。しかしリアルタイム性の確保はあくまで、
ユーザーの稼動状況を照らし合わせた上で「ユーザーの接続に
現在進行で呼応するようにできる機構」であると私は理解します。
つまり、各ユーザー同士は様々な事に「同期」を取る事は出来ても
真に同次元の世界を体感したことにはならないのです。（まだ続きます↓）

166 ：
(続き)
この現実世界、つまり３次元空間には万物に平等の時間作用が
働いています。地球上にいるが為に、全世界の時間は時差があり
その結果、同じ地球上にいても全人類が世界の各所で同時に
同時刻を迎える事が出来ません。分かりやすくいうと全人類
同時に朝と夜は迎えられないということです。しかし、それは
地球上の話しで「宇宙空間にある地球」という見方をすれば、
地球に働いてる時間の流れは平等です。その時間の流れは
宇宙空間内であればどの星でも平等です。いわゆる「パルサー」
です。共通仮想空間はまさに宇宙そのものと同様の性質、
つまり各仮想世界に入るまでは、その共通仮想空間内ではどの
ユーザーにも同一の時間的概念の提供をしてみたいんです。
独自に自空間の時間的概念に流動性を持たせる事により、一つの
次元が完成されます。ユーザーはその共通仮想空間に入る事により
、同期と共に「同次元同時進行」がもたらされるんです。
私はこの様なリアルディメンジョン性を持たせたいんです。
例として、日本の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夜)。なにしよっか？」
てな感じに例えですが、地球上の国、人種を超えた同次元体験の
一例(予測)です。どうでしょうか？
それから言語に依存しないのはいいですね！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

181 ：
>>163
サーバ/クライアント的アプローチの場合、
メッセージ、または名前空間を管理する中央集権的方法を取るためになるので
それは仕方がないでしょう。
ドメイン運用にはお金かかってますよね？
サーバ運用だって無料じゃすまないし。
>>180
なにをしたいのかよくわからんのですが。
異る仮想世界を繋げるメリットは？
インターネット上でコミュニケーションを取る方法はいくらでもあるのに
それを仮想空間内で完結するメリットは？
キャラクター名でメッセージをやり取りしたいだけだったら、
会社が相当のメールアドレスでも提供すればいい。
最終的に何をどうしたいってのを明確にしないと
よくわからんまま終りますよ。
あなたはよくわかってないみたいだし、黙ってたほうがよろしいような。

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

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

184 ：
まー、このスレつぶれても別にいいんだけど…、あえて一言。
とりあえず、キャラクター間のメッセージ通信だけに絞っておやりなさい。
ゲーム間の貨幣交換とかいうのはその辺がしっかり確定してからでないと
ものになりません。
（もっともメッセージ交換と貨幣交換は全く別物なので、作ったものが
あとで役立つとは言えませんが。）

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

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

187 ：
>>184
はい　そのとおりだと思います。関係のない妄想未来予想は
未来技術板とかの別のスレッドでやる位でもいいと思います。
>>186
よくわからないんですがエイプリルフールにジョークRFCではない
RFCを出すということでしょうか？まさか日記形式のRFC？

188 ：
仕様からいくんじゃなくて、なにかサンプル実装をつくって、
それをもとに文書つくっっていったほうがはやいんじゃない？
改良点もあるとおもうけど、ますサンプル実装がないと、
なにを改善すればいいかもわからない
最初の実装は、打ち合わせとかじゃなくて、数人以下でとりあえず
作ってしまい、それからみんなでワイワイやって
改善したほうがはやいんじゃないかな？

189 ：
>>186
サンプルの例として違う種類のチャットAとチャットBを作って
チャットAの参加者がチャットBの参加者に向けてメッセージが送れる
というような形でもいいのでしょうか？
＞皆様
最初に実装を作るとしたらどんな形がいいか、書き込み
いただけないでしょうか？

190 ：
age

191 ：
http://pc.2ch.sc/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まで言ったらゲーム終了、ルール違反があると
再び挑戦になります。（藁
マターリとやりましょう！
＞くだらん。R
ブー！ブー！ブー！
まずは、ヒッキー板とLinux板、もう一つはどこか適当な場所を選びます。

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

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

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

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

196 ：
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です。

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

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

199 ：
>>198
様々な分野って、このスレが発散してしまっているのは、無闇に
いろいろなネタを、それがどんなものであるかを調べもせずに
言っているからです。ここでさらに発散させないでください。
メッセージ交換をどういうモデルで行いたいか、をしっかりまず
決めましょう。技術的な話はそれからで、使える既存技術があれば
それを応用すればよい。なければ作ればよい。
まだ他人のRFCを読むような段階ではない。
取りまとめ役はどっしりと！
ちなみにこういう話は、最初たたき台となる案をあらかじめを用意
しておいて、みんなに修正してもらう、という方がスムーズに軌道に
乗りますよ。

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

201 ：
>>200
とりあえず、IRC と既存の IM 技術が利用出来ないか、
出来ないとすれば何故出来ないかを調べてみては?
その上で、スレタイトルを*適切に*してからまた呼掛けたら違った結果になるかも。
ちなみに、会社が独占してうんぬん、ってのを言ってるけど、
貴方が言ってる意見はなんだか共感しにくいのが多いです。
何故かはよくわからないけど。
最後に。これからは sage で行きましょうや。

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

203 ：
>>202
すげ、もう勉強してきたんですか。
スレタイトルは、「オープンな Instant Messaging の規格を作ろう」
とかでいいんでないの？
それとそれと。
取り引きの方に関してなんだけど、
地域通貨の勉強したら結構面白いんじゃないかなと。
http://www3.plala.or.jp/mig/whats-jp.html
とりあえず、これを Web アプリケーション(って正しい用語か？)あたりで実
装したほうが楽しいような気がしないでもない。
通信技術とは違うけどね。どこが適当なんだろ、こういう話題は。

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

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

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

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

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




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


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

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

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

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

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

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


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

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

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



214 ：
sage

215 ：
こういうのはどうよ？(w
Meaning Of Naming Ascii art Protocol (MONA-P)
アスキーアートの名前付けの意味プロトコル (joke rfc)

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

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

218 ：
ちなみに他力本願です

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

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

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

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


221 ：
　補足すると、SOAP（シンプルオブジェクトアクセスプロトコル）
は、XML（エクステンシブルマークアップランゲージ）を用いてRPC
（リモートプロシジャコール）を実現する為の規格。
　悪名高きマイクロソフトのオブジェクトを、広く一般からも利用
して貰える様に再構成してあるので、Java等とも親和性が高く、色
んな可能性を秘めています。
　この規格に基いて幾つかの必須メソッドと拡張メソッドを規定し
て、>>161 を組み合わせれば、何とかなると思います。

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

223 ：
>>222
　これは、重要な問題です。
　ここを踏み誤ると、全然違う結果をもたらす事になります。
　今後の話題を何処に置くかが、これで決まります。
　意味をご理解頂けないのは、多分、>>222 さんが、予め用意され
ている教科書や問題集で知識を積んで居られるせいだと思います。
実務をなされば、きっとこの意味がお分かりいただけるでしょう。
　この点でスレッド主は、１年でも実務を経験しているので、きっ
と、ご理解頂けると思います。

224 ：
>>223
ドーイ

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

226 ：
････････････････！(・A・)！

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

228 ：
>>227
オマエモキモイ

229 ：
あげよう。

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

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

232 ：
IEEEはできたもよう。
http://www.watch.impress.co.jp/pc/docs/2002/0401/uocchi/802.htm
IEEEEE、ワイヤレス電源規格「802.110v」を制定

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

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


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

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

236 ：
とりあえずパールのソケット間通信クライアント。サーバーサイドは知らん
#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 $!;
}

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

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

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

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

242 ：
とりあえず>>1からだいたい読んでみた。>>1がやろうとしてるのは
TCP/IP Stack over TCP/IP Stackでもやってpseudo stackの
インフラをPhysical App Layerに設けようということでつか？
それとも仮想世界の規格を創ることでつか？それなら・・・

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

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

245 ：
この世界のこの人とあの世界のあの人が同一人物である、と
いうような情報は簡単に出回ってはいけない。
ネットストーカーの問題とか、どのサーバからクレジット番号
が漏れるかわからないとか、いろいろと危険な状況になる。
だから個人間の連絡方法としては、いわゆる転送電話方式で、
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さん。

246 ：
続き。
サーバとユーザの名前空間はDNS方式でよいと思います。
さて、ゲームサーバに対しても他のユーザに対してもエイリアス
を隠蔽しつつどうやって相手を捜索するか。
　ユーザYはゲームサーバBに別名リストのサーバ名部分だけ伝え
　ておく。
　ゆえに転送が発生するサーバBはどことどこのサーバに送れば
　いいかだけ知っている。
　転送側サーバBはあて先のユーザYの公開鍵で暗号化。あて先
　ユーザ名は破棄。
　受信側サーバC,D,…は受け取った通信ををそのとき接続していた
　全ユーザにブロードキャスト。
　本人だけが内容を解読して完了。
返事はどうしましょう。Cの￥がAのZに返事を書いていることが
（もちろんZに対しては隠蔽するけど）サーバCに知られるのも
どうかと思います。

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

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

249 ：
あ

250 ：
（＾＾）

251 ：
winnyのプロトコルをinformational RFCにすることは可能
問題はwinnyってプロトコル非公開の信用できないものなんだろ？

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

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

255 ：
負けじと実装しますた。
http://news.gw.com/netbsd.source.changes/139087

256 ：
>>251
winnyはユーザが信用できないのでプロトコル非公開になっていますが、
アーキテクチャ的に匿名性を非公開に依存してる訳じゃないです。

257 ：
（＾＾）

259 ：
>>256
どうしてユーザが信用できないのでプロトコル非公開なの？
プロトコル非公開なものは絶対に悪だっていう原則からすると？

262 ：
>>259
ダウソ板という背景とWinnyに対する攻撃を考えれば容易に見えるかと。
ソースをごく一部だけ書き換えるだけで送信量を制限できたりすると、
ネットワーク全体の不利益につながるので、それを「しにくく」している、というだけ。
ダウンロードできるんなら少しくらい資源を提供してもいいじゃん、と思うなかれ。
ダウソ板というはそういう場所だと思ってくだちぃ。

265 ：
　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

267 ：
<やること>
　・ネットゲーム間に同一実装の会話システムをつくること
　・その会話システムは近接したキャラクターとの会話とは別物
　・同一ゲーム間の電話の様なものとしてUIが与えられる
　・同一ネットゲームでユーザーを一意に識別できるIDをつける(user-id)
　　（これはネットゲーム間で同一実装）
　・ネットゲームを一意に特定できるIDをつける(world-id)
　・world-id＋user-idでキャラクターを一意に特定できる。
　・２つのネットゲーム間で会話可能にする
<その方法>
　・Msnメッセンジャーライクなソフトウェアを内部に持つ
　・URIを考案する
　・XMLベースのメッセージ交換(後にデータ転送を主眼に入れる場合)
　・ウニコード
　・1の猛勉強

268 ：
もｙぐ

269 ：
なんか面白そうなんでちょっとだけ覗いてみたけど、
>>267のまとめの通りだとするとお前らが考えていることは全てSIPで
実現できることばっかだな。MSNメッセは今はSIPベースだし。
RFC3261とその周辺のドラフト読んでみ。


270 ：
STDってのがつらいな
ジョークRFCなら何とかできそうなのに。。。

271 ：
>>19でPHIの話題が出てたから見に着てみたんすけど
既にあんまり関係なさそうなので生暖かく見守らせてもらいます。

272 ：
リア工房だからよくわからんけど
UOのお金でFFのアイテムを買ったりとか？
ようするに現在の株や外貨みたいに一箇所で取引できるようにするって感じ？

273 ：
FF１１のチートの方法知りたいです

274 ：
RFCで定義してもらえバカ。二度と現れるな

275 ：
a

276 ：
検索で飛んできました。
地域通貨に興味を持ってるんですが・・・ここはもう廃棄された
スレなんでしょうか？ だいたい、検索で来たんで、どの板かすら
わからんのですが・・・。

277 ：
だめだ・・・こんな理系の板だったのか〜。
すいません・・・どっか他に地域通貨のスレないですか〜？

278 ：
経済板と地方自治知事板にあるよ＞地域通貨
本文検索よりはスレタイ検索。
地域通貨といえば
http://www.hotwired.co.jp/altbiz/yamagata/010918/
なんて記事を思い出す。

279 ：
著作権がらみの話って誰もしてないようだけど、そのへんは大丈夫なの？
勝手にそういうことしてたらメーカー側が黙ってないと思うんだが。

280 ：
RFC（STD）って何の略？

281 ：
１はﾊﾞ━━━ヾ(｡´囗｀)ﾉ━━━ｶじゃないか
１にレスするやつも同じﾊﾞ━━━ヾ(｡´囗｀)ﾉ━━━ｶだ。

282 ：
>>276 >>277
地域通貨、いいセンスしてるね。
これは地域通貨自体のプロトコル標準化を行なって、standard RFCにするチャンス。

283 ：
Web6.0の仕様などをStandards Trackに載せるべく皆で頑張っていきたいと思います。
具体的にInternet Draftを出す前に、まずはbrainstormingから始めたいと思います。
皆さんの自由な御意見や質疑をお願いします。

284 ：
DNA交換プロトコルとかはWeb6.0の一部になるんだろ

285 ：
2chの各仕様を、informational RFCとして出すのはどうよ？

286 ：
つーか、これはRFCの枠を超えてると思うんだが。
ネトゲ内での内規と、運営各社での取り決めが無ければ成立しないし。
ただデータのやり取りをする部分だけがRFCでできるところだろ。
そしてそんなものを決めても無意味。

287 ：
もうジョークRFC作ろうぜ

288 ：
ジョークネタすら集まらないのか。
暇つぶしにネタ提供。
日本人のRFC貢献ランキング。
http://www.arkko.com/tools/allstats/japan.html

289 ：
うぉ2002年のスレかｗ
ツッコミレスしかけたぜｗ

290 ：
前レスから1年以上かｗ
何か出来たのか？

291 ：
>>280
レスないな

292 ：
あらゆるE-mail欄に"sage"と書くことについてコメントを募集したい。
2chのE-mail欄に"sage"と書くことはもちろん、メールのヘッダのReply-toなど
にも"sage"と書くことを標準の礼儀としたい。

293 ：
　　　　　　　　　　　　 　 r''"''ｰ-,,_
　　　　　　　　　　　　　 　 |　　　 　 "''ｰ──‐---''ヽ
　　　　　　　　　　　　　 　 |　　　　　　　　　　　　　 /
　　　　　　　　　　　　　 　 |　　　　　　　 　 　 　 　 |
　　　 　 　 　 ､--───‐ﾉ''ｰ-,,,_　　　　　　 　 　 |
　　　　　　　　 `ヽ　　　　 ＼　　　"'''ｰ-,,,_　　　　　|
　　　 　 　 　 　 　 ＼　　 　 ＼ 　 　 　 　"''''ー--┤
　　　 　 　 　 　 　 ／＼　　　　"'''-,,,__　　　　　 　 |
　　 　 　 　 　 　 /　　r‐＼　　　　　　 "'''ｰ‐-.,,,__　|､
　　　　　　　 　 /　　 ||,-`| ＼　　　　　　　　　　　"` ＼
　　 　 　 　 　 /　 　 ヽYi |　 /`-,,_　 　 　 　 　 　 　 　 ＼
　　　　　　　　|　　　　 ＼ |　|　　　"''ー-,,,＿　　　　　　　 ＼
　　 　 　 　 　 |　　 　 　 ‖ |　　　　　　　　　|"'''''┬--,,,＿　 ＼
　　　　　　　　 |　　　　　 |　 |　　　　 　 　 　 ﾞ､ 　 | 　 　 　 `ｰ-'
　　　　 　 　 　 |　　　 　 | 　 ﾞ､　　 ､　 　 　 　 >　|
　　　　　　　　　ﾞ､ 　 　 /|　　,､ﾞ､　　`ｰ- .,__　 　 /　　　　　　　
　　　　　　　　 　 ,へ　/ ﾉ,イ二ヽ､　　 　 ‐-￣　/　　　　　　＜　
　 　 　 　 　 　 ノ 　 `''y''i|.r''⌒ヽヽヽ-､ 　 人,,,/､　　　　　　　
　　　　_,,,-‐'''"＼　 r'"‖| |　　　| |　 　 ﾞ''"　　　 ﾞ､
　　　/　　 　 ,,--`-|| .（l| ゝ`ｰ‐' ,人-.,,_　　　　　　 ＼
　 　 |　 　 ／　　　 ||）　rヽ､ﾞ､｡/　　ﾞ､　"''ヽ､ ､　　__　"''-,,_
　　 .|　 ／　　 ,-─iﾞ､ヽ `''`i! ||､　　　ﾞ､.　|　｀ゞ`=i-"､`￣
　　 |　 |　 　 /　　/ﾄ､`Tヽ<||‖ ＼　　 ﾞ､|､　 　 　|　 ﾞ､　＼
　　 |　 |　　/　　 / | `‐`r､ ﾞi!()ｰ‐--､ 　 ﾞ､ヽ､　 　|　　ﾞ､ 　 ＼
　　 |　 ﾞ､| /　r''""￣￣￣￣| |"'''ヽ､_ヽ　 ﾞ､　Y二|ﾞ､ 　 ﾞ､ 　 /|
　　 .|　 / |　/　　 ､.＿＿＿_|_|,,_　 　 )）　　 ﾞ､〈 ‐->|　 　 ﾞ､ / |
　　　|　ﾞ､.　 〉　　 ´￣￣￣￣￣""ヽ´　　 　 ﾞ､|　　||　　 　/　 |
　　　.|　 |ﾞ､. 〉　　　　　　　　　　　 _丿 　 　 　 ﾞi 　 ‖ 　 /　　 |

294 ：
　　　　　　　　　　　　 　 r''"''ｰ-,,_
　　　　　　　　　　　　　 　 |　　　 　 "''ｰ──‐---''ヽ
　　　　　　　　　　　　　 　 |　　　　　　　　　　　　　 /
　　　　　　　　　　　　　 　 |　　　　　　　 　 　 　 　 |
　　　 　 　 　 ､--───‐ﾉ''ｰ-,,,_　　　　　　 　 　 |
　　　　　　　　 `ヽ　　　　 ＼　　　"'''ｰ-,,,_　　　　　|
　　　 　 　 　 　 　 ＼　　 　 ＼ 　 　 　 　"''''ー--┤
　　　 　 　 　 　 　 ／＼　　　　"'''-,,,__　　　　　 　 |
　　 　 　 　 　 　 /　　r‐＼　　　　　　 "'''ｰ‐-.,,,__　|､
　　　　　　　 　 /　　 ||,-`| ＼　　　　　　　　　　　"` ＼
　　 　 　 　 　 /　 　 ヽYi |　 /`-,,_　 　 　 　 　 　 　 　 ＼
　　　　　　　　|　　　　 ＼ |　|　　　"''ー-,,,＿　　　　　　　 ＼
　　 　 　 　 　 |　　 　 　 ‖ |　　　　　　　　　|"'''''┬--,,,＿　 ＼
　　　　　　　　 |　　　　　 |　 |　　　　 　 　 　 ﾞ､ 　 | 　 　 　 `ｰ-'
　　　　 　 　 　 |　　　 　 | 　 ﾞ､　　 ､　 　 　 　 >　|
　　　　　　　　　ﾞ､ 　 　 /|　　,､ﾞ､　　`ｰ- .,__　 　 /　　　　　　　
　　　　　　　　 　 ,へ　/ ﾉ,イ二ヽ､　　 　 ‐-￣　/　　　　　　＜　
　 　 　 　 　 　 ノ 　 `''y''i|.r''⌒ヽヽヽ-､ 　 人,,,/､　　　　　　　
　　　　_,,,-‐'''"＼　 r'"‖| |　　　| |　 　 ﾞ''"　　　 ﾞ､
　　　/　　 　 ,,--`-|| .（l| ゝ`ｰ‐' ,人-.,,_　　　　　　 ＼
　 　 |　 　 ／　　　 ||）　rヽ､ﾞ､｡/　　ﾞ､　"''ヽ､ ､　　__　"''-,,_
　　 .|　 ／　　 ,-─iﾞ､ヽ `''`i! ||､　　　ﾞ､.　|　｀ゞ`=i-"､`￣
　　 |　 |　 　 /　　/ﾄ､`Tヽ<||‖ ＼　　 ﾞ､|､　 　 　|　 ﾞ､　＼
　　 |　 |　　/　　 / | `‐`r､ ﾞi!()ｰ‐--､ 　 ﾞ､ヽ､　 　|　　ﾞ､ 　 ＼
　　 |　 ﾞ､| /　r''""￣￣￣￣| |"'''ヽ､_ヽ　 ﾞ､　Y二|ﾞ､ 　 ﾞ､ 　 /|
　　 .|　 / |　/　　 ､.＿＿＿_|_|,,_　 　 )）　　 ﾞ､〈 ‐->|　 　 ﾞ､ / |
　　　|　ﾞ､.　 〉　　 ´￣￣￣￣￣""ヽ´　　 　 ﾞ､|　　||　　 　/　 |
　　　.|　 |ﾞ､. 〉　　　　　　　　　　　 _丿 　 　 　 ﾞi 　 ‖ 　 /　　 |

295 ：
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

296 ：2018/05/21
ユニークで個性的な嘘みたいに金の生る木を作れる方法
興味がある人はどうぞ
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

4792G

ルーターで音声チャット
自宅サーバー構築中
Foundryについて語ってくれなスレ
　　ATM技術って将来性あるの？　　
NTTの電波塔からは何が出てるの？
住民基本台帳ネットワーク(住基ネット)ってどうよ？
【3hop目】JANOG ML をマターリと観察する人の数 →
ISDNルータをADSLに利用したい
ＮＥＣ系装置勉強会(MM-Node,IP45,ATOMIS　etc)
フレッツグループについて
--------------------
３５超えて急にパートナーが欲しくなった、たすけて [886034557]
【速報】千葉、一部水止まる
【乃木坂46】鈴木絢音応援ｽﾚ☆62便【あやねちゃん】
「消費税10％で未来永劫大丈夫というのは危険。さらに引き上げるべき」…経済同友会の発言に怒りの声「なんで法人税上げないの？」★3
ドケチの断捨離
十文字青 総合スレ68
カラテカ入江　一部メディアに法的措置を取ることに　反社とは関係ない
Painter総合 63筆目【ペインター】
【新型肺炎】「マスク値下げしました。中国頑張れ」日本のPOP、中国SNSで話題…「感動。泣きそう」「日本人にも良心のある人がいる」 ★2
【第100回】大阪桐蔭 対 済美 【準決勝】
【仙台潰し】 ヴィクトリーナ姫路 Part4 【ベルフィーユ乗っ取り】
＜民主党？＞2008年大統領選挙<共和党？＞
☆　祝　★　4号機の燃料回収完了！！
◇◇チラシの裏 404枚目◇◇
女子高生×バイク！「ばくおん!!」　その209
サウスパークに逝こうぜ！62
【旧U】三菱UFJ信託被害者の会【徹底追及】
ファンシー系・キャラクター系文房具総合スレ
豚はこのタイミングでモンハンがフリプに来る意味を考えろ
今年の阪神はやらかす19-660
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼