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

Negotiation comments

From: Paul Sutton <paul@ukweb.com>
Date: Wed, 19 Feb 1997 16:22:23 +0000 (GMT)
To: http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.LNX.3.95.970219161601.31610A-100000@aardvark.localnet>
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 EST

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