読者です 読者をやめる 読者になる 読者になる

( ꒪⌓꒪) ゆるよろ日記

( ゚∀゚)o彡°オパーイ!オパーイ! ( ;゚皿゚)ノシΣ フィンギィィーーッ!!!

ハイパーおちんちんタイム転送プロトコル 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 ̄|  おちんちんランド開園だよー
        ::| | |二 /⌒ヽ
        ::| | |д(ω^ )
        ::| | 〔: 〕と  ヽ
        └┴[__]‐し―J

         _____
        ::| |l´ ̄ ̄ ̄`l
        ::| ||¶     |
        ::| ||______|
        ::| |┌──..l´ll  乗り込めー
        ::| | | ⌒ヽ | |¶
        ::| | |(^/⌒`| ||   д д
        ::| | |_(__|д .д〔д〔: 〕
        └┴‐――‐〔: 〕〔: д: 〕__]
                [__] [_〔: 〕]
         _____    [__]
        ::| |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)