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

1 ：02/01/06 〜 最終レス ：8)

インターネット上に何百という数の仮想世界が存在します。
例えば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.net/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.net/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作りたいなら、
せめて「コメントをリクエスト」できるような叩き台を提示しないか？

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

　　　　ADSL速度と局からの距離　　　　。　　 (583)
ネットワークエンジニアの定番ノートPCは？ (440)
NTTへの文句で1000を目指すスレ。 (874)
　　　　ADSL速度と局からの距離　　　　。　　 (583)
SNMPについて語るスレ (271)
★ＬＡＮカードのチップについて語る★ (783)
--log9.info------------------
ヾ(*´∀`*)ﾉ ｷｬｯｷｬｯ♪ (534)
女が嫌いで嫌いで殺したい (315)
アフリカで仕事してるけど質問ある？ (282)
(｀･ω･´)スナイパー (305)
VIPPER+アイドルしょこたんこと中川翔子さんと愉快な仲間たち。 (402)
ここだけみんな紳士。コンマ00でエロ大爆発　その２ (504)
他人の気持ちがわからない (338)
名前欄に!RでRした回数がわかってしまうwwwwww (678)
妹や姉とのやりとり晒してけ (596)
当方ラバーフェチですが、皆様のご質問にご回答申し上げます (410)
No1ソープ嬢を嫁にした話 (883)
俺の人生エロい話多すぎワロタｗｗｗｗｗｗｗ (251)
気持ち事がいい大好きだった私の話 (957)
おそらく周りで自分しか聴いていないであろうミュージシャン挙げて毛 (302)
河童だけれども、何か質問のある人間はいないかな？ (699)
最寄り駅晒してかぶったら一緒に遊びに行くスレ (301)
--log55.com------------------
【BEMANI】音ゲーで同人40【セガ、バンナム、タイトーetc.】
【一次創作気取り】うちの子厨アンチスレ16【チートオリキャラ】
【ゼッケン屋】待たせたな！石鹸屋だ！【インフェクテッド】 Part33
同人やめる時、やめたい時　4
原作未読やエアプの同人者が苦手★２
ナマモノ同人3
「腐女子狙い」厨がウザイ29
【コスプレ(笑)】コスプレだけは理解出来ない！59【アンチ】