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

Koen Holtman (koen@win.tue.nl)
Thu, 20 Feb 1997 22:26:45 +0100 (MET) 

Klaus Weide:
>
[...]
>Some other remarks:
>
>- 
>--- begin excerpt ---
>|10.5 Extracting a normal response from a choice response
>   [...]
>|  For security reasons (see section 14.2), an extracted normal
>   response may only be cached if the negotiable resource and the
>   variant resource are neighbors.  If they are not neighbors, the
>   proxy should reject the choice response as a probable spoofing
>   attempt and pass on a 502 (bad gateway) error response instead.
>--- end excerpt ---
>(a) The *last* sentence doesn't seem to belong in this section -
>    it is not about extracting or what to do with an extracted "normal"
>    response, but about what to do when a certain kind of choice response
>    is received.

OK, I'll see If I can move it to a better place.

>(b) I don't think a proxy should do this (behaviour of last sentence,
>    i.e. refuse to forward such a choice response to the client.  This
>    is of course different from the "no extracting" rule).
>    (i) The user agent has the same information available as the proxy
>        from the response headers - if proxy forwards the response -
>        to decide whether this is a probable spoofing attempt, if it
>        is concerned about that.  This is already covered in the last
>        paragraph of 11.1 for a t.c.n.-supporting client.  (And a user
>        agent which does not support t.c.n would not get a cached choice
>        response anyway, because it hasn't sent "Negotiate:", right? [*])

Right, except that the server may also choose to send choice responses to
non-negotiating agents.  If it does, the non-negotiatiing agent can get a
choice response.

>        So there is no need for a proxy to play policeman for exchanges
>        in which it may not be involved beyond the usual caching and
>        forwarding.

The general philosophy of the 1.1 caching mechanism is that caches do need
to play policeman.  At least that is my interpretation of Jeff's design, the
Age header requirements are a good example of this philosophy.  This point
is debatable though, and I would not mind to leave out this `should'.

If somebody seconds the idea that the proxy should not police this case,
I'll cut the stuff.

>    (ii) It seems to be a property of the 1.0 rvsa that non-neighboring
>        variants are never returned in a choice response.

If it seems that way, I was not clear enough in the main draft.  The main
draft is supposed to _always_ require this, no matter what the rvsa.  It is
a general security feature after all.  I'll add some more text to make this
clearer.

>(c) Not chaching such a choice response (in addition to not caching the
>    "extracted normal response") is a different matter, no problem with that.
>
>[*] Actually I don't know whether this is true, or under which conditions
>    it is..
>        
>
>- There is an ambiguity in the terminology (maybe throughout all three 
>  drafts), in that "Accept header(s)" mostly refers to all 4 of "Accept:", 
>  "Accept-Charset:", "Accept-Language:", and "Accept-Features:",
>  but in some cases just to "Accept:"
>  (draft-ietf-http-rvsa-v10-00.txt 3.3 qt, 3.4 1., 4.2.1 2nd sentence,
>   4.2.2 are examples)

Yes, this is mainly for stylistic reasons.  I could use `Accept* headers' or
`Accept-* headers' to denote the set, but I think it is ugly.  If you think
that the ambiguity can be confusing, I'll make it uglier and less ambiguous.

>- You use "header" where RFC 2068 uses "header field".  (not necessary
>  a problem, just an observation)

Yes.  Style again.  Everybody says `header' on the list, so that is what I
use.

A related issue: I also don't capitalise MUST, MAY, and SHOULD, again because
it is ugly.  I could be persuaded to change this if enough people want it.

>- In draft-ietf-http-feature-reg-00.txt:
>  Make sure "*" and things starting with '!' cannot be registered.

We will.

>   Klaus

Koen.