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

Klaus Weide:
>
>Here are some comments or suggestions (mostly minor) for
>draft draft-ietf-http-negotiation-00.txt:

Klaus,

Thanks for your careful review.  You found a lot of little errors I
overlooked.  I have read the draft so many times that I have become
blind to some of these things.


>1/
>Somewhere in 4.4:
>--- begin excerpt ---
>|  A server may only choose on behalf of the user agent if the user
>|  agent explicitly allows the use of a particular remote variant
>|  selection algorithm in the Negotiate request header.
>--- end excerpt ---
>
>Replace first "the user agent" with "a user agent supporting
>transparent content negotiation",

OK

> and maybe add the following in
>parentheses: (But see also 4.5).

4.5 (HTTP/1.0 negotiation) does not lead to a choice response as in
the diagram, so I can't really add the reference.

>
>2/
>What exactly does "capable of t.c.n." or "supports t.c.n." mean?
>The expression occurs often enough that it should be added to the
>terms in 2.2... 

Yes, I think it should be added.  Basically, the UAG supports TCN if
it sends a Negotiate header that says so.

>I assume that a server (including a proxy) must be able to determine
>unambiguously whether a request originates from a user agent "capable
>of t.c.n." (e.g. 1/ above and 4.5 require this), if the request is for
>a transparently negotiable resource.  I also assume that the Negotiate
>header is for this purpose.

Yes.

>  But does absense of a Negotiate header
>mean "The user agent does not support t.c.n. (for this request)"?

Yes.  I'll add that explicitly.

>This seems logical, but I did not find it clearly stated. (I may have
>overlooked it though..)
>
>3/
>--- begin excerpt ---
>|8.7 Variant-Vary
>
>   The Variant-Vary response header can be used in a list response to
>                                                     ^^^^^^^^^^^^^(a)
>   record any vary information which applies to the variant data
>                                                    ^^^^^^^^^^^^(b)
>   contained in the response, rather than to the response as a whole.
>--- end excerpt ---
>(a) Should that be "choice response"?

Oops.  Yes.

>(b) The term "variant data" is not explained (I first took it as meaning
>    the same as "variant list").  Suggestion: replace with something 
>    involving  the word "entity", or add term to list in 2.2.

The variant data is really the entity and some of the entity headers,
but there is no convenient word for this concept.  I'll see what I can
do to make it more clear.

>4/
>--- begin excerpt ---
>|9.2 Structured entity tags
>
>   A structured entity tag consists of a normal entity tag of which
>   the opaque string is extended with a semicolon followed by a
>   variant list validator:
>--- end excerpt ---
>
>Replace with
>--- begin excerpt ---
>|9.2 Structured entity tags
>
>   A structured entity tag consists of a normal entity tag of which
>   the opaque string is extended with a semicolon followed by the text
>   (without surrounding quotes) of a variant list validator:
>--- end excerpt ---
>
>Yes this is really a nitpick...

:) OK.  (I usually lean towards writing such nitpicking text myself,
and then get people complaining that the draft is too long.  It is
nice to have some support from fellow nitpickers.)

>
>5/
>--- begin excerpt ---
>10 Content negotiation responses
>
>   [...]
>
>   Transparently negotiated responses with other status codes may also
>   include an Alternates header, if this is allowed by the HTTP/1.1
>   specification [1].  Note that HTTP/1.1 does not allow an Alternates
>   header in a 304 (Not Modified) response.  [...]
>   negotiation, a server must never include an Alternates header.
>--- end excerpt ---
>
>I cannot find anything that forbids an Alternates header field in RFC 2068.
>What comes closest is (section 10.3.5)
>--- begin excerpt ---
>   If the conditional GET used a strong cache validator (see section
>   13.3.3), the response SHOULD NOT include other entity-headers.
>   Otherwise (i.e., the conditional GET used a weak validator), the
>   response MUST NOT include other entity-headers; this prevents
>   inconsistencies between cached entity-bodies and updated headers.
>--- end excerpt ---
>
>But (a) the "MUST NOT" only applies for weak validators,

Oops, I seem to have missed that.  So the negotiation draft should say:

   Note that HTTP/1.1 sometimes disallows an Alternates
   header in a 304 (Not Modified) response.

> and (b) Alternates
>is not an entity-header but a response-header.

Alternates is defined as a response-header in the appendix, but the
appendix is not normative.  I think this implies that 1.1 caches
should treat Alternates as an unknown header, which makes it an
entity-header.

Hmmm.  I could just as well reason the other way around though, and
this would make the draft simpler.

OK, I'll replace 

   Transparently negotiated responses with other status codes may also
   include an Alternates header, if this is allowed by the HTTP/1.1
   specification [1].  Note that HTTP/1.1 does not allow an Alternates
   header in a 304 (Not Modified) response.  [...]
   negotiation, a server must never include an Alternates header.

by


   Transparently negotiated responses with other status codes may also
   include an Alternates header.

It seems safe enough.

>6/
>--- begin excerpt ---
>10 Content negotiation responses
>
>   [...]
>
>|  After having constructed a list, choice, or ad hoc response, a
>|  server may process any If-No-Match or If-Range headers in the
>|  request message and shorten the response to a 304 (Not Modified) or
>|  206 (Partial Content) response, following the rules in the HTTP/1.1
>|  specification [1].  In this case, the entity-ID of the shortened
>|  response will identify it as belonging to a list, choice, or ad-hoc
>|  response.
>--- end excerpt ---
>
>You have not defined entity-ID (at least in this draft).

Oops.  That should be entity _tag_.

>  As a result,
>I don't understand how a 304 response (or a 206 response) carries
>information on the original response code.
>
>7/
>10.2, 3rd paragraph:
>--- begin excerpt ---
>                                   [...]  Section 10.3 specifies how
>                                                  ^^^^
>|  these two items can be obtained by a proxy cache.
>--- end excerpt ---
>
>Should this be 10.4, or maybe 9.x?

Yes, should be 10.4.

>
>8/
>10.2, in description of the algorithm under 2.:
>--- begin excerpt ---
>|          Note: the proxy must be careful not to add entity tags of
>|          non-neighboring variants to the request, as there are no
>|          global uniqueness requirements for these tags.
>--- end excerpt ---
>
>Suggest replacing of "to the request" by "to If-* headers in the request", 
>for clarity.

OK.

>
>9/
>10.2, in description of the algorithm:
>--- begin excerpt ---
>     3. Check for an origin server configuration error. If the HTTP
>        response message generated in step 2 contains an Alternates
>        header, a Content-Location header, or has the 300 status code,
>                  ^^^^^^^^^^^^^^^^
[...]

[Already covered in previous messages.]

>10/
>Change the note under 10.2, 4.a. to
>--- begin excerpt ---
>               Note: According to the HTTP/1.1 specification [1], if
>               the Content-Location header contains a relative URI,
>               this URI is relative to the URI in the Content-Base
>               header, if present, and relative to the Request-URI
>               if no Content-Base header is present.
>--- end excerpt ---

OK.

>
>11/
>In 10.5,  2nd paragraph:
>--- begin excerpt ---
>   [...] This
>   caching of extracted responses can increase overall efficiency with
>   up to a factor 2.
>--- end excerpt ---
>
>How is this number derived, and what does it mean?
>(I.e. how is "overall efficiency" measured?)

Without this optimisation, every variant would have to be transmitted
twice to completely `fill' all applicable cache slots in the cache.
The variant would have to be transmitted once for a cache slot
associated with the negotiable URI, and once more for a cache slot
associated with the variant URI.  By filling both slots at the same
time, you save half of the bandwidth to the upstream server, this is
where the factor 2 comes from.  The overall efficiency is measured as
bandwidth savings on the upstream connection.  The optimisation also
allows you to save on cache memory and revalidations, but this is
secondary.

I'll add an explanation of this factor 2 to the draft.

>12/
>Add part in parentheses to last paragraph of 10.8:
>--- begin excerpt ---
>   Like HTTP/1.1, this specification allows proxies to encode or
>   decode relayed or cached responses on the fly (unless explicitly
>   forbidden by a Cache-Control directive): [...]
>--- end excerpt ---

OK.

>
>13/
>--- begin excerpt ---
>|11 User agent support for transparent negotiation
>
>                                          [...]  If the user agent
>|  contains an internal cache, this cache must satisfy the
>|  requirements for proxy caches in section 13.
>--- end excerpt ---
>
>However, section 13 doesn't list any requirements.

Right, it does not.  What I meant is that the agent cache may perform
all optimisations listed in section 13, following the rules in section
10, but not more.  I'll fix this.

>14/
>In section 12.1, second paragraph:
>--- begin excerpt ---
>|             [...]  The origin server must never return a response
>|  with a 2xx status code or any 3xx status code, except 304, which is
>|  not a list, choice, or ad hoc response.
>--- end excerpt ---
>Add to end of that sentence: 
>", if the request was for a negotiable resource".

Oops.  I'll fix that.  Also, the sentence above the excerpt should
have been axed completely.  I guess this paragraph got garbled in an
editing pass.

>
>15/
>At end of 12.2:
>--- begin excerpt ---
>   See the HTTP/1.1 specification [1] for details on the 303 (See
>   Other) response code.  Note that this response code is not
>   understood by most HTTP/1.0 clients.                ^^^^^^
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>--- end excerpt ---
>
>Is that really the case?

Last time I checked, yes.  Maybe it is not `most clients' anymore, but
it is at least `some clients', unfortunately.  I'll change it to
`some' to be on the safe side.

The 30[123] codes have always been a big mess; this can be traced back
to an editing error one of Tim's early specifications.  I recall that
some versions of Lynx abort the transaction entirely when getting a
303.

>  I know of problems with 300, but not with 303.
>Most clients treat 301 and 302 responses to POST requests like 303 responses
>(to the point that so many Web pages rely on this "feature" that 301 and 302
>responses will probably never be usable as intended...).  I they would 
>at least treat 303 the same way.
>
>16/
>--- begin excerpt ---
>|13 Proxy support for transparent negotiation
>|
>|  Transparent content negotiation is designed to work through any
>|  proxy which only implements the HTTP/1.1 specification [1].  If
>|  Expires headers are added as discussed in section 10.7, negotiation
>|  will also work though HTTP/1.0 proxies.  Thus, in a sense, every
>|  HTTP proxy supports transparent content negotiation.
>
>   Plain HTTP/1.1 allows proxies to cache list, choice, and ad hoc
>   responses, and to efficiently revalidate them by using the
>   If-None-Match header.  This specification defines additional
>   optimization mechanisms.
>--- end excerpt ---
>[Are the next three paragraphs meant as a listing of the additional
> mechanisms, or a listing of old and new mechanisms?  This should be
> made clearer.]

Only of new mechanisms.  I'll make it more clear.


>--- begin excerpt ---
>|  First, when getting a request on a transparently negotiable
>|  resource from a user agent which is capable of transparent content
>|  negotiation (from a user agent which sends a Negotiate header), the
>|  proxy may return a cached, fresh list response from that resource.
>--- end excerpt ---
>This is what a proxy that is not aware of t.c.n. would do,
>if it happens to hold in its cache a cachable 300 response, right?

No, a 1.1 proxy is restricted by the Vary header; it may only do this
if the selecting request headers match.  A TCN proxy may always do it.
I'll add some text making this explicit.

>So it is not really a new mechanism.
>
>--- begin excerpt ---
>|  Second, when allowed by the user agent and origin server, a proxy
>|  may reuse an Alternates header taken from a previous response
>|  (section 10.4) to run a remote variant selection algorithm.  If the
>|  algorithm has sufficient information to choose a best variant, the
>|  origin server may return a choice response with this variant.
>   ^^^^^^^^^^^^^
>--- end excerpt ---
>I assume that should be "proxy"?

Oops, yes.  Cut-and-paste error.

>
>--- end excerpt ---
>|  Third, if a proxy receives a choice response, it may extract and
>|  cache the normal response embedded therein, as described in section
>|  10.5.
>--- end excerpt ---
>
>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.

>  It should also list some
>requirements, especially what a proxy (which understands t.c.n.) MUST
>or SHOULD not do.  For example: A proxy forwarding a request MUST NOT
>add or change a Negotiate header (Is this always true?).

Yes.

>  A proxy MUST
>NOT choose a variant on behalf of the user agent unless specifically
>allowed by a Negotiate header (and not forbidden by an Alternates header's
>proxy-rvsa directive).

True.

The general rule is that a proxy may not do anything which is not
explicitly allowed.  This is really an underlying assumption in both
the 1.1 spec and the TCN draft.  I'll add text which states this
explicitly.

>That's all for now...
>
>   Klaus
>
>P.S. Koen, it would be nice if you could make gewis.win.tue.nl 
>     return a more appropriate Content-Type than text/plain for
>     <URL:http://gewis.win.tue.nl/~koen/conneg/conneg-uax-v1.1.tar.gz>...

Thanks for catching that.  It now returns application/octet-stream.
That is the most appropriate registered type I could find.

Koen.

Received on Wednesday, 19 February 1997 12:53:42 UTC