ハイパーおちんちんタイム転送プロトコル Hyper Otintin Time Transfer Protocol (HOTTP/1.0)
HTTPの勉強として、ジョークRFCを書いてみました。
ネタは相当に頭が悪く、真摯にWebに対して向き合っている方々には本当に申し訳なく思っており、反省しています。
ただ、こういう仕様を考えることで色々と勉強になりました。URIスキームとステータスコードはHTTPで代用できるのですが、ネタとして面白いので拡張しました。いちおう、実装可能な仕様になっていると思います。
Network Working Group Yuroyoro(T.Ozaki)
Request for Comments: xxxx 17 July 2010
Category: Informational
ハイパーおちんちんタイム転送プロトコル
Hyper Otintin Time Transfer Protocol (HOTTP/1.0)
このメモの位置づけ
このメモはインターネットコミュニティに情報を提供する。インターネッ
トの標準を規定するたぐいのものではない。このメモの配布は無制限であ
る。
著作権の表示
Copyright (C) yuroyoro - Tomohito Ozaki(2010). All Rights Reserved.
概要
この文書は HOTTP/1.0について記述する。このプロトコルはURI(Uniform
Resource Identifier)[RFC3986] によって表現されたリソースについて、
そのリソースのハイパーおちんちんタイムの状態を取得・更新するための
ものである。
1. 理論的根拠と適用範囲
インターネットにおけるアプリケーション・サービスの進化にともない、
特定のURIが示すリソースについての状態をHTTP/1.1[RFC2616]によって制
御する需要が拡大している。
このようなリソースに対しての制御は、REST(Representational State
Transfer )によるものが一般的だが、この文書ではより特定のリソースの
状態に特化した制御プロトコルについての提案を行うものである。
具体的には、URI によって表現されるリソースがハイパーおちんちんタイ
ムであるかを取得・更新するためのプロトコルとしてハイパーおちんちん
タイム転送プロトコル(HOTTP/1.0 (Hyper Otintintime Transfer
Protocol))をこの文書で規定した。
現代(2010年)におけるインターネットでは、URI で表現されたリソースが
特定個人を示す識別子(ID /identifier)である場合があり、リソースが個
人であれば、ハイパーおちんちんタイムである・ないという状態を持つは
ずである。
よって、この状態モデルをクライアント・サーバー間で制御・転送するた
めのプロトコルが必要となると予測される。
Yuroyoro Informational [Page 1]
RFC xxxx HOTTP/1.0 17 July 2010
HOTTP/1.0 では、リソースに対するハイパーおちんちんタイムに関する状
態を取得・更新するためのあらゆる要求と返答を許す。HOTTP というプロ
トコルの名前は、RESTにおける"リソースの状態を転送(transfer)する"と
いう考えにもとづき、"制御(control)"ではなく"転送(tranfer)"を採用し
たことによる。あと、スキームをなるべくHTTPに似た字面にしたかった、
という理由もあるしむしろこっちが本音である。
このプロトコルは、おそらく拡張もされないであろうし、将来の版が提案
されることもない、はずだ。
2. HOTTP プロトコル
HOTTP プロトコルは、いくつかの新しいステータスコードとヘッダフィー
ルドを加え、既存のヘッダーフィールドの意味を置き換えて、HTTPの上に
構築する。
あらゆる HOTTP サーバーは、URIスキームを "hottp:" により参照する
(Section 2.1.3)。または、URIスキームを"http:" とした場合は、リクエ
ストヘッダーフィールドにOtintintime-version フィールドが設定された
リクエストによって識別される。
そのため、HTTP/1.1 におけるプロトコルパラメータ
(RFC2616 (Section 3))のうちいくつかは、HOTTPにおいて修正される。
また、HOTTP プロトコルにおけるリクエストメソッドは、HTTP/1.1により
規定されるものの一部のみをサポートする(section 3.1)
その他の規定についてはHTTP/1.1に準ずるものとする。
2.1 HOTTP のバージョン
RFC2616(Section 3.1)において規定されるHTTPのバージョンは、HOTTP で
はHTTP-Version フィールドに以下の形式で指定する。
HTTP-Version = "HOTTP" "/" 1*DIGIT "." 1*DIGIT
実質的には、HOTTPリクエストにおいては"HOTTP/1.0"以外が指定されるこ
とはないであろう。
上記のリクエストラインの形式は、URIスキームが"hottp:" によって参照
される場合であり、"http:"によって参照される場合はHTTP/1.1に準ずる。
2.2 Uniform Resource Identifiers
HOTTP/1.0におけるURIは、特定の個人を意味し、ハイパーおちんちんタイ
ムという状態を持つべきリソースを意味するが、プロトコル上でURI が特
定個人に対する識別子であるかを指定しなくともよいし、サーバーは保証
する必要はない。
Yuroyoro Informational [Page 2]
RFC xxxx HOTTP/1.0 17 July 2010
2.3 HOTTP スキーム
RFC2616(3.2.2 http URL )に示される"http" スキームは、HOTTPにおいて
は"hottp"スキームとなる。従って、HOTTP URLは以下の構文で示される。
hottp_URL = "hottp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
もしportが空かあるいは与えられていなければ、ポート番号として8421が
仮定される。
8421は、いにしえのポケベル打ちで"おちんちん"と入力した場合のキーの
組み合わせである"お(15)ちん(4203)ちん(4203)"を加算したものである。
URIスキームが"http:"により参照される場合はこの限りではなくHTTP/1.0
に準ずるものである。
3 HOTTP のリクエストメソッドとレスポンス
HOTTP サーバーは、リソースのハイパーおちんちんタイムについての制御
要求をリクエストメソッドにより判断する。
HOTTP において規定されるリクエストメソッドは、HTTP/1.1により規定さ
れているOPTIONS/GET/HEAD/POST/PUT/DELETE/TRACE/CONNECTのうち、以下
のものである。
Method = "GET" ; Section 3.1
"POST" ; Section 3.2
"PUT" ; Section 3.3
"DELETE" ; Section 3.4
上記以外のHTTP/1.1リクエストメソッドについて、HOTTP サーバーはその
リクエストに対して 405(Method Not Allowed) を返すべきである。
HTTP/1.1で規定されていないメソッドに対しては、HOTTP サーバーはレス
ポンスとして 501(Not Implemented)を返すべきである。
3.1 GET メソッド
HTTP では、GET メソッドは「リクエストURIで指定されるどんな情報でも
(存在している形式で)検索する」という意味で使われるが、HOTTP におい
てはリソースのハイパーおちんちんタイムの状態を返すものである。
HOTTP GETリクエストは、基本的にはHTTP/1.1 GET リクエストと同じ形式
である。例として以下を示す。
GET /ozaki HOTTP/1.0
Host : example.com
Accept:text/html;q=0.9, text/plain;q=0.8, image/png, */*;q=0.5
Yuroyoro Informational [Page 3]
RFC xxxx HOTTP/1.0 17 July 2010
"http:"により参照される場合は、"Hottp-version"をヘッダーフィールド
にHOTTPバージョン(section 2)を指定し、以下の形式となる。
GET /ozaki HTTP/1.0
Host : example.com
Accept:text/html;q=0.9, text/plain;q=0.8, image/png, */*;q=0.5
Hottp-version: HOTTP/1.0
ステータスラインにおけるHTTP-versionフィールドは、リソースが参照さ
れるURIスキームと一致する。"http:"URIスキームであれば"HTTP/1.0" で
あり、"hottp:"URIスキームであれば"HOTTP/1.0"である。これはレスポン
スステータスラインも同様である。
HOTTP GET レスポンスは、新しく規定されたステータスコードにより、リ
ソースがハイパーおちんちんタイムに突入しているかを設定する。リソー
スがハイパーおちんちんタイムに突入している場合は 270
(Yeahoooooooooooo!!!)が設定される。
賢者モードの場合は 271 (Hu....)が設定される。
HOTTPサーバーは、同様にリソースの状態を表すために、"Otintin-time"
レスポンスヘッダーフィールドをレスポンスに含めるべきである。ハイパ
ーおちんちんタイム突入中であれば"Hyper" が設定され、賢者モードであ
れば"Wiseman" が設定される。値はステータスコードと一貫性をもって設
定されなければならない。
Otintin-time = ( "Hyper" | "Wiseman" )
また、ハイパーおちんちんタイムに突入している場合には、メッセージボ
ディにはテキストや画像などそのリソースのおちんちんタイムを表す内容
がAcceptヘッダーフィールドに応じて設定されることがあるし、なにも設
定されないこともある。例えば以下のようになる。
HOTTP/1.1 270 Yeahoooooooooooo!!!
Otintin-time: Hyper
Date: Fri, 15 Jul 2010 17:22:53 JST
Expires: Fri, 15 Jul 2010 18:00:00 JST
Content-Type: text/html; charset=UTF-8
<p>ｲﾔｯﾎｵｵｵｵｵｵｫｵｵｵｵｵｵ!!</p>
HOTTP レスポンスメッセージボディに設定される内容は、HTTP/1.1に準じ
たコンテントネゴシエーションにより決定されるべきである。リソースが
賢者モードの場合は、レスポンスメッセージボディになにも設定してはな
らない。
HOTTP レスポンスヘッダーフィールドでは、HTTP/1.1で規定されるヘッダ
ーフィールドの意味を変更しているものがある。
Yuroyoro Informational [Page 4]
RFC xxxx HOTTP/1.0 17 July 2010
Dateレスポンスヘッダーフィールドは、そのリソースがハイパーおちんち
んタイムに突入した時刻を示す。
Expires レスポンスヘッダーフィールドは、そのリソースがハイパーおち
んちんタイムを終了して賢者モードになる予定の時刻を示す。
3.2 POST メソッド
POST メソッドは、URIによって表現されるリソースの生成を指示する。
リクエストは、Otintin-timeヘッダーフィールドにより、生成されたあと
のリソースがハイパーおちんちんタイムであるか指定することができる。
Otintin-time ヘッダーフィールドが省略された場合は、"Wiseman"が設定
されているものと見なされる。"Hyper" が設定されている場合は、ヘッダ
ーフィールドにWiseman-dateヘッダーフィールドを指定することにより、
ハイパーおちんちんタイムが終了する日時を示す必要がある。
Wiseman-date = "Wiseman-date" ":" HTTP-date
またリクエストメッセージボディには、リソースのハイパーおちんちんタ
イムを表す内容を含めることができる。HOTTPサーバーは、POST/PUT メソ
ッドで送信されたメッセージボディの内容を以降のGET リクエストに対す
るメッセージボディに設定しなければならない。
HOTTP サーバーは、リソースのハイパーおちんちんタイムを表す内容とし
て、Content-type毎にPOST/PUTメソッドで送信されたメッセージボディの
内容を複数保持する。
保持する内容は、PUT リクエストを受信するたびにContent-type毎に追加
される。
つまり、最初のPOSTメソッドでContent-type: text/plan であるメッセー
ジボディが送信され、次にPUTメソッドでContent-type: image/jpgである
メッセージボディを受け取り、三番目のPUT でContent-type:text を受け
取った場合は、HOTTP サーバーはAccept: text/* のGETリクエストに対し
て最初か三番目のPUT リクエストで受け取った内容を返さねばならない。
このときに、最初から三番目かどちらの内容を返すかはHOTTP サーバーが
任意に選択してよいし、本文書ではその方式を規定しない( ランダムに返
すか、ローテーションして返すか、など)。そして、Accept:image/* に対
しては二番目のPUTメソッドで受け取った内容を返さなければならない。
HOTTP サーバーが対応するContent-typeを保持していない場合は、単純に
なにもメッセージボディを返す必要は無い。
リクエストメッセージボディの内容には、"multipart/form-data" タイプ
を許可するが、それ以外のマルチパートタイプは許可しない。
Yuroyoro Informational [Page 5]
RFC xxxx HOTTP/1.0 17 July 2010
HOTTP サーバーは、リクエストメッセージボディが省略された場合に、そ
のリソースのハイパーおちんちんタイム状態を表す初期状態を複数設定し
てよい。たとえば、以下のようにいかにもハイパーおちんちんタイムであ
るような文字列を初期状態として持つことが望ましい。
Content-type: text/plain
::| |l´￣￣￣｀l
::| ||¶ |
::| ||＿＿＿___|
::| |┌─‐l'l￣| おちんちんランド開園だよー
::| | |二 /⌒ヽ
::| | |д(ω＾ ）
::| | 〔: 〕と ヽ
└┴[__]‐し―Ｊ
＿＿＿＿_
::| |l´￣￣￣｀l
::| ||¶ |
::| ||＿＿＿___|
::| |┌──..l´lｌ 乗り込めー
::| | | ⌒ヽ | |¶
::| | |(＾/⌒｀| || д д
::| | |_（＿＿|д .д〔д〔: 〕
└┴‐――‐〔: 〕〔: д: 〕__]
[__] [_〔: 〕]
＿＿＿＿_ [__]
::| |l´￣￣￣｀l
::| ||¶ |
::| ||＿＿＿___|
::| |l´￣￣￣｀l ﾊﾟﾀﾝ…
::| ||¶ |
::| || .| д д
::| ||＿＿＿__д .д〔д〔: 〕
└┴‐――‐.〔: 〕〔 ﾟдﾟ 〕__]
.[__] [_〔: 〕]
[__]
ハイパーおちんちんタイムを表現する望ましい内容については、下記を参
照するとよい。
http://slpy.blog65.fc2.com/blog-entry-1570.html
POSTリクエストに対するレスポンスは、ハイパーおちんちんタイムに突入
できた場合は 272 (Otintin Land Has Opened)を返す。POSTリクエストを
受信した時点ですでにリソースが生成されているならば、 471 (Otintin
Conflict)を返し、リソースの状態を更新してはならない。
Yuroyoro Informational [Page 6]
RFC xxxx HOTTP/1.0 17 July 2010
POSTメソッドは、PUT/DELETEメソッドを発行できないクライアントを考慮
しPUT/DELETEメソッドの代わりに利用することができる。そのため、POST
リクエストには、新しくHOTTPで規定されたOtintin-commandヘッダーフィ
ールドにより、PUT またはDELETEのどちらかのメソッドの代わりであるか
を示すことができる。
Otintin-command = ( "PUT" | "DELETE" )
Otintin-command が省略された場合は、上述のPOSTメソッドであると解釈
される。
3.3 PUT メソッド
PUT メソッドはURI で示されるリソースがハイパーおちんちんタイムを開
始することを要求する。または、リソースが保持するハイパーおちんちん
タイム突入中を表す内容の更新を指示する。
PUT リクエストは、ヘッダーフィールドにWiseman-dateヘッダーフィール
ドを指定することにより、ハイパーおちんちんタイムが終了する日時の更
新を指示することができる。
リクエストメッセージボディには、リソースのハイパーおちんちんタイム
状態を表す内容を設定することができる。HOTTP サーバーが、すでに対応
するContent-typeの内容を保持している場合はその内容を更新する。
PUT リクエストメッセージボディの内容も、POSTリクエストメッセージボ
ディと同様に"multipart/form-data" タイプを許可するが、それ以外のマ
ルチパートタイプは許可しない。"multipart/form-data" タイプを送信さ
れた場合は、対応するContent-typeが無ければ追加し、保持していれば更
新するようにしなければならない。
PUT リクエストをサーバーが受け取った時点ですでにハイパーおちんちん
タイムが開始されている場合は、Wiseman-Dateヘッダーフィールドの内容
でリソースが賢者タイムにもどる時刻を更新しなければならない。
また、レスポンスヘッダーフィールドには、Otintin-timeヘッダーフィー
ルド、DateヘッダーフィールドおよびExpires ヘッダーフィールドを含む
べきである。
レスポンスメッセージボディには、そのリソースがハイパーおちんちんタ
イムに突入したことを示す内容を含んでもよい。GET リクエストに対する
メッセージボディと同じ内容を設定することもできる。
3.4 DELETE メソッド
DELETE メソッドにより、URIで示されるリソースがハイパーおちんちんタ
イムを終了して賢者タイムに戻ることを要求する。または、リソースに紐
付けされているのハイパーおちんちんタイムの状態を表す内容の削除を要
求する。
Yuroyoro Informational [Page 7]
RFC xxxx HOTTP/1.0 17 July 2010
DELETEメソッドのメッセージボディが設定されていない場合、リソースは
ハイパーおちんちんタイムは終了し、賢者モードに入る。この場合は、レ
スポンスとして273 (Otintin Land Has Closed)を返す。ただしDELETE メ
ソッドを受け取った時点で賢者モードならば、レスポンスとして204 (No
Content)を返す。
DELETEメソッドにメッセージボディが設定されている場合は、保持してい
るハイパーおちんちんタイムの状態をあらわす内容から、メッセージボデ
ィに一致するものを削除する。対応するリソースが存在し削除された場合
は270 (Yeahoooooooooooo!!!)を返し、一致するものがない場合は204 (No
Content)が返される。
4 追加されたステータスコード
HOTTP/1.0 におけるステータスコードは、リソースのハイパーおちんちん
タイム状態と制御に対する結果を表す。よって、HTTP/1.1にいくつかの拡
張を行っている。
4.1 270 Yeahoooooooooooo!!! (イヤッホホホホッホオオオオオオオオオ!!)
リソースがハイパーおちんちんタイム突入中である場合に戻される。
4.2 271 Hu.... (ふぅ…。)
リソースが賢者モードである場合に戻される。
4.3 272 Otintin Land Has Opened (おちんちんランド開園だよー)
リソースがハイパーおちんちんタイムに突入できた場合に返される。
4.4 273 Otintin Land Has Closed(おちんちんラン閉園だお)
DELETEメソッドによりリソースが賢者モードにもどった場合に返される。
4.5 470 Bad Otintin Time (おちんちんタイム終わってるよ)
POST/PUTリクエストで指定されたOtintin-timeフィールドの時刻が過去
の時刻を指定している場合に返される。
4.7 471 Otintin Conflict (おちんちんバトル)
POSTリクエストにより生成を指示されたリソースがすでに生成されてい
る場合にかえされる。
4.8 472 Otintin Time Required (おちんちんタイム教えて)
POSTリクエストにOtintin-time フィールドが含まれていない場合、または
HTTP-date形式に準じない時刻が指定された場合に返される。
Yuroyoro Informational [Page 8]
RFC xxxx HOTTP/1.0 17 July 2010
4.9 473 Otintin Time Too Long (そんなに長い時間おちんちんできないお)
HOTTPサーバーが、対象のリソースが指定されたOtintin-timeまで耐えるこ
とができないと判断した場合に返される。
4.10 474 Otintin Not Found (おちんちんついてないお…)
URIで指定されたリソースが存在しない、またはおちんちんがついていない
場合に設定される。
5. 謝辞
こんなネタにつきあってくれた全ての人へ、深く感謝します。
6. 参考文献
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068,
January 1997.
[RFC3986] T.Berners-Lee, R.Fielding, L. Masinter, "Uniform Resource
Identifier (URI): Generic Syntax" RFC 3986, January 2005.
[RFC2186] Wessels, D., and K. Claffy, "Internet Cache Protocol (ICP),
version 2," RFC 2186, September 1997
10. 著者の連絡先
yuroyoro (Tomohito Ozaki)
EMail: ozaki@yuroyoro.com
Ozaki Informational [Page 9]
RFC xxxx HOTTP/1.0 17 July 2010
6. 著作権について
Copyright (C) yuroyoro - Tomohito Ozaki(2010). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
Japanese.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Ozaki Informational [Page 10]ハイパーおちんちんタイム転送プロトコル Hyper Otintin Time Transfer Protocol (HOTTP/1.0)
