超文本咖啡壶控制协议

https://www.ietf.org/rfc/rfc2324.txt

网络工作组                                                                            L. Masinter
请求评论：2324                                                                        1998年4月1日
分类：信息性

                               超文本咖啡壶控制协议（HTCPCP / 1.0）

该备忘录的状态

    本备忘录为互联网社区提供信息。它不指定任何形式的互联网标准。本备忘录的传播没有限制。

版权声明

    版权所有（C）互联网协会（1998）。保留所有权利。

摘要

    本文档介绍了HTCPCP，一种用于控制、监视和诊断咖啡壶的协议。
 

1.理由和范围

    世界各地都有咖啡。在这个计算机无处不在的世界里，越来越多的计算机科学家想煮咖啡。煮咖啡是一门艺术，然而在网络连接的世界中，分布式智能超越了艺术。因此，我们对一个专为煮咖啡设计的协议有着强烈、深切而丰富的渴求。煮咖啡需要用到咖啡壶。控制联网的咖啡壶需要一个协议。

    越来越多的家庭和消费类设备正在连接到互联网。早期的网络实验证明了自动售货机连接到互联网进行状态监视的可行性。最早的通过网络进行远程控制的机器之一是联网的烤面包机（通过SNMP控制），它在1990年的[RFC2235]中首次亮相。

    对无所不在的设备连接的需求导致了IPv4地址空间的消耗。消费者想要远程控制诸如咖啡壶之类的设备，这样他们就能在醒来时品尝到新鲜煮好的咖啡，或者让咖啡刚好在准备完晚餐时煮好。

    本文档定义了超文本咖啡壶控制协议（HTCPCP），它支持完整的请求和响应，来控制所有主流的能制作含咖啡因热饮的设备。

    HTTP 1.1（[RFC2068]）允许网络对象从源服务器传输到客户端。网络遍布全球。HTCPCP基于HTTP。由于HTTP无处不在，加之一个事物如果不好就不会如此流行，故HTTP是好的。如果你想煮好的咖啡，HTCPCP必须是好的。为了让HTCPCP更好，它最好是基于HTTP的。

    本协议的未来版本可能包含针对意式浓缩咖啡机及类似设备的扩展。

2.HTCPCP协议

    HTCPCP协议建立在HTTP之上，增加了一些新方法、标头字段和返回代码。所有HTCPCP服务器应该遵循URI结构“coffee：”（第4节）。

2.1 HTCPCP新增方法

2.1.1 BREW方法以及POST的使用

    控制咖啡壶的命令通过BREW或POST方法从客户端发送到咖啡服务器，信息体的内容类型设置为“应用程序/咖啡壶命令”。

    咖啡壶服务器必须同时接受BREW和POST方法。但是，不推荐使用POST出发动作。

    咖啡壶通过电热方法加热水，不需要火。因此，防火墙不是必须的，防火墙控制策略是无关紧要的。但是，POST可能是咖啡的商标，因此添加了BREW方法。BREW方法可以与其他基于HTTP的协议共同使用（例如，超文本啤酒厂控制协议）。

2.1.2 GET方法

    在HTTP中，GET方法表示“检索请求URI标识的任何内容（以实体形式）”。如果请求URI涉及数据生成过程，返回实体应为产生的数据而不是源文本，除非该文本恰好是该过程的输出。

    在HTCPCP中，与咖啡壶相关的资源是物理资源，而不是信息资源。大多数咖啡URI的数据部分不含咖啡因。

2.1.3 PROPFIND方法

    如果一杯咖啡是数据，则可以使用PROPFIND方法获取调制资源的元数据[WEBDAV]。

2.1.4 WHEN方法

    当咖啡已经倒好，开始倒牛奶后，接收牛奶的容器需要在咖啡中加好了足够的牛奶时说"when"。出于这个目的，HTCPCP中添加来“WHEN”方法。牛奶足够了？说WHEN。

2.2 咖啡壶头字段

    HTCPCP建议使用几个HTTP头字段并定义了一些新的字段。

2.2.1 推荐的头字段

