Independent Submission                                          I. Nazar
Request for Comments: 7168                                  1 April 2014
Updates: 2324
Category: Informational
ISSN: 2070-1721
        
Independent Submission                                          I. Nazar
Request for Comments: 7168                                  1 April 2014
Updates: 2324
Category: Informational
ISSN: 2070-1721
        

The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)

超文本咖啡壶控制协议(HTCPCP-Tea)

Abstract

摘要

The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.

超文本咖啡壶控制协议(HTCPCP)规范不允许泡茶,因为其种类繁多且复杂。本文概述了HTCPCP的扩展,以允许壶提供网络化的茶叶酿造设施。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

这是对RFC系列的贡献,独立于任何其他RFC流。RFC编辑器已选择自行发布此文档,并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7168.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7168.

Copyright Notice

版权公告

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2014 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。

Table of Contents

目录

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. HTCPCP-TEA Protocol Additions . . . . . . . . . . . . . . . . .  3
     2.1. BREW and POST Methods . . . . . . . . . . . . . . . . . . .  3
       2.1.1. The "/" URI . . . . . . . . . . . . . . . . . . . . . .  3
       2.1.2. Variety-Specific URIs . . . . . . . . . . . . . . . . .  4
     2.2. Modified Header Fields  . . . . . . . . . . . . . . . . . .  4
       2.2.1. The Accept-Additions Header Field . . . . . . . . . . .  4
     2.3. Response Codes  . . . . . . . . . . . . . . . . . . . . . .  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. Environmental Considerations  . . . . . . . . . . . . . . . . .  6
   5. Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   6. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  7
   7. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1. Normative References  . . . . . . . . . . . . . . . . . . .  7
     7.2. Informative References  . . . . . . . . . . . . . . . . . .  7
        
   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. HTCPCP-TEA Protocol Additions . . . . . . . . . . . . . . . . .  3
     2.1. BREW and POST Methods . . . . . . . . . . . . . . . . . . .  3
       2.1.1. The "/" URI . . . . . . . . . . . . . . . . . . . . . .  3
       2.1.2. Variety-Specific URIs . . . . . . . . . . . . . . . . .  4
     2.2. Modified Header Fields  . . . . . . . . . . . . . . . . . .  4
       2.2.1. The Accept-Additions Header Field . . . . . . . . . . .  4
     2.3. Response Codes  . . . . . . . . . . . . . . . . . . . . . .  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. Environmental Considerations  . . . . . . . . . . . . . . . . .  6
   5. Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   6. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  7
   7. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1. Normative References  . . . . . . . . . . . . . . . . . . .  7
     7.2. Informative References  . . . . . . . . . . . . . . . . . .  7
        
1. Introduction
1. 介绍

As noted in the Hyper Text Coffee Pot Control Protocol [HTCPCP], coffee is renowned worldwide as an artfully brewed caffeinated beverage, but coffee shares this quality with many other varied preparations based on the filtration of plant material. 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.

正如超文本咖啡壶控制协议[HTCPCP]所述,咖啡作为一种精心酿造的含咖啡因饮料在世界范围内享有盛誉,但咖啡与许多其他基于植物材料过滤的不同制剂具有相同的质量。最重要的是,其中有一类是通过茶树准备好的叶子将水过滤而成的泡茶:茶属的血统和历史将不会作为本文的一部分进行叙述,但证据表明茶的生产存在数千年前。

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在解决茶这类古老饮料的网络化生产方面存在不足:事实上,为网络化茶壶提供的唯一规定是,它们不响应生产咖啡的请求,这虽然非常合理,但不允许与茶壶就其预期目的进行沟通。

This paper specifies an extension to HTCPCP to allow communication with networked tea production devices and teapots. The additions to the protocol specified herein permit the requests and responses necessary to control all devices capable of making, arguably, the most popular caffeinated hot beverage.

本文指定了HTCPCP的扩展,以允许与网络化茶叶生产设备和茶壶进行通信。本协议中规定的附加协议允许必要的请求和响应,以控制所有能够制造(可以说)最受欢迎的含咖啡因热饮料的设备。

1.1. Terminology
1.1. 术语

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。

2. HTCPCP-TEA Protocol Additions
2. HTCPCP-TEA协议增补

The TEA extension to HTCPCP adapts the operation of certain HTCPCP methods.

HTCPCP的TEA扩展适用于某些HTCPCP方法的操作。

2.1. BREW and POST Methods
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.

如基本HTCPCP规范所述,可通过发送BREW请求来控制茶叶罐。POST请求被同等对待,但它们仍然被弃用。然而,茶叶生产不同于咖啡,因为在沏茶之前,通常会为客户提供茶叶选择。为此,接收内容类型为“message/teapot”的BREW消息的支持TEA的壶必须根据请求的URI进行响应,如下所示。

2.1.1. The "/" URI
2.1.1. “/”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:

对于URI“/”,将不会开始酿造。相反,必须发送RFC 2295[RFC2295]中定义的备用标题,可用的茶叶袋和/或茶叶品种作为条目。此类响应的示例如下所示:

      Alternates: {"/darjeeling" {type message/teapot}},
                  {"/earl-grey" {type message/teapot}},
                  {"/peppermint" {type message/teapot}}
        
      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:

以下示例演示了也符合基本HTCPCP规范的茶壶的互操作性的可能性:

      Alternates: {"/" {type message/coffeepot}},
                  {"/pot-0/darjeeling" {type message/teapot}},
                  {"/pot-0/earl-grey" {type message/teapot}},
                  {"/pot-1/peppermint" {type message/teapot}}
        
      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.

支持TEA的HTCPCP客户端必须检查BREW请求返回的Alternates标头的内容,并为后续的“message/teapot”类型请求提供特定的URI。

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.

对“/”URI(内容类型标题为“message/coffeepot”)的请求也应以上述格式的替代标题进行响应,以便在最初请求劣质含咖啡因饮料时,能够使用茶叶的客户有机会向用户展示所选茶叶。

2.1.2. Variety-Specific URIs
2.1.2. 品种特定URI

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.

对于特定种类的茶叶,当提出冲泡请求时,可冲泡茶叶的茶壶遵循基本HTCPCP规范。罐应遵循每个品种给出的酿造强度建议,当达到该强度时停止酿造;建议通过检测罐中当前正在酿造的饮料的不透明度来测量强度。

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.

支持TEA的客户端应通过发送包含“停止”的实体体的BREW请求来指示酿造结束;壶可以继续冲泡超过推荐的强度,直到收到为止。如果客户未发送“停止”请求,这可能会导致冲泡罐中茶与水的比例出现状态反转,某些罐可能会报告为负强度。

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.

如果在达到推荐浓度之前收到包含“停止”的实体体的BREW命令,则壶必须中止酿造并以较低的浓度供应生成的饮料。当使用此超控时,寻找饮料的首选浓度是茶壶收到“启动”请求和随后的“停止”之间时间的函数。客户应准备好多次尝试以达到首选优势。

2.2. Modified Header Fields
2.2. 修改的标题字段

HTCPCP-TEA modifies the definition of one header field from the base HTCPCP specification.

HTCPCP-TEA修改了基础HTCPCP规范中一个标题字段的定义。

2.2.1. The Accept-Additions Header Field
2.2.1. 接受添加标题字段

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:

据观察,一些混合茶的用户偶尔会偏爱以蔗糖乳液加少量水酿造的茶。为了适应这种情况,更新了基础HTCPCP规范中定义的Accept Additions标头字段,以允许以下选项:

      addition-type   = ( "*"
                        | milk-type
                        | syrup-type
                        | sweetener-type
                        | spice-type
                        | alcohol-type
                        | sugar-type
                        ) *( ";" parameter )
      sugar-type      = ( "Sugar" | "Xylitol" | "Stevia" )
        
      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.

实施者应注意,过度使用糖添加可能会导致BREW请求超过传输层允许的段大小,从而导致碎片和酿造延迟。

2.3. Response Codes
2.3. 响应代码

HTCPCP-TEA makes use of normal HTTP error codes and those defined in the base HTCPCP specification.

HTCPCP-TEA使用正常HTTP错误代码和基本HTCPCP规范中定义的错误代码。

2.3.1. 300 Multiple Options
2.3.1. 300多种选择

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.1.1节所定义,对“/”URI的BREW请求将返回一个Alternates标头,指示要酿造的可用茶叶品种的URI。建议该回复的状态代码为300,以表明酿造尚未开始,客户必须选择其他选项。

2.3.2. 403 Forbidden
2.3.2. 403禁止

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.

实现Accept Additions header(接受添加项标题)字段的服务可能会返回给定种类茶叶的酿造请求的403状态代码,前提是服务认为请求的添加项组合违背了饮酒者对所述种类的共识。

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
2.3.3. 我是个茶壶

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.

未配置为冲泡咖啡的茶壶可能返回503状态代码,表示咖啡暂时不可用,或返回418代码,如基本HTCPCP规范中所定义,表示壶是茶壶的更永久指示。

3. The "message/teapot" Media Type
3. “消息/茶壶”媒体类型

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.

为了区分发往支持TEA的HTCPCP服务的消息和符合基本HTCPCP规范的pots,本文定义了一种新的MIME媒体类型。如果要请求茶,发送到支持茶功能的茶壶的POST或BREW请求的内容类型标头必须为“message/teapot”。

4. Environmental Considerations
4. 环境考虑

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.

如第2.1节所述,如果BREW请求的内容类型标题字段为“message/teapot”,则发送到支持TEA功能的壶时,会产生一个替代标题,并随响应一起发送,壶不会被酿造。但是,如果BREW请求的内容类型为“message/coffeepot”,并且该壶能够冲泡咖啡,则服务的行为将回到基本HTCPCP规范,并将冲泡一壶咖啡。

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.

如果开始冲泡时服务器返回的实体包含符合TEA的Alternates标头,指示“消息/咖啡壶”,并且客户端不想要咖啡,则客户端应发送包含“停止”的实体体的冲泡请求。这将导致浪费咖啡;这是否被视为坏事是用户定义的。

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.

能够喝茶的客户可以防止这种浪费,首先请求“message/teapot”类型的啤酒,然后允许选择可用的饮料。

5. Security Considerations
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.

与基础HTCPCP规范一样,大多数能够使用茶壶的茶壶预计会通过使用电气元件来加热水,因此不会靠近火。因此,与这些POT进行通信不需要防火墙。

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. Acknowledgements
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.

如果没有基本规范以及在此之前对网络化饮料生产的研究,HTCPCP规范的扩展是不可能的。在这方面,作者希望感谢Larry Masinter在开发咖啡壶通信的领先协议方面所做的出色工作。

Many thanks also to Kevin Waterson and Pete Davis, for providing guidance and suggestions during the drafting of this document.

非常感谢Kevin Waterson和Pete Davis在本文件起草过程中提供的指导和建议。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[关键词]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

7.2. Informative References
7.2. 资料性引用

[HTCPCP] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, April 1 1998.

[HTCPCP]Masinter,L.,“超文本咖啡壶控制协议(HTCPCP/1.0)”,RFC 23241998年4月1日。

[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.

[RFC2295]Holtman,K.和A.Mutz,“HTTP中的透明内容协商”,RFC 2295,1998年3月。

Author's Address

作者地址

Imran Nazar deviantART Inc. 7095 Hollywood Blvd Hollywood, CA 90028

伊姆兰·纳扎尔·德维安塔特公司,加利福尼亚州好莱坞大道7095号,邮编90028

   EMail: inazar@deviantart.com
        
   EMail: inazar@deviantart.com