Independent Submission I. Nazar Request for Comments: 7168 1 April 2014 Updates: 2324 Category: Informational ISSN: 2070-1721 お茶を煎れる機器のためのハイパーテキストコーヒーポット制御プロトコル(HTCPCP-TEA) 概要 コーヒーポット制御プロトコル(HTCPCP)の仕様はその多様性と複雑さからお茶を煎れることができません。 本論文ではHTCPCPを拡張してポットにネットワーク化されたお茶を煎れる機器について説明します。 このメモの位置付け この文書では、インターネット標準化過程の仕様ではありません、それは情報目的のために公開されています。 これは、他のいかなるRFCストリームに関係なく、RFCシリーズに貢献をしています。 RFC Editor は自らの裁量でこのドキュメントを公開することを選択しました。そして、実装や展開においてのその価値に関して何らかの声明を出すことはありません。 RFC Editorによって公表の承認をされたドキュメントはインターネット標準のいかなるレベルの候補でもありません。RFC5714のセクション2を見てください。 このドキュメントの現在の状況、正誤表、フィードバックの提供の仕方の情報については、http://www.rfc-editor.org/info/rfc7168 で得られるでしょう。 http://www.rfc-editor.org/info/rfc7168. 著作権 Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) の適用を受けます。 それらにこの文章に関する権利と制限が記述されていますので、慎重にこれらの文章を確認してください。 目次 1. はじめに. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. 用語. . . . . . . . . . . . . . . . . . . . . . . . 3 2. HTCPCP-TEA プロトコルアディション. . . . . . . . . . . . . . . . 3 2.1. BREW とPOST メソッド. . . . . . . . . . . . . . . . . . 3 2.1.1. The "/" URI . . . . . . . . . . . . . . . . . . . . . . 3 2.1.2. Variety-Specific URIs . . . . . . . . . . . . . . . . . 4 2.2. Modified Header Fields . . . . . . . . . . . . . . . . . . 4 2.2.1. Accept-Additions ヘッダ フィールド. . . . . . . . . . . 4 2.3. 応答コード. . . . . . . . . . . . . . . . . . . . . . 5 2.3.1. 300 Multiple Options. . . . . . . . . . . . . . . . 5 2.3.2. 403 Forbidden . . . . . . . . . . . . . . . . . . . . . 5 2.3.3. 418 I'm a Teapot . . . . . . . . . . . . . . . . . . . 5 3. The "message/teapot" Media Type . . . . . . . . . . . . . . . . 6 4. 環境の問題. . . . . . . . . . . . . . . . 6 5. セキュリティ問題. . . . . . . . . . . . . . . . . . . 6 6. 謝辞. . . . . . . . . . . . . . . . . . . . . . 7 7. 参照. . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. 標準の表記. . . . . . . . . . . . . . . . . . 7 7.2. 引用. . . . . . . . . . . . . . . . . 7 1. はじめに Hyper Text Coffee Pot Control Protocol [HTCPCP] で述べられているように、コーヒーは巧みに醸造されたカフェイン飲料として世界的に有名なものですが、この品質は植物材料のろ過に基づく様々なほかに多くの準備を共有しています。 Foremost, among these are the category of brews based on the straining of water through prepared leaves from a tea tree: the lineage and history of the tea genus will not be recounted as part of this paper, but evidence shows that the production of tea existed many thousands of years ago. The deficiency of HTCPCP in addressing the networked production of such a venerable beverage as tea is noteworthy: indeed, the only provision given for networked teapots is that they not respond to requests for the production of coffee, which, while eminently reasonable, does not allow for communication with the teapot for its intended purpose. 本論文ではHTCPCPを拡張してネットワーク化されたお茶製造機とティーポットと会話できるようにする仕様を決定します。 ここに定義された追加のプロトコルにより、おそらく最も人気のある温かい飲み物を作成する事ができる全ての装置を制御するのに必要なリクエストとレスポンスをすることができます。 1.1. 用語 この文章中の「しなければならない(MUST)」、「してはならない(MUST NOT)」、「必須である(REQUIRED)」、「SHALL(するものとする)」、「しないものとする(SHALL NOT)」、「すべきである(SHOULD)」、「すべきではない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「してもよい(MAY)」および「任意である(OPTIONAL)」のキーワードは、[RFC2119]に記述されているとおりに解釈すべきである。[KEYWORDS] 2. HTCPCP-TEA プロトコルアディション HTCPCPのお茶拡張は特定のHTCPCPメソッドの操作を改変します。 2.1. BREW と POST メソッド Control of a TEA-capable pot is performed, as described in the base HTCPCP specification, through the sending of BREW requests. POST requests are treated equivalently, but they remain deprecated. Tea production differs from coffee, however, in that a choice of teas is often provided for client selection before the tea is brewed. To this end, a TEA-capable pot that receives a BREW message of content type "message/teapot" MUST respond in accordance with the URI requested, as below. 2.1.1. The "/" URI For the URI "/", brewing will not commence. Instead, an Alternates header as defined in RFC 2295 [RFC2295] MUST be sent, with the available tea bags and/or leaf varieties as entries. An example of such a response is as follows: Alternates: {"/darjeeling" {type message/teapot}}, {"/earl-grey" {type message/teapot}}, {"/peppermint" {type message/teapot}} The following example demonstrates the possibility of interoperability of a TEA-capable pot that also complies with the base HTCPCP specification: Alternates: {"/" {type message/coffeepot}}, {"/pot-0/darjeeling" {type message/teapot}}, {"/pot-0/earl-grey" {type message/teapot}}, {"/pot-1/peppermint" {type message/teapot}} TEA-capable HTCPCP clients MUST check the contents of the Alternates header returned by a BREW request, and provide a specific URI for subsequent requests of the "message/teapot" type. A request to the "/" URI with a Content-Type header of "message/coffeepot" SHOULD also be responded to with an Alternates header in the above format, to allow TEA-capable clients the opportunity to present the selection of teas to the user if inferior caffeinated beverages have initially been requested. 2.1.2. Variety-Specific URIs TEA-capable pots follow the base HTCPCP specification when presented with a BREW request for a specific variety of tea. Pots SHOULD follow the recommendations for brewing strength given by each variety, and stop brewing when this strength is reached; it is suggested that the strength be measured by detection of the opacity of the beverage currently under brew by the pot. TEA-capable clients SHOULD indicate the end of brewing by sending a BREW request with an entity body containing "stop"; the pot MAY continue brewing beyond the recommended strength until this is received. If the "stop" request is not sent by the client, this may result in a state inversion in the proportion of tea to water in the brewing pot, which may be reported by some pots as a negative strength. If a BREW command with an entity body containing "stop" is received before the recommended strength is achieved, the pot MUST abort brewing and serve the resultant beverage at lesser strength. Finding the preferred strength of beverage when using this override is a function of the time between the TEA-capable pot receiving a "start" request and the subsequent "stop". Clients SHOULD be prepared to make multiple attempts to reach the preferred strength. 2.2. Modified Header Fields HTCPCP-TEA modifies the definition of one header field from the base HTCPCP specification. 2.2.1. The Accept-Additions Header Field It has been observed that some users of blended teas have an occasional preference for teas brewed as an emulsion of cane sugar with hints of water. To allow for this circumstance, the Accept-Additions header field defined in the base HTCPCP specification is updated to allow the following options: addition-type = ( "*" | milk-type | syrup-type | sweetener-type | spice-type | alcohol-type | sugar-type ) *( ";" parameter ) sugar-type = ( "Sugar" | "Xylitol" | "Stevia" ) Implementers should be aware that excessive use of the Sugar addition may cause the BREW request to exceed the segment size allowed by the transport layer, causing fragmentation and a delay in brewing. 2.3. Response Codes HTCPCP-TEA makes use of normal HTTP error codes and those defined in the base HTCPCP specification. 2.3.1. 300 Multiple Options A BREW request to the "/" URI, as defined in Section 2.1.1, will return an Alternates header indicating the URIs of the available varieties of tea to brew. It is RECOMMENDED that this response be served with a status code of 300, to indicate that brewing has not commenced and further options must be chosen by the client. 2.3.2. 403 Forbidden Services that implement the Accept-Additions header field MAY return a 403 status code for a BREW request of a given variety of tea, if the service deems the combination of additions requested to be contrary to the sensibilities of a consensus of drinkers regarding the variety in question. A method of garnering and collating consensus indicators of the most viable combinations of additions for each variety to be served is outside the scope of this document. 2.3.3. 418 I'm a Teapot TEA-capable pots that are not provisioned to brew coffee may return either a status code of 503, indicating temporary unavailability of coffee, or a code of 418 as defined in the base HTCPCP specification to denote a more permanent indication that the pot is a teapot. 3. The "message/teapot" Media Type To distinguish messages destined for TEA-capable HTCPCP services from pots compliant with the base HTCPCP specification, a new MIME media type is defined by this document. The Content-Type header of a POST or BREW request sent to a TEA-capable pot MUST be "message/teapot" if tea is to be requested. 4. Environmental Considerations As noted in Section 2.1, a BREW request with a Content-Type header field of "message/teapot" to a TEA-capable pot will result in an Alternates header being sent with the response, and a pot will not be brewed. However, if the BREW request has a Content-Type of "message/coffeepot", and the pot is capable of brewing coffee, the service's behavior will fall back to the base HTCPCP specification and a pot will be brewed. If the entity returned by the server when brewing commences contains a TEA-compliant Alternates header indicating "message/coffeepot" and the client does not want coffee, the client SHOULD then send a BREW request with an entity body containing "stop". This will result in wasted coffee; whether this is regarded as a bad thing is user-defined. Such waste can be prevented by TEA-capable clients, by first requesting a BREW of type "message/teapot" and then allowing selection of an available beverage. 5. セキュリティ問題 As with the base HTCPCP specification, most TEA-capable pots are expected to heat water through the use of electric elements, and as such will not be in proximity to fire. Therefore, no firewalls are necessary for communication with these pots to proceed. This extension does support communication with fired pots, however, which may require heat retention and control policies. Care should be taken so that coal-fired pots and electrically heated kettles are not connected to the same network, to prevent pots from referring to any kettles on the network as darkened or otherwise smoke driven. 6. 謝辞 This extension to the HTCPCP specification would not be possible without the base specification, and research on networked beverage production leading up thereto. In that vein, the author wishes to acknowledge the sterling work of Larry Masinter in the development of the leading protocol for coffee pot communication. Many thanks also to Kevin Waterson and Pete Davis, for providing guidance and suggestions during the drafting of this document. 7. 参照 7.1. 参照する参考文献 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. 有益な参考文献 [HTCPCP] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, April 1 1998. [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998. Author's Address Imran Nazar deviantART Inc. 7095 Hollywood Blvd Hollywood, CA 90028 EMail: inazar@deviantart.com