2.2.1.1 “Safe”响应头字段。
 

    [SAFE]定义了HTTP响应的头字段，“Safe”可以用于表示重复进行一个HTTP请求是安全的。引入"Safe:Yes"头字段，从而当一个请求的结果可能重复时，客户端可以重复一个历史请求。

    实际上，煮咖啡的设备安全性差异很大，并且可能取决于客户而不仅仅是服务器的状态。因此，本协议引入了对"Safe"响应头部的扩展：

          Safe                = "Safe" ":" safe-nature
          safe-nature         = "yes" | "no" | conditionally-safe
          conditionally-safe  = "if-" safe-condition
          safe-condition      = "user-awake" | token

        这些标识允许用户代理处理一些安全的重复请求，特别是用更加用户友好的方式进行安全的POST请求。

2.2.2 新的标头字段

2.2.2.1 接受添加标头字段

    在HTTP中，"Accept"请求标头字段用于指定媒体可接受的响应类型。但是，在HTCPCP中，响应可能会导致自动煮咖啡壶的额外动作。因此，HTCPCP添加了一个新的标头字段，"Accept-Additions"：

    Accept-Additions = "Accept-Additions" ":"
                       #( addition-range [ accept-params ] )
    addition-type   = ( "*"
                          | milk-type       牛奶类型
                          | syrup-type      糖浆类型
                          | sweetener-type  甜味剂类型
                          | spice-type      香料类型
                          | alcohol-type    酒精类型
                          ) *( ";" parameter )
    milk-type       = ( "Cream" | "Half-and-half" | "Whole-milk" | "Part-Skim" | "Skim" | "Non-Dairy" )
     牛奶类型              奶油        一种一半          全脂牛奶        半脱脂牛奶    脱脂牛奶    不要牛奶
    syrup-type      = ( "Vanilla" | "Almond" | "Raspberry" | "Chocolate" )
     糖浆类型              香草          杏仁        覆盆子        巧克力
    alcohol-type    = ( "Whisky" | "Rum" | "Kahlua" | "Aquavit" )
     酒精类型              威士忌    朗姆酒     咖啡酒      白兰地

2.2.3 省略的标题字段

    不提供不含咖啡因的咖啡的选项。那有什么意义？

2.3 HTCPCP返回码

    使用通常的HTTP返回码指示HTCPCP服务器状态。本部分给出一些特殊解释新的返回码。

2.3.1 406不可接受

    此返回码通常被解释为"请求标识的资源只能生成响应实体，根据请求中发送的接受标头，这些实体的内容特征不可接受"。在HTCPCP中，此响应代码可能是咖啡壶的操作员未能遵守"Accept-Additions"请求导致的。
除非是HEAD请求，否则响应应包含一个实体，列出所有可获得的咖啡添加物。

    实际上，大多数自动咖啡壶目前无法提供添加物。

2.3.2 418我是一个茶壶

    任何用茶壶冲泡咖啡的尝试都将导致错误代码"418 I'm a teapot"。返回的实体短小精悍。

3.“咖啡” URI方案

    由于咖啡是国际化的，所以有国际咖啡URI方案。所有咖啡URL方案都使用UTF-8编码的URL编码编写，可以用29种语言中的任何一种拼写"咖啡"，以遵循URI[URLI18N]国际化的传统。

    coffee-url  =  coffee-scheme ":" [ "//" host ]
                   ["/" pot-designator ] ["?" additions-list ]

    coffee-scheme = ( "koffie"                   ; Afrikaans, Dutch            南非荷兰语，荷兰语
                    | "q%C3%A6hv%C3%A6"          ; Azerbaijani                 阿塞拜疆语
                    | "%D9%82%D9%87%D9%88%D8%A9" ; Arabic                      阿拉伯语
                    | "akeita"                   ; Basque                      巴斯克语
                    | "koffee"                   ; Bengali                     孟加拉语
                    | "kahva"                    ; Bosnian                     波斯尼亚语
                    | "kafe"                     ; Bulgarian, Czech            保加利亚语，捷克语
                    | "caf%C3%E8"                ; Catalan, French, Galician   加泰罗尼亚语，法语，加利西亚语 
                    | "%E5%92%96%E5%95%A1"       ; Chinese                     汉语
                    | "kava"                     ; Croatian                    克罗地亚语
                    | "k%C3%A1va                 ; Czech                       捷克语
                    | "kaffe"                    ; Danish, Norwegian, Swedish  丹麦语，挪威语，瑞典语
                    | "coffee"                   ; English                     英语
                    | "kafo"                     ; Esperanto                   世界语
                    | "kohv"                     ; Estonian                    爱沙尼亚语
                    | "kahvi"                    ; Finnish                     芬兰语
                    | "%4Baffee"                 ; German                      德语
                    | "%CE%BA%CE%B1%CF%86%CE%AD" ; Greek                       希腊语
                    | "%E0%A4%95%E0%A5%8C%E0%A4%AB%E0%A5%80" ; Hindi           印地语
                    | "%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC" ; Japanese        日语
                    | "%EC%BB%A4%ED%94%BC"       ; Korean                      韩语
                    | "%D0%BA%D0%BE%D1%84%D0%B5" ; Russian                     俄语
                    | "%E0%B8%81%E0%B8%B2%E0%B9%81%E0%B8%9F" ; Thai            泰语
                    )

     pot-designator = "pot-" integer  ; 对有多个壶的机器
     additions-list = #( addition )

    所有其他咖啡方案形式都是等效的。但是，使用不同语言的咖啡方案可能被解释成咖啡壶产生的咖啡种类。注意URL方案名称不区分大小写，但大写形式为对德语很重要，因此必须对开头的“K”进行编码

4.“消息/咖啡壶”媒体类型

    POST或BREW请求实体的Content-Type必须为"message/coffeepot"。因为大多数控制咖啡壶的信息是由附加请求头提供的，"message/coffeepot"仅包含一个咖啡消息主体：

    coffee-message-body = "start" | "stop"

5.操作上的限制

    本部分列出了一些使用HTCPCP的普遍问题。

5.1 时序注意事项

    需要保证用户和咖啡壶之间可靠的服务质量。咖啡壶应使用网络时间协议[NTP]将其时钟同步到全球时间标准。

    远程机器是一项昂贵的技术。 但是，随着剑桥咖啡壶[CAM]的出现，已经证明了使用网络（而不是SNMP）进行远程系统监视和管理是可行的。其他咖啡壶维护任务可以通过远程机器人完成。

    网络数据通常是静态的。 因此，为了减少传输数据量和时间，浏览器将用户访问的每个网页存储在用户的计算机上。当用户想返回该页面，由于页面现在存储在本地，就无需再次从服务器请求。而用于控制机器或监视场景变化的图像是动态的。每次访问都需要从服务器获取一个新版本。

5.2 穿越防火墙

    大多数情况下HTTP流量相当容易穿过防火墙。现代的咖啡壶不使用火。但是防火墙可以保护咖啡壶，使其免受任何形式的热源的伤害，不仅仅是火。每个家用计算机网络都应受到防火墙的保护从而免受热源的侵害。但是，在远程遥控咖啡壶也很重要。因此，HTCPCP需要能够轻松穿越防火墙。

       通过将HTCPCP基于HTTP并使用端口80，它将获取所有HTTP穿越防火墙的优点。当然，家庭防火墙将需要重新配置或更新版本以适应HTCPCP的特殊方法、头部和尾部，不过这些升级是很容易的。大多数家庭网络系统管理员都喝咖啡，并且愿意满足HTCPCP穿越防火墙的需要。

6.系统管理注意事项

    使用HTTP协议监控咖啡壶是网络的早期应用。最初，监控咖啡壶是对ATM网络[CAM]的早期使用（也是适当的使用）。

         传统技术[CAM]是将抓帧器连接到摄像机，然后将图像输入到网络服务器。 这是一种对ATM网络的合理应用。 在这个咖啡壶装置中，使用了剑桥大学实验室的特洛伊室来提供监控咖啡壶的网络界面。 由于参与研究的都是贫穷的学者，只有一台咖啡过滤机，它被放在特洛伊室外面的走廊上。但是，作为高度敬业且勤奋的学者，他们喝了很多咖啡，煮新鲜的咖啡并不会要很长时间。

        MSRPC2这项服务是剑桥计算机实验室第一个使用新的RPC方法设计的应用。它运行在MSNL（多服务网络层）上，这是一个为ATM网络设计的网络层协议。

        联网的咖啡壶可以通过咖啡壶MIB[CPMIB]进行管理。

7.安全注意事项

    任何一个插足我和我的晨间咖啡的人都不安全。

    互联网用户无限制地访问不受保护的咖啡壶可能导致几种“拒绝提供咖啡服务”攻击。过滤设备使用不当可能会导致特洛伊木马。过滤不是一种好的病毒防护方法。

         将咖啡渣放入互联网管道可能会导致管道堵塞，这将需要互联网管道工[PLUMB]的服务，而管道工需要网络水管工的帮助。

8.致谢

    非常感谢本标准的贡献者们，他们是Roy Fielding，Mark Day，Keith Moore，Carl Uno-Manros，Michael Slavitch，和 Martin Duerst。腾跃小马，CMU可乐机，剑桥咖啡壶，联网面包机以及其它计算机控制的远程设备启发了这个宝贵的创造。

9.参考

   [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.Berners-Lee, "超文本传输协议 -- HTTP/1.1", RFC 2068,January 1997.

   [RFC2186] Wessels, D., and K. Claffy, "网络缓存协议 (ICP),version 2," RFC 2186, September 1997

   [CPMIB] Slavitch, M., "使用SMIv2的滴漏式加热饮料硬件设备的管理对象的定义", RFC 2325, 1 April1998.

   [HTSVMP] Q. Stafford-Fraser, "超文本三明治面包车控制协议, Version 3.2". In preparation.

   [RFC2295] Holtman, K., and A. Mutz, "HTTP中的透明内容协商", RFC 2295, March 1998.

   [SAFE] K. Holtman. "安全响应头字段", September 1997.

   [CAM] "特洛伊室咖啡壶", D. Gordon and M. Johnson, University of Cambridge Computer Lab, <http://www.cl.cam.ac.uk/coffee/coffee.html>

   [CBIO] "特洛伊室咖啡壶（非技术）传记", Q.Stafford-Fraser, University of Cambridge Computer Lab, <http://www.cl.cam.ac.uk/coffee/qsf/coffee.html>.

   [RFC2235] Zakon, R., "霍布斯互联网时间轴", FYI 32, RFC 2230, November 1997.  See also <http://www.internode.com.au/images/toaster2.jpg>

   [NTP] Mills, D., "网络时间协议(第3版)规范,Implementation and Analysis", RFC 1305, March 1992.

   [URLI18N] Masinter, L., "使用UTF8编码非ASCII字符扩展URI" Work in Progress.

   [PLUMB] B. Metcalfe, "年度互联网管道工: Jim Gettys", Infoworld, February 2, 1998.

   [COKE] D. Nichols, "可乐机历史", C. Everhart, "互联网的有趣用法", <http://www-cse.ucsd.edu/users/bsy/coke.history.txt>.

10.作者的地址

拉里·马辛特（Larry Masinter）
施乐帕洛阿尔托研究中心
土狼山道3333号
加利福尼亚州帕洛阿尔托94304

电子邮件：masinter@parc.xerox.com

11.完整的版权声明

    版权所有（C）互联网协会（1998）。版权所有。

        本文档及其翻译本可以复制并提供给他人，对本文档进行评价、解释、帮助实现的派生作品可以全部或部分的准备、复制、出版和分发，而不受任何形式的限制，前提是这些副本和衍生作品均包含上述版权声明和本段文字。 但是，不得以任何方式修改本文档本身，例如删除版权声明或对互联网协会或其他网络组织的引用，除非是出于开发网络标准的需要，在这种情况下，必须遵循网络标准流程，或将其翻译成英语以外的其他语言所需的流程。

   上面授予的有限权限是永久的，不会由互联网协会或其后继者或受让人撤销。

       本文档和此处包含的信息是按“原样”提供的，互联网协会和互联网工程任务组不作任何明示或暗示的担保，包括但不限于使用本信息不会侵犯针对特定目的的适销性或适用性的任何权利或任何默示担保。

 

Anyone who gets in between me and my morning coffee should be insecure.

后续：

https://www.ietf.org/rfc/rfc7168.txt