From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc2774.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 1123 insertions(+)
 create mode 100644 doc/rfc/rfc2774.txt

(limited to 'doc/rfc/rfc2774.txt')

diff --git a/doc/rfc/rfc2774.txt b/doc/rfc/rfc2774.txt
new file mode 100644
index 0000000..cb8328a
--- /dev/null
+++ b/doc/rfc/rfc2774.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                          H. Nielsen
+Request for Comments: 2774                                       P. Leach
+Category: Experimental                                          Microsoft
+                                                              S. Lawrence
+                                                          Agranat Systems
+                                                            February 2000
+
+
+                      An HTTP Extension Framework
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+IESG Note
+
+   This document was originally requested for Proposed Standard status.
+   However, due to mixed reviews during Last Call and within the HTTP
+   working group, it is being published as an Experimental document.
+   This is not necessarily an indication of technical flaws in the
+   document; rather, there is a more general concern about whether this
+   document actually represents community consensus regarding the
+   evolution of HTTP.  Additional study and discussion are needed before
+   this can be determined.
+
+   Note also that when HTTP is used as a substrate for other protocols,
+   it may be necessary or appropriate to use other extension mechanisms
+   in addition to, or instead of, those defined here.  This document
+   should therefore not be taken as a blueprint for adding extensions to
+   HTTP, but it defines mechanisms that might be useful in such
+   circumstances.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                      [Page 1]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+Abstract
+
+   A wide range of applications have proposed various extensions of the
+   HTTP protocol. Current efforts span an enormous range, including
+   distributed authoring, collaboration, printing, and remote procedure
+   call mechanisms. These HTTP extensions are not coordinated, since
+   there has been no standard framework for defining extensions and
+   thus, separation of concerns. This document describes a generic
+   extension mechanism for HTTP, which is designed to address the
+   tension between private agreement and public specification and to
+   accommodate extension of applications using HTTP clients, servers,
+   and proxies.  The proposal associates each extension with a globally
+   unique identifier, and uses HTTP header fields to carry the extension
+   identifier and related information between the parties involved in
+   the extended communication.
+
+Table of Contents
+
+   1.  Introduction ...............................................3
+   2.  Notational Conventions .....................................3
+   3.  Extension Declarations .....................................4
+    3.1   Header Field Prefixes ...................................5
+   4.  Extension Header Fields ....................................6
+    4.1   End-to-End Extensions ...................................7
+    4.2   Hop-by-Hop Extensions ...................................7
+    4.3   Extension Response Header Fields ........................8
+   5.  Mandatory HTTP Requests ....................................8
+    5.1   Fulfilling a Mandatory Request .........................10
+   6.  Mandatory HTTP Responses ..................................11
+   7.  510 Not Extended ..........................................11
+   8.  Publishing an Extension ...................................11
+   9.  Caching Considerations ....................................12
+   10. Security Considerations ...................................13
+   11. References ................................................13
+   12. Acknowledgements ..........................................14
+   13. Authors' Addresses ........................................14
+   14. Summary of Protocol Interactions ..........................15
+   15. Examples ..................................................16
+    15.1  User Agent to Origin Server ............................16
+    15.2  User Agent to Origin Server via HTTP/1.1 Proxy .........17
+    15.3  User Agent to Origin Server via HTTP/1.0 Proxy .........18
+   Full Copyright Statement ......................................20
+
+
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                      [Page 2]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+1. Introduction
+
+   This proposal is designed to address the tension between private
+   agreement and public specification; and to accommodate dynamic
+   extension of HTTP clients and servers by software components. The
+   kind of extensions capable of being introduced range from:
+
+      o  extending a single HTTP message;
+
+      o  introducing new encodings;
+
+      o  initiating HTTP-derived protocols for new applications; to...
+
+      o  switching to protocols which, once initiated, run independent
+         of the original protocol stack.
+
+   The proposal is intended to be used as follows:
+
+      o  Some party designs and specifies an extension; the party
+         assigns the extension a globally unique URI, and makes one or
+         more representations of the extension available at that address
+         (see section 8).
+
+      o  An HTTP client or server that implements this extension
+         mechanism (hereafter called an agent) declares the use of the
+         extension by referencing its URI in an extension declaration in
+         an HTTP message (see section 3).
+
+      o  The HTTP application which the extension declaration is
+         intended for (hereafter called the ultimate recipient) can
+         deduce how to properly interpret the extended message based on
+         the extension declaration.
+
+   The proposal uses features in HTTP/1.1 but is compatible with
+   HTTP/1.0 applications in such a way that extended applications can
+   coexist with existing HTTP applications. Applications implementing
+   this proposal MUST be based on HTTP/1.1 (or later versions of HTTP).
+
+2. Notational Conventions
+
+   This specification uses the same notational conventions and basic
+   parsing constructs as RFC 2068 [5]. In particular the BNF constructs
+   "token", "quoted-string", "Request-Line", "field-name", and
+   "absoluteURI" in this document are to be interpreted as described in
+   RFC 2068 [5].
+
+
+
+
+
+
+Nielsen, et al.               Experimental                      [Page 3]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [6].
+
+   This proposal does not rely on particular features defined in URLs
+   [8] that cannot potentially be expressed using URNs (see section 8).
+   Therefore, the more generic term URI [8] is used throughout the
+   specification.
+
+3. Extension Declarations
+
+   An extension declaration can be used to indicate that an extension
+   has been applied to a message and possibly to reserve a part of the
+   header namespace identified by a header field prefix (see 3.1). This
+   section defines the extension declaration itself; section 4 defines a
+   set of header fields using the extension declaration.
+
+   This specification does not define any ramifications of applying an
+   extension to a message nor whether two extensions can or cannot
+   logically coexist within the same message. It is simply a framework
+   for describing which extensions have been applied and what the
+   ultimate recipient either must or may do in order to properly
+   interpret any extension declarations within that message.
+
+   The grammar for an extension declaration is as follows:
+
+       ext-decl        = <"> ( absoluteURI | field-name ) <">
+                         [ namespace ] [ decl-extensions ]
+
+       namespace       = ";" "ns" "=" header-prefix
+       header-prefix   = 2*DIGIT
+
+       decl-extensions = *( decl-ext )
+       decl-ext        = ";" token [ "=" ( token | quoted-string ) ]
+
+   An extension is identified by an absolute, globally unique URI or a
+   field-name. A field-name MUST specify a header field uniquely defined
+   in an IETF Standards Track RFC [3]. A URI can unambiguously be
+   distinguished from a field-name by the presence of a colon (":").
+
+   The support for header field names as extension identifiers provides
+   a transition strategy from decentralized extensions to extensions
+   defined by IETF Standards Track RFCs until a mapping between the
+   globally unique URI space and features defined in IETF Standards
+   Track RFCs has been defined according to the guidelines described in
+   section 8.
+
+
+
+
+
+Nielsen, et al.               Experimental                      [Page 4]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+   Examples of extension declarations are
+
+       "http://www.company.com/extension"; ns=11
+       "Range"
+
+   An agent MAY use the decl-extensions mechanism to include optional
+   extension declaration parameters but cannot assume these parameters
+   to be recognized by the recipient. An agent MUST NOT use decl-
+   extensions to pass extension instance data, which MAY be passed using
+   header field prefix values (see section 3.1). Unrecognized decl-ext
+   parameters SHOULD be ignored and MUST NOT be removed by proxies when
+   forwarding the extension declaration.
+
+3.1 Header Field Prefixes
+
+   The header-prefix is a dynamically generated string. All header
+   fields in the message that match this string, using string prefix-
+   matching, belong to that extension declaration. Header field prefixes
+   allow an extension declaration to dynamically reserve a subspace of
+   the header space in a protocol message in order to prevent header
+   field name clashes and to allow multiple declarations using the same
+   extension to be applied to the same message without conflicting.
+
+   Header fields using a header-prefix are of the form:
+
+       prefixed-header = prefix-match field-name
+       prefix-match    = header-prefix "-"
+
+   Linear white space (LWS) MUST NOT be used between the header-prefix
+   and the dash ("-") or between the prefix-match and the field-name.
+   The string prefix matching algorithm is applied to the prefix-match
+   string.
+
+   The format of the prefix using a combination of digits and the dash
+   ("-") guarantees that no extension declaration can reserve the whole
+   header field name space. The header-prefix mechanism was preferred
+   over other solutions for exchanging extension instance parameters
+   because it is header based and therefore allows for easy integration
+   of new extensions with existing HTTP features.
+
+   Agents MUST NOT reuse header-prefix values in the same message unless
+   explicitly allowed by the extension (see section 4.1 for a discussion
+   of the ultimate recipient of an extension declaration).
+
+   Clients SHOULD be as consistent as possible when generating header-
+   prefix values as this facilitates use of the Vary header field in
+   responses that vary as a function of the request extension
+   declaration(s) (see [5], section 13.6).
+
+
+
+Nielsen, et al.               Experimental                      [Page 5]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+   Servers including prefixed-header header fields in a Vary header
+   field value MUST also include the corresponding extension declaration
+   field-name as part of that value. For example, if a response depends
+   on the value of the 16-use-transform header field defined by an
+   optional extension declaration in the request, the Vary header field
+   in the response could look like this:
+
+       Vary: Opt, 16-use-transform
+
+   Note, that header-prefix consistency is no substitute for including
+   an extension declaration in the message: header fields with header-
+   prefix values not defined by an extension declaration in the same
+   message are not defined by this specification.
+
+   Examples of header-prefix values are
+
+       12
+       15
+       23
+
+   Old applications may introduce header fields independent of this
+   extension mechanism, potentially conflicting with header fields
+   introduced by the prefix mechanism. In order to minimize this risk,
+   prefixes MUST contain at least 2 digits.
+
+4. Extension Header Fields
+
+   This proposal introduces two types of extension declaration strength:
+   mandatory and optional, and two types of extension declaration scope:
+   hop-by-hop and end-to-end (see section 4.1 and 4.2).
+
+   A mandatory extension declaration indicates that the ultimate
+   recipient MUST consult and adhere to the rules given by the extension
+   when processing the message or reporting an error (see section 5 and
+   7).
+
+   An optional extension declaration indicates that the ultimate
+   recipient of the extension MAY consult and adhere to the rules given
+   by the extension when processing the message, or ignore the extension
+   declaration completely. An agent may not be able to distinguish
+   whether the ultimate recipient does not understand an extension
+   referred to by an optional extension or simply ignores the extension
+   declaration.
+
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                      [Page 6]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+   The combination of the declaration strength and scope defines a 2x2
+   matrix which is distinguished by four new general HTTP header fields:
+   Man, Opt, C-Man, and C-Opt. (See sections 4.1 and 4.2; also see
+   appendix 14, which has a table of interactions with origin servers
+   and proxies.)
+
+   The header fields are general header fields as they describe which
+   extensions actually are applied to an HTTP message. Optional
+   declarations MAY be applied to any HTTP message if appropriate (see
+   section 5 for how to apply mandatory extension declarations to
+   requests and section 6 for how to apply them to responses).
+
+4.1 End-to-End Extensions
+
+   End-to-end declarations MUST be transmitted to the ultimate recipient
+   of the declaration. The Man and the Opt general header fields are
+   end- to-end header fields and are defined as follows:
+
+       mandatory       = "Man" ":" 1#ext-decl
+       optional        = "Opt" ":" 1#ext-decl
+
+   For example
+
+       HTTP/1.1 200 OK
+       Content-Length: 421
+       Opt: "http://www.digest.org/Digest"; ns=15
+       15-digest: "snfksjgor2tsajkt52"
+       ...
+
+   The ultimate recipient of a mandatory end-to-end extension
+   declaration MUST handle that extension declaration as described in
+   section 5 and 6.
+
+4.2 Hop-by-Hop Extensions
+
+   Hop-by-hop extension declarations are meaningful only for a single
+   HTTP connection. In HTTP/1.1, C-Man, C-Opt, and all header fields
+   with matching header-prefix values defined by C-Man and C-Opt MUST be
+   protected by a Connection header field. That is, these header fields
+   are to be included as Connection header field directives (see [5],
+   section 14.10). The two header fields have the following grammar:
+
+       c-mandatory     = "C-Man" ":" 1#ext-decl
+       c-optional      = "C-Opt" ":" 1#ext-decl
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                      [Page 7]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+   For example
+
+       M-GET / HTTP/1.1
+       Host: some.host
+       C-Man: "http://www.digest.org/ProxyAuth"; ns=14
+       14-Credentials="g5gj262jdw@4df"
+       Connection: C-Man, 14-Credentials
+
+   The ultimate recipient of a mandatory hop-by-hop extension
+   declaration MUST handle that extension declaration as described in
+   section 5 and 6.
+
+4.3 Extension Response Header Fields
+
+   Two extension response header fields are used to indicate that a
+   request containing mandatory extension declarations has been
+   fulfilled by the ultimate recipient as described in section 5.1. The
+   extension response header fields are exclusively intended to serve as
+   extension acknowledgements, and can not carry any other information.
+
+   The Ext header field is used to indicate that all end-to-end
+   mandatory extension declarations in the request were fulfilled:
+
+       ext             = "Ext" ":"
+
+   The C-Ext response header field is used to indicate that all hop-by-
+   hop mandatory extension declarations in the request were fulfilled.
+
+       c-ext           = "C-Ext" ":"
+
+   In HTTP/1.1, the C-Ext header fields MUST be protected by a
+   Connection header (see [5], section 14.10).
+
+   The Ext and the C-Ext header fields are not mutually exclusive; they
+   can both occur within the same message as described in section 5.1.
+
+5. Mandatory HTTP Requests
+
+   An HTTP request is called a mandatory request if it includes at least
+   one mandatory extension declaration (using the Man or the C-Man
+   header fields). The method name of a mandatory request MUST be
+   prefixed by "M-". For example, a client might express the binding
+   rights- management constraints in an HTTP PUT request as follows:
+
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                      [Page 8]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+       M-PUT /a-resource HTTP/1.1
+       Man: "http://www.copyright.org/rights-management"; ns=16
+       16-copyright: http://www.copyright.org/COPYRIGHT.html
+       16-contributions: http://www.copyright.org/PATCHES.html
+       Host: www.w3.org
+       Content-Length: 1203
+       Content-Type: text/html
+
+       <!doctype html ...
+
+   An ultimate recipient conforming to this specification receiving a
+   mandatory request MUST process the request by performing the
+   following actions in the order listed below:
+
+      1. Identify all mandatory extension declarations (both hop-by-hop
+         and end-to-end); the server MAY ignore optional declarations
+         without affecting the result of processing the HTTP message;
+
+      2. Examine all extensions identified in 1) and determine if they
+         are supported for this message. If not, respond with a 510 (Not
+         Extended) status-code (see section 7);
+
+      3. If 2) did not result in a 510 (Not Extended) status code, then
+         process the request according to the semantics of the
+         extensions and of the existing HTTP method name as defined in
+         HTTP/1.1 [5] or later versions of HTTP. The HTTP method name
+         can be obtained by ignoring the "M-" method name prefix.
+
+      4. If the evaluation in 3) was successful and the mandatory
+         request fulfilled, the server MUST respond as defined in
+         section 5.1. A server MUST NOT fulfill a request without
+         understanding and obeying all mandatory extension
+         declaration(s) in a request.
+
+   A proxy that does not act as the ultimate recipient of a mandatory
+   extension declaration MUST NOT remove the extension declaration or
+   the "M-" method name prefix when forwarding the message (see section
+   5.1 for how to detect when a mandatory extension has been fulfilled).
+
+   A server receiving an HTTP/1.0 (or earlier versions of HTTP) message
+   that includes a Connection header MUST, for each connection-token in
+   this field, remove and ignore any header field(s) from the message
+   with the same name as the connection-token.
+
+   A server receiving a mandatory request including the "M-" method name
+   prefix without any mandatory extension declarations to follow MUST
+   return a 510 (Not Extended) response.
+
+
+
+
+Nielsen, et al.               Experimental                      [Page 9]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+   The "M-" prefix is reserved by this proposal and MUST NOT be used by
+   other HTTP extensions.
+
+5.1 Fulfilling a Mandatory Request
+
+   A server MUST NOT claim to have fulfilled any mandatory request
+   unless it understood and obeyed all the mandatory extension
+   declarations in the request. This section defines a mechanism for
+   conveying this information to the client in such a way that it
+   interoperates with existing HTTP applications and prevents broken
+   servers from giving the false impression that an extended request was
+   fulfilled by responding with a 200 (Ok) response without
+   understanding the method.
+
+   If any end-to-end mandatory extension declarations were among the
+   fulfilled extensions then the server MUST include an Ext response
+   header field in the response. In order to avoid that the Ext header
+   field inadvertently is cached in an HTTP/1.1 cache, the response MUST
+   contain a no-cache cache-control directive. If the response is
+   otherwise cachable, the no-cache cache-control directive SHOULD be
+   limited to only affect the Ext header field:
+
+       HTTP/1.1 200 OK
+       Ext:
+       Cache-Control: no-cache="Ext"
+       ...
+
+   If the mandatory request has been forwarded by an HTTP/1.0
+   intermediary proxy then this is indicated either directly in the
+   Request-Line or by the presence of an HTTP/1.1 Via header field. In
+   this case, the server MUST include an Expires header field with a
+   date equal to or earlier than the value of the Date header field (see
+   section 9 for a discussion on caching considerations):
+
+       HTTP/1.1 200 OK
+       Date: Sun, 25 Oct 1998 08:12:31 GMT
+       Expires: Sun, 25 Oct 1998 08:12:31 GMT
+       Ext:
+       Cache-Control: no-cache="Ext", max-age=3600
+       ...
+
+   If any hop-by-hop mandatory extension declarations were among the
+   fulfilled extensions then the server MUST include a C-Ext response
+   header field in the response. The C-Ext header field MUST be
+   protected by a Connection header field (see [5], section 14.10).
+
+
+
+
+
+
+Nielsen, et al.               Experimental                     [Page 10]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+       HTTP/1.1 200 OK
+       C-Ext:
+       Connection: C-Ext
+
+   Note, that the Ext and C-Ext header fields are not mutually
+   exclusive; they can be both be present in a response when  fulfilling
+   mandatory request containing both hop-by-hop as well as end-to-end
+   mandatory extension declarations.
+
+6. Mandatory HTTP Responses
+
+   A server MUST NOT include mandatory extension declarations in an HTTP
+   response unless it is responding to a mandatory HTTP request whose
+   definition allowed for the mandatory response or the server has some
+   a priori knowledge that the recipient can handle the extended
+   response.  A server MAY include optional extension declarations in
+   any HTTP response (see section 4).
+
+   If a client is the ultimate recipient of a mandatory HTTP response
+   containing mandatory extension declarations that either the client
+   does not understand or does not want to use, then it SHOULD discard
+   the complete response as if it were a 500 (Internal Server Error)
+   response.
+
+7. 510 Not Extended
+
+   The policy for accessing the resource has not been met in the
+   request.  The server should send back all the information necessary
+   for the client to issue an extended request. It is outside the scope
+   of this specification to specify how the extensions inform the
+   client.
+
+   If the 510 response contains information about extensions that were
+   not present in the initial request then the client MAY repeat the
+   request if it has reason to believe it can fulfill the extension
+   policy by modifying the request according to the information provided
+   in the 510 response. Otherwise the client MAY present any entity
+   included in the 510 response to the user, since that entity may
+   include relevant diagnostic information.
+
+8. Publishing an Extension
+
+   While the protocol extension definition should be published at the
+   address of the extension identifier, this specification does not
+   require it. The only absolute requirement is that extension
+   identifiers MUST be globally unique identifiers, and that distinct
+   names be used for distinct semantics.
+
+
+
+
+Nielsen, et al.               Experimental                     [Page 11]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+   Likewise, applications are not required to attempt resolving
+   extension identifiers included in an extension declaration. The only
+   absolute requirement is that an application MUST NOT claim
+   conformance with an extension that it does not recognize (regardless
+   of whether it has tried to resolve the extension identifier or not).
+   This document does not provide any policy for how long or how often
+   an application may attempt to resolve an extension identifier.
+
+   The association between the extension identifier and the
+   specification might be made by distributing a specification, which
+   references the extension identifier.
+
+   It is strongly recommended that the integrity and persistence of the
+   extension identifier be maintained and kept unquestioned throughout
+   the lifetime of the extension. Care should be taken not to distribute
+   conflicting specifications that reference the same name. Even when an
+   extension specification is made available at the address of the URI,
+   care must be taken that the specification made available at that
+   address does not change over time. One agent may associate the
+   identifier with the old semantics, while another might associate it
+   with the new semantics.
+
+   The extension definition may be made available in different
+   representations ranging from
+
+      o  a human-readable specification defining the extension semantics
+         (see for example [7]),
+
+      o  downloadable code which implements the semantics defined by the
+         extension,
+
+      o  a formal interface description provided by the extension, to
+
+      o  a machine-readable specification defining the extension
+         semantics.
+
+   For example, a software component that implements the specification
+   may reside at the same address as a human-readable specification
+   (distinguished by content negotiation). The human-readable
+   representation serves to document the extension and encourage
+   deployment, while the software component would allow clients and
+   servers to be dynamically extended.
+
+9. Caching Considerations
+
+   Use of extensions using the syntax defined by this document may have
+   additional implications on the cachability of HTTP response messages
+   other than the ones described in section 5.1.
+
+
+
+Nielsen, et al.               Experimental                     [Page 12]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+   The originator of an extended message should be able to determine
+   from the semantics of the extension whether or not the extension's
+   presence impacts the caching constraints of the response message. If
+   an extension does require tighter constraints on the cachebility of
+   the response, the originator MUST include the appropriate combination
+   of cache header fields (Cache-Control, Vary, Expires) corresponding
+   to the required level of constraints of the extended semantics.
+
+10. Security Considerations
+
+   Dynamic installation of extension facilities as described in the
+   introduction involves software written by one party (the provider of
+   the implementation) to be executed under the authority of another
+   (the party operating the host software). This opens the host party to
+   a variety of "Trojan horse" attacks by the provider, or a malicious
+   third party that forges implementations under a provider's name. See,
+   for example RFC2046 [4], section 4.5.2 for a discussion of these
+   risks.
+
+11. References
+
+   [1]  Crocker, D., "Standard for the Format of ARPA Internet Text
+        Messages", STD 11, RFC 822, August 1982.
+
+   [2]  Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
+        Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part Two: Media Types", RFC 2046, November
+        1996.
+
+   [5]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+        2068, January 1997.
+
+   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [7]  Masinter, L., "Hyper Text Coffee Pot Control Protocol
+        (HTCPCP/1.0)", RFC 2324, 1 April 1998.
+
+   [8]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+
+
+
+
+Nielsen, et al.               Experimental                     [Page 13]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+   [9]  Nielsen, H., Connolly, D. and R. Khare, "PEP - an extension
+        mechanism for HTTP", Work in Progress.
+
+12. Acknowledgements
+
+   Roy Fielding, Rohit Khare, Yaron Y. Goland, and Koen Holtman, deserve
+   special recognition for their efforts in commenting in all phases of
+   this specification. Also thanks to Josh Cohen, Ross Patterson, Jim
+   Gettys, Larry Masinter, and to the people involved in PEP [9].
+
+   The contribution of World Wide Web Consortium (W3C) staff is part of
+   the W3C HTTP Activity (see "http://www.w3.org/Protocols/Activity").
+
+13. Authors' Addresses
+
+   Henrik Frystyk Nielsen
+   Microsoft Corporation
+   1 Microsoft Way
+   Redmond, WA 98052, USA
+
+   EMail: frystyk@microsoft.com
+
+
+   Paul J. Leach
+   Microsoft Corporation
+   1 Microsoft Way
+   Redmond, WA 98052, USA
+
+   EMail: paulle@microsoft.com
+
+
+   Scott Lawrence
+   Agranat Systems, Inc.
+   5 Clocktower Place, Suite 400
+   Maynard, MA 01754, USA
+
+   EMail: lawrence@agranat.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                     [Page 14]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+Appendices
+
+14. Summary of Protocol Interactions
+
+   The following tables summarize the outcome of strength and scope rules
+   of the mandatory proposal of compliant and non-compliant HTTP proxies
+   and origin servers. The summary is intended as a guide and index to
+   the text, but is necessarily cryptic and incomplete. This summary
+   should never be used or referenced separately from the complete
+   specification.
+
+                        Table 1: Origin Server
+
+       Scope            Hop-by-hop                End-to-end
+
+     Strength      Optional     Required    Optional     Required
+                    (may)        (must)       (may)       (must)
+
+   Mandatory     Standard    501 (Not     Standard     501 (Not
+   unsupported   processing  Implemented) processing   Implemented)
+
+   Extension     Standard    510 (Not     Standard     510 (Not
+   unsupported   processing  Extended)    processing   Extended)
+   Extension     Extended    Extended     Extended     Extended
+   supported     processing  processing   processing   processing
+
+
+                         Table 2: Proxy Server
+
+       Scope            Hop-by-hop                End-to-end
+
+     Strength      Optional     Required    Optional     Required
+                    (may)        (must)       (may)       (must)
+
+   Mandatory     Strip       501 (Not     Forward      501 (Not
+   unsupported   extension   Implemented) extension    Implemented)
+                             or tunnel                 or tunnel
+
+   Extension     Strip       510 (Not     Forward      Forward
+   unsupported   extension   Extended)    extension    extension
+
+   Extension     Extended    Extended     Extended     Extended
+   supported     processing  processing   processing,  processing,
+                 and strip   and strip    may strip    may strip
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                     [Page 15]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+15. Examples
+
+   The following examples show various scenarios using mandatory in
+   HTTP/1.1 requests and responses. Information not essential for
+   illustrating the examples is left out (referred to as "...")
+
+15.1 User Agent to Origin Server
+
+               Table 3: User Agent directly to origin server
+
+   Client issues a request M-GET /some-document HTTP/1.1
+   with one optional and   Opt: "http://www.my.com/tracking"
+   one mandatory extension Man: "http://www.foo.com/privacy"
+                           ...
+
+   Origin server accepts   HTTP/1.1 200 OK
+   the mandatory extension Ext:
+   but ignores the         Cache-Control: max-age=120, no-cache="Ext"
+   optional one. The       ...
+   client can not see in
+   this case that the
+   optional extension was
+   ignored.
+
+
+               Table 4: Origin server with Vary header field
+
+   Client issues a request M-GET /p/q HTTP/1.1
+   with one mandatory      Man: "http://www.x.y/transform"; ns=16
+   extension               16-use-transform: xyzzy
+                           ...
+
+   Origin server accepts   HTTP/1.1 200 OK
+   the mandatory but       Ext:
+   indicates that the      Vary: Man, 16-use-transform
+   response varies on the  Date: Sun, 25 Oct 1998 08:12:31 GMT
+   request extension       Expires: Sun, 25 Oct 1998 08:12:31 GMT
+   declaration             Cache-Control: no-cache="Ext", max-age=1000
+                           ...
+
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                     [Page 16]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+15.2 User Agent to Origin Server via HTTP/1.1 Proxy
+
+   These two examples show how an extended request interacts with an
+   HTTP/1.1 proxy.
+
+              Table 5: HTTP/1.1 Proxy forwards extended request
+
+   Client issues a request M-GET /some-document HTTP/1.1
+   with one optional and   C-Opt: "http://www.meter.org/hits"
+   one mandatory hop-by-   C-Man: "http://www.copy.org/rights"
+   hop extension           Connection: C-Opt, C-Man
+                           ...
+
+   HTTP/1.1 proxy forwards M-GET /some-document HTTP/1.1
+   the request and takes   Via: 1.1 new
+   out the connection      ...
+   headers
+
+   Origin server fails as  HTTP/1.1 510 Not Extended
+   the request does not    ...
+   contain any information
+   belonging to the M-GET
+   method
+
+         Table 6: HTTP/1.1 Proxy does not forward extended request
+
+   Client issues a request M-GET /some-document HTTP/1.1
+   with one optional and   C-Opt: "http://www.meter.org/hits"
+   one mandatory hop-by-   C-Man: "http://www.copy.org/rights"
+   hop extension           Connection: C-Opt, C-Man
+                           ...
+
+   HTTP/1.1 proxy refuses  HTTP/1.1 501 Not Implemented
+   to forward the M-GET    ...
+   method and returns an
+   error
+
+   Origin server never
+   sees the extended
+   request
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                     [Page 17]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+15.3 User Agent to Origin Server via HTTP/1.0 Proxy
+
+   These two examples show how an extended request interacts with an
+   HTTP/1.0 proxy in the message path
+
+             Table 7: HTTP/1.0 Proxy forwards extended request
+
+   Client issues a request M-GET /some-document HTTP/1.1
+   with one mandatory      Man: "http://www.price.com/sale"
+   extension               ...
+
+   HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
+   the request as a        Man: "http://www.price.com/sale"
+   HTTP/1.0 request        ...
+   without changing the
+   method
+
+   Origin server accepts   HTTP/1.1 200 OK
+   declaration and returns Ext:
+   a 200 response and an   Date: Sun, 25 Oct 1998 08:12:31 GMT
+   extension               Expires: Sun, 25 Oct 1998 08:12:31 GMT
+   acknowledgement. The    Cache-Control: no-cache="Ext", max-age=600
+   response can be cached  ...
+   by HTTP/1.1 caches for
+   10 minutes.
+
+                Table 8: HTTP/1.0 and HTTP/1.1 Proxy Chain
+
+   Client issues request   M-GET /some-document HTTP/1.1
+   with one mandatory and  Man: "http://www.copy.org/rights"
+   one hop-by-hop optional C-Opt: "http://www.ads.org/noads"
+   extension               Connection: C-Opt
+                           ...
+
+   HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
+   request as HTTP/1.0     Man: "http://www.copy.org/rights"
+   request without         C-Opt: "http://www.ads.org/noads"
+   changing the method and Connection: C-Man
+   without honoring the    ...
+   Connection directives
+
+   HTTP/1.1 proxy deletes  M-GET /some-document HTTP/1.1
+   (and ignores) optional  Man: "http://www.copy.org/rights"
+   extension and forwards  C-Man: "http://www.ads.org/givemeads"
+   the rest including a    Connection: C-Man
+   via header field. It    Via: 1.0 new
+   also add a hop-by-hop   ...
+   mandatory extension
+
+
+
+Nielsen, et al.               Experimental                     [Page 18]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+   Origin server accepts   HTTP/1.1 200 OK
+   both mandatory          Ext:
+   extensions. The         C-Ext
+   response is not         Connection: C-Ext
+   cachable by the         Date: Sun, 25 Oct 1998 08:12:31 GMT
+   HTTP/1.0 cache but can  Expires: Sun, 25 Oct 1998 08:12:31 GMT
+   be cached for 1 hour by Cache-Control: no-cache="Ext", max-age=3600
+   HTTP/1.1 caches.        ...
+
+   HTTP/1.1 proxy removes  HTTP/1.1 200 OK
+   the hop-by-hop          Ext:
+   extension               Date: Sun, 25 Oct 1998 08:12:31 GMT
+   acknowledgement and     Expires: Sun, 25 Oct 1998 08:12:31 GMT
+   forwards the remainder  Cache-Control: no-cache="Ext", max-age=3600
+   of the response.        ...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                     [Page 19]
+
+RFC 2774              An HTTP Extension Framework          February 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nielsen, et al.               Experimental                     [Page 20]
+
-- 
cgit v1.2.3