RFC relevance of response

As per Relevance of the word response, we have this rfc below:

Network Working Group L.
Request for Comments: 2324 1 April 1998
Category:

Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved

This document describes HTCPCP, a protocol for controlling
monitoring, and diagnosing coffee pots

1. Rationale and

There is coffee all over the world. Increasingly, in a world in
computing is ubiquitous, the computists want to make coffee.
brewing is an art, but the distributed intelligence of the web
connected world transcends art. Thus, there is a strong, dark,
requirement for a protocol designed espressoly for the brewing
coffee. Coffee is brewed using coffee pots. Networked coffee
require a control protocol if they are to be controlled

Increasingly, home and consumer devices are being connected to
Internet. Early networking experiments demonstrated vending
connected to the Internet for status monitoring [COKE]. One of
first remotely _operated_ machine to be hooked up to the Internet
the Internet Toaster, (controlled via SNMP) was debuted in 1990
[RFC2235].

The demand for ubiquitous appliance connectivity that is causing
consumption of the IPv4 address space. Consumers want remote
of devices such as coffee pots so that they may wake up to
brewed coffee, or cause coffee to be prepared at a precise time
the completion of dinner preparations

Masinter Informational [Page 1]

RFC 2324 HTCPCP/1.0 1 April 1998

This document specifies a Hyper Text Coffee Pot Control
(HTCPCP), which permits the full request and responses necessary
control all devices capable of making the popular caffeinated
beverages

HTTP 1.1 ([RFC2068]) permits the transfer of web objects from
servers to clients. The web is world-wide. HTCPCP is based on HTTP
This is because HTTP is everywhere. It could not be so
without being good. Therefore, HTTP is good. If you want good coffee
HTCPCP needs to be good. To make HTCPCP good, it is good to
HTCPCP on HTTP

Future versions of this protocol may include extensions for
machines and similar devices

2. HTCPCP

The HTCPCP protocol is built on top of HTTP, with the addition of
few new methods, header fields and return codes. All HTCPCP
should be referred to with the "coffee:" URI scheme (Section 4).

2.1 HTCPCP Added

2.1.1 The BREW method, and the use of

Commands to control a coffee pot are sent from client to
server using either the BREW or POST method, and a message body
Content-Type set to "application/coffee-pot-command".

A coffee pot server MUST accept both the BREW and POST
equivalently. However, the use of POST for causing actions to
is deprecated

Coffee pots heat water using electronic mechanisms, so there is
fire. Thus, no firewalls are necessary, and firewall control
is irrelevant. However, POST may be a trademark for coffee, and
the BREW method has been added. The BREW method may be used
other HTTP-based protocols (e.g., the Hyper Text Brewery
Protocol).

2.1.2 GET

In HTTP, the GET method is used to mean "retrieve
information (in the form of an entity) identified by the Request
URI." If the Request-URI refers to a data-producing process, it
the produced data which shall be returned as the entity in
response and not the source text of the process, unless that
happens to be the output of the process

Masinter Informational [Page 2]

RFC 2324 HTCPCP/1.0 1 April 1998

In HTCPCP, the resources associated with a coffee pot are physical
and not information resources. The "data" for most coffee
contain no caffeine

2.1.3 PROPFIND

If a cup of coffee is data, metadata about the brewed resource
discovered using the PROPFIND method [WEBDAV].

2.1.4 WHEN

When coffee is poured, and milk is offered, it is necessary for
holder of the recipient of milk to say "when" at the time
sufficient milk has been introduced into the coffee. For
purpose, the "WHEN" method has been added to HTCPCP. Enough?
WHEN

2.2 Coffee Pot Header

HTCPCP recommends several HTTP header fields and defines some
ones

2.2.1 Recommended header

2.2.1.1 The "safe" response header field

[SAFE] defines a HTTP response header field, "Safe", which can
used to indicate that repeating a HTTP request is safe. The
of a "Safe: Yes" header field allows a client to repeat a
request if the result of the request might be repeated

The actual safety of devices for brewing coffee varies widely,
may depend, in fact, on conditions in the client rather than just
the server. Thus, this protocol includes an extension to the "Safe
response header

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

indication will allow user agents to handle retries of some
requests, in particular safe POST requests, in a more user-
way

Masinter Informational [Page 3]

RFC 2324 HTCPCP/1.0 1 April 1998

2.2.2 New header

2.2.2.1 The Accept-Additions header

In HTTP, the "Accept" request-header field is used to specify
types which are acceptable for the response. However, in HTCPCP,
response may result in additional actions on the part of
automated pot. For this reason, HTCPCP adds a new header field
"Accept-Additions":

Accept-Additions = "Accept-Additions" ":"
#( addition-range [ accept-params ] )

addition-type = ( "*"
| milk-
| syrup-
| sweetener-
| spice-
| alcohol-
) *( ";" 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 Omitted Header

No options were given for decaffeinated coffee. What's the point

2.3 HTCPCP return

Normal HTTP return codes are used to indicate difficulties of
HTCPCP server. This section identifies special interpretations
new return codes

2.3.1 406 Not

This return code is normally interpreted as "The resource
by the request is only capable of generating response entities
have content characteristics not acceptable according to the
headers sent in the request. In HTCPCP, this response code MAY
returned if the operator of the coffee pot cannot comply with
Accept-Addition request. Unless the request was a HEAD request,
response SHOULD include an entity containing a list of
coffee additions

Masinter Informational [Page 4]

RFC 2324 HTCPCP/1.0 1 April 1998

In practice, most automated coffee pots cannot currently
additions

2.3.2 418 I'm a

Any attempt to brew coffee with a teapot should result in the
code "418 I'm a teapot". The resulting entity body MAY be short
stout

3. The "coffee" URI

Because coffee is international, there are international coffee
schemes. All coffee URL schemes are written with URL encoding of
UTF-8 encoding of the characters that spell the word for "coffee"
any of 29 languages, following the conventions
internationalization in URIs [URLI18N].

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

coffee-scheme = ( "koffie" ; Afrikaans,
| "q%C3%A6hv%C3%A6" ;
| "%D9%82%D9%87%D9%88%D8%A9" ;
| "akeita" ;
| "koffee" ;
| "kahva" ;
| "kafe" ; Bulgarian,
| "caf%C3%E8" ; Catalan, French,
| "%E5%92%96%E5%95%A1" ;
| "kava" ;
| "k%C3%A1va ;
| "kaffe" ; Danish, Norwegian,
| "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" ;
)

pot-designator = "pot-" integer ; for machines with multiple
additions-list = #( addition )

Masinter Informational [Page 5]

RFC 2324 HTCPCP/1.0 1 April 1998

All alternative coffee-scheme forms are equivalent. However, the
of coffee-scheme in various languages MAY be interpreted as
indication of the kind of coffee produced by the coffee pot.
that while URL scheme names are case-independent, capitalization
important for German and thus the initial "K" must be encoded

4. The "message/coffeepot" media

The entity body of a POST or BREW request MUST be of Content-
"message/coffeepot". Since most of the information for
the coffee pot is conveyed by the additional headers, the content
"message/coffeepot" contains only a coffee-message-body

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

5. Operational

This section lays out some of the operational issues with
of HTCPCP ubiquitously

5.1 Timing

A robust quality of service is required between the coffee pot
and the coffee pot service. Coffee pots SHOULD use the Network
Protocol [NTP] to synchronize their clocks to a globally
time standard

Telerobotics has been an expensive technology. However, with
advent of the Cambridge Coffee Pot [CAM], the use of the web (
than SNMP) for remote system monitoring and management has
proven. Additional coffee pot maintenance tasks might
accomplished by remote robotics

Web data is normally static. Therefore to save data transmission
time, Web browser programs store each Web page retrieved by a user
the user's computer. Thus, if the user wants to return to that page
it is now stored locally and does not need to be requested again
the server. An image used for robot control or for monitoring
changing scene is dynamic. A fresh version needs to be retrieved
the server each time it is accessed

5.2 Crossing

In most organizations HTTP traffic crosses firewalls fairly easily
Modern coffee pots do not use fire. However, a "firewall" is
for protection of any source from any manner of heat, and not
fire. Every home computer network SHOULD be protected by a
from sources of heat. However, remote control of coffee pots

Masinter Informational [Page 6]

RFC 2324 HTCPCP/1.0 1 April 1998

important from outside the home. Thus, it is important that
cross firewalls easily

By basing HTCPCP on HTTP and using port 80, it will get all of HTTP'
firewall-crossing virtues. Of course, the home firewalls will
reconfiguration or new versions in order to accommodate HTCPCP
specific methods, headers and trailers, but such upgrades will
easily accommodated. Most home network system administrators
coffee, and are willing to accommodate the needs of
HTCPCP

6. System management

Coffee pot monitoring using HTTP protocols has been an
application of the web. In the earliest instance, coffee
monitoring was an early (and appropriate) use of ATM networks [CAM].

The traditional technique [CAM] was to attach a frame-grabber to
video camera, and feed the images to a web server. This was
appropriate application of ATM networks. In this coffee
installation, the Trojan Room of Cambridge University
was used to give a web interface to monitor a common coffee pot.
us involved in related research and, being poor,
academics, we only had one coffee filter machine between us,
lived in the corridor just outside the Trojan Room. However,
highly dedicated and hard-working academics, we got through a lot
coffee, and when a fresh pot was brewed, it often didn't last long

This service was created as the first application to use a new
mechanism designed in the Cambridge Computer Laboratory - MSRPC2.
runs over MSNL (Multi-Service Network Layer) - a network
protocol designed for ATM networks

Coffee pots on the Internet may be managed using the Coffee Pot
[CPMIB].

7. Security

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

Unmoderated access to unprotected coffee pots from Internet
might lead to several kinds of "denial of coffee service" attacks
The improper use of filtration devices might admit trojan grounds
Filtration is not a good virus protection method

Masinter Informational [Page 7]

RFC 2324 HTCPCP/1.0 1 April 1998

Putting coffee grounds into Internet plumbing may result in
plumbing, which would entail the services of an Internet
[PLUMB], who would, in turn, require an Internet Plumber's Helper

Access authentication will be discussed in a separate memo

8.

Many thanks to the many contributors to this standard, including
Fielding, Mark Day, Keith Moore, Carl Uno-Manros, Michael Slavitch
and Martin Duerst. The inspiration of the Prancing Pony, the
Coke Machine, the Cambridge Coffee Pot, the Internet Toaster,
other computer controlled remote devices have led to this
creation

9.

[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068,
January 1997.

[RFC2186] Wessels, D., and K. Claffy, "Internet Cache Protocol (ICP),
version 2," RFC 2186, September 1997

[CPMIB] Slavitch, M., "Definitions of Managed Objects for Drip-
Heated Beverage Hardware Devices using SMIv2", RFC 2325, 1
1998.

[HTSVMP] Q. Stafford-Fraser, "Hyper Text Sandwich Van
Protocol, Version 3.2". In preparation

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

[SAFE] K. Holtman. "The Safe Response Header Field", September 1997.

[CAM] "The Trojan Room Coffee Machine", D. Gordon and M. Johnson
University of Cambridge Computer Lab

[CBIO] "The Trojan Room Coffee Pot, a (non-technical) biography", Q
Stafford-Fraser, University of Cambridge Computer Lab
.

[RFC2235] Zakon, R., "Hobbes' Internet Timeline", FYI 32, RFC 2230,
November 1997. See

Masinter Informational [Page 8]

RFC 2324 HTCPCP/1.0 1 April 1998

[NTP] Mills, D., "Network Time Protocol (Version 3) Specification
Implementation and Analysis", RFC 1305, March 1992.

[URLI18N] Masinter, L., "Using UTF8 for non-ASCII Characters
Extended URIs" Work in Progress

[PLUMB] B. Metcalfe, "Internet Plumber of the Year: Jim Gettys",
Infoworld, February 2, 1998.

[COKE] D. Nichols, "Coke machine history", C. Everhart, "
uses of networking", cse.ucsd.edu/users/bsy/coke.history.txt>.

10. Author's

Larry
Xerox Palo Alto Research
3333 Coyote Hill
Palo Alto, CA 94304

EMail: masinter@parc.xerox.

Masinter Informational [Page 9]

RFC 2324 HTCPCP/1.0 1 April 1998

11. Full Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Masinter Informational [Page 10]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX