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
電子郵件:[email protected]
11.完整的版權聲明
版權所有(C)互聯網協會(1998)。版權所有。
本文檔及其翻譯本可以複製並提供給他人,對本文檔進行評價、解釋、幫助實現的派生作品可以全部或部分的準備、複製、出版和分發,而不受任何形式的限制,前提是這些副本和衍生作品均包含上述版權聲明和本段文字。 但是,不得以任何方式修改本文檔本身,例如刪除版權聲明或對互聯網協會或其他網絡組織的引用,除非是出於開發網絡標準的需要,在這種情況下,必須遵循網絡標準流程,或將其翻譯成英語以外的其他語言所需的流程。
上面授予的有限權限是永久的,不會由互聯網協會或其後繼者或受讓人撤銷。
本文檔和此處包含的信息是按“原樣”提供的,互聯網協會和互聯網工程任務組不作任何明示或暗示的擔保,包括但不限於使用本信息不會侵犯針對特定目的的適銷性或適用性的任何權利或任何默示擔保。
Anyone who gets in between me and my morning coffee should be insecure.
後續: