kahvi:

coffee: URL scheme

[1] coffee: その他は、 HTCPCP に対応する URL scheme です。

仕様書

意味

[24] coffee: その他の URL schemeHTCPCP を表します。

[25] HTCPCP-TEAURL scheme は明記されていませんが、 HTCPCP から特に変更はなく同じ URL scheme 群を共有しているものと思われます。

構文

[10] HTCPCPURLURL schemeホスト、ポット指示子、 添加物リストで構成されます。 URL scheme の後には : を置きます。ホスト、ポット指示子、添加物リストは省略可能です。 省略しない場合はそれぞれの前に ///? を置きます。 >>2

  1. URL scheme
  2. :
  3. ?
    1. //
    2. ホスト
  4. ?
    1. /
    2. ポット指示子
  5. ?
    1. ?
    2. 添加物リスト
[11] RFC 2324素片識別子を構文上明示していませんが、 URL scheme に依存する部分のみ示しており、除外する意図は無いと思われます。 (この時代の URL の仕様では素片識別子URI の一部とはされていませんでした。)
[12] authorityuserinfoポートは含まれていないようです。

URL scheme

[3] RFC 2324国際化と称して次の (同じ意味の) URL scheme を規定しています >>2

[5] ただしRFC正誤表では caf%C3%E8:caf%C3%E9: の誤りと報告されています >>3

[6] RFC 23244月1日に発行された RFC であり、 ネタにマジレスするのも野暮ですが、

[13] URL scheme の違いは、珈琲の種類の決定に反映させても構いません >>2

[18] これらの URL schemeIANA登録簿にはなぜか登録されていません。

パス

[14] パス部にはポット指示子を指定できます。これは pot- のあとに整数を指定するもので、複数のポットがある場合にそれを識別するために使うことができます >>2pot-大文字・小文字不区別>>2、明記されていませんがどちらでも同じ意味と思われます。明記されていませんが整数ASCII数字の1つ以上の列を指すと推測されます。

[21] HTCPCP-TEA ではパスはポットだけでなく、ティーバッグ茶葉も指定できるように拡張されているようです >>20。ただしその構文は明記されていません。

[22] 次のようなパスが例示されています >>20

[23] /HTCPCP>>22HTCPCP-TEA のように一つので混在させることもできるようです >>20

/

[26] / への message/coffeepot 要求に対する応答Alternates: ヘッダーを含むべきです >>20

message/coffeepot も参照。

[27] / への message/teapot 要求に対する応答Alternates: ヘッダーを含まなければなりません >>20。 茶はまだ沸かしません。

[29] Alternates: ヘッダーを送信する (茶を沸かしていない) 応答状態符号 300 を使うべきです >>28

query

[15] query 部分には添加物のリストを指定できます >>2

[16] HTTP におけるリストの構文である # を使って定義されていますが >>2URL では空白をそのまま使うことはできませんから、空白は禁止されると解釈するべきでしょうか。あるいはパーセント符号化すれば空白, の前後に挿入できると解釈するべきでしょうか。

[17] 添加物として何を指定できるのかは明記されてません。 Accept-Additions: ヘッダーで指定できる種別とも推測されますが、はっきりしていません。

相対 URL

[19] HTCPCP-TEAAlternates: ヘッダー相対URL (絶対パス) を使った例が示されています >>20