W3C home > Mailing lists > Public > ietf-discuss@w3.org > March 1999

RE: Extensibility methods in APPCORE protocol

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>
Message-ID: <000001be74d4$4ec0cea0$15d0000d@copper.parc.xerox.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:05 UTC