[1] coffee: その他は、 HTCPCP に対応する
URL scheme です。
[24] coffee: その他の URL scheme は HTCPCP
を表します。
[25] HTCPCP-TEA の URL scheme は明記されていませんが、 HTCPCP から特に変更はなく同じ URL scheme 群を共有しているものと思われます。
[10] HTCPCP の URL は URL scheme、ホスト、ポット指示子、
添加物リストで構成されます。 URL scheme の後には :
を置きます。ホスト、ポット指示子、添加物リストは省略可能です。
省略しない場合はそれぞれの前に //、/、
? を置きます。 >>2
[3] RFC 2324 は国際化と称して次の (同じ意味の) URL scheme を規定しています >>2。
koffie:q%C3%A6hv%C3%A6:%D9%82%D9%87%D9%88%D8%A9:akeita:koffee:kahva:kafe:caf%C3%E8:%E5%92%96%E5%95%A1:kava:k%C3%A1va:kaffe:coffee:kafo:kohv:kahvi:%4Baffee:%CE%BA%CE%B1%CF%86%CE%AD:%E0%A4%95%E0%A5%8C%E0%A4%AB%E0%A5%80:%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC:%EC%BB%A4%ED%94%BC:%D0%BA%D0%BE%D1%84%D0%B5:%E0%B8%81%E0%B8%B2%E0%B9%81%E0%B8%9F:[5] ただしRFC正誤表では caf%C3%E8: は
caf%C3%E9: の誤りと報告されています >>3。
[6] RFC 2324 は4月1日に発行された RFC であり、
ネタにマジレスするのも野暮ですが、% を使う URL scheme はすべて構文上正しい URL には使えません。K を
パーセント符号化して %4B としていますが、 (仮にパーセント符号化を許容するとしても)
非予約文字はパーセント符号化してもしなくても等価とされており、
従って K と等価なので、正規化により小文字に変換されるおそれがあります。
パーセント符号化しても小文字への正規化の防止にはなりません。
[13] URL scheme の違いは、珈琲の種類の決定に反映させても構いません >>2。
[18] これらの URL scheme は IANA登録簿にはなぜか登録されていません。
[14] パス部にはポット指示子を指定できます。これは pot- のあとに整数を指定するもので、複数のポットがある場合にそれを識別するために使うことができます >>2。 pot- は大文字・小文字不区別で >>2、明記されていませんがどちらでも同じ意味と思われます。明記されていませんが整数は ASCII数字の1つ以上の列を指すと推測されます。
[21] HTCPCP-TEA ではパスはポットだけでなく、ティーバッグや茶葉も指定できるように拡張されているようです >>20。ただしその構文は明記されていません。
/[26] / への message/coffeepot 要求に対する応答は
Alternates: ヘッダーを含むべきです >>20。
message/coffeepot も参照。[27] / への message/teapot 要求に対する応答は
Alternates: ヘッダーを含まなければなりません >>20。
茶はまだ沸かしません。
[29] Alternates: ヘッダーを送信する (茶を沸かしていない)
応答は状態符号 300 を使うべきです >>28。
[15] query 部分には添加物のリストを指定できます >>2。
[16] HTTP におけるリストの構文である # を使って定義されていますが >>2、
URL では空白をそのまま使うことはできませんから、空白は禁止されると解釈するべきでしょうか。あるいはパーセント符号化すれば空白を ,
の前後に挿入できると解釈するべきでしょうか。
[17] 添加物として何を指定できるのかは明記されてません。 Accept-Additions:
ヘッダーで指定できる種別とも推測されますが、はっきりしていません。
[19] HTCPCP-TEA の Alternates: ヘッダーで相対URL
(絶対パス) を使った例が示されています >>20。