W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: Comments on draft-ietf-http-negotiation-00.txt

From: Klaus Weide <kweide@tezcat.com>
Date: Thu, 20 Feb 1997 18:33:38 -0600 (CST)
To: Koen Holtman <koen@win.tue.nl>
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.SUN.3.95.970220175814.6072O-100000@xochi.tezcat.com>
On Wed, 19 Feb 1997, Koen Holtman wrote:

> Klaus Weide:
> >
> >16/
> >--- begin excerpt ---
> >|13 Proxy support for transparent negotiation
> >|
> >
> >Section 13 should include a part similar to 12.1 (maybe just a copy from
> >there, with appropriate modifications).
> 
> I did copy some parts (and made a cut-and-paste error).  Which parts
> do you think I should copy in addition?  I'm not aware of any
> omissions.

Most of the requirements may already be there scattered in other
sections, but it would be nice to have them summarized here (parallel
to 12.1).
I am just taking a copy of 12.1 here, changing and annotating it,
to give an idea what I meant:


|13.1 Requirements for proxies [and caches?]

   To implement transparent negotiation [a.k.a. `support t.c.n.',
   a.k.a. `be compliant with this specification'?] on a resource, a proxy
   must be able to [?????] when getting a GET
   request on the resource.  It should also be able to [?????]
   for HEAD requests.  A list response must
   always be sent [or the request be forwarded to the origin server?]
   if the request includes a Negotiate header with only
   a "trans" directive.  If the Negotiate header allows it, the proxy
    may run a remote variant selection algorithm, and if the
   algorithm has sufficient information to choose a best variant, the
   proxy may return a choice response with this variant.
 
   When getting a request without a Negotiate header indicating
   support for transparent content negotiation, the proxy MUST
   forward the request towards the origin server
   [or reply from its cache if allowed by HTTP/1.1 rules, Vary etc.?]
   [and must forward the response towards the client without any other
   changes than those allowed by HTTP/1.1?]

   Negotiability is a binary property: a resource is either
   transparently negotiated, or it is not.  A proxy MUST determine
   whether a resource is transparently negotiated or not by the presence
   of an Alternates header, and [do the stuff that is allowed by this
   draft but otherwise forbidden by HTTP/1.1 only if a resource is
   transparently negotiated.]

   Proxies and caches implementing this spec MUST recognize and obey
   all [some?] cache-control directives defined by HTTP/1.1, even if
   they are not otherwise HTTP/1.1 conformant [i.e. claim only
   HTTP/1.0 version in messages].  [thinking about this sentence 
   from the Introduction: "However, use of
   this extension does not require use of HTTP/1.1: transparent
   content negotiation can also be done if some or all of the parties
   are HTTP/1.0 [3] systems."]

Add whatever is missing, "First" and "Third" from the present section 13 etc.


  Klaus
Received on Thursday, 20 February 1997 16:34:41 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:29 EDT