- From: Paul Sutton <paul@ukweb.com>
- Date: Wed, 19 Feb 1997 16:22:23 +0000 (GMT)
- To: http-wg@cuckoo.hpl.hp.com
A few points about draft-ieft-http-negotiation-00 ....
1. Section 8.2: the footnote should say "Accept-Charset" not
"Accept-Language"
2. Presence of a Content-Location header on the end-point of a
negotiated resource is taken to indicate that the end-point
was itself negotiated (10.2 item 3). But in Content-Location is
defined in rfc2068 (14.15) as an optional header for any
response.
3. rvsa-version is defined as number "." number, where number is
1*digit. This is unbounded in size, making processing difficult.
Could the size of the two numbers be limited (say to 3DIGIT)
similar to the HTTP-Version in rfc2068
4. 10.3 says that in an ad hoc response "Content-Location" is never
valid. Ad hoc responses are effectively any old HTTP/1.1 response
with Alternates and Vary added. Denying Content-Location in
a standard response conflicts with rfc2068 (14.15) where
Content-Location is valid.
5. 12.1 para 1 says that if the UA cannot do transparent negotiation
the server MUST (my emphasis) only send ad-hoc, choice or list
responses, if the response is 2xx or 3xx (except 304). If I am
reading this correct it means that if a non-negotiating browser
requests a resource from a negotiating server, _even if_ that
resource is not negotiated or negotiated by a custom algorithm the
response must be ad-hoc, choice or list (rather than a response
compatible with rfc2068 alone).
I don't understand the need for this paragraph. Surely if the
server wants to it can choose to use a custom algorithm and return
a standard response, whether or not the UA can support tcn.
Paul
--
Paul Sutton, Technical Director, UK Web ---- http://www.ukweb.com/~paul/
Editor, Apache Week .. the latest Apache news http://www.apacheweek.com/
Received on Wednesday, 19 February 1997 08:28:06 UTC