- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Mon, 22 Mar 1999 18:24:40 PST
- To: "Graham Klyne" <GK@Dial.pipex.com>, "Jacob Palme" <jpalme@dsv.su.se>
- Cc: "IETF Applications Area Discussion List" <discuss@apps.ietf.org>
HTTP has many extensibility mechanisms, each with its own theory and practice for default handling, mandatory behavior, and interaction with firewalls, access control policy, intermediate proxies, etc. In HTTP, you can use a new method (PROPPATCH) use a new URL scheme (afs:) use a new protocol name (SIP/1.0) use a new protocol version (HTTP/1.3) create a new header use a new value for an old header, including - create a new extension field for an old value - create a new content-type for the message body extend the data sent in the body. Most of these extension methods are used by one or more applications that are built out of HTTP. (HTCPCP attempts to use most of these.) The theory and practice of these extension mechanisms differ. Some examples: Servers are supposed to complain if they see new methods, or at least handle them with authorization for "unknown methods", but some servers treat unrecognized methods as GET; a few proxies will forward unrecognized methods as if they were GET. Most proxies will complain if they are handed unknown URL schemes; the practice with origin servers isn't widely tested. Similar extensibility mechanisms are also used by applications that use or extend mail; I would include not only SMTP, but the mail-based applications such as Internet Fax, EDI, and Workflow interoperability. Larry -- http://www.parc.xerox.com/masinter
Received on Monday, 22 March 1999 21:25:54 UTC