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

Klaus Weide:
[...]
>> >    (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.
>
>Maybe it was wishful thinking that I thought a choice response like the
>following would not be "forbidden" by the basic t.c.n.:
>
>[ for a request of GET http://x.org/paper, as in your examples ]
>
>     HTTP/1.1 200 OK
>     Date: Tue, 11 Jun 1996 20:05:31 GMT
>     Content-Type: text/html
>     Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
>     Content-Length: 5327
>     Cache-control: max-age=604800
>     Content-Location: en/paper.html
>     Alternates: {"en/paper.html" 0.9 {type text/html} {language en}},
>                 {"fr/paper.html" 0.7 {type text/html} {language fr}},
>                 {"en/paper.ps"   1.0 {type application/postscript}
>                     {language en}}
>     Etag: "gonkyyyy;1234"
>     Vary: negotiate, accept, accept-language
>     Expires: Thu, 01 Jan 1980 00:00:00 GMT
>
>     <title>A paper about ....

That response is forbidden because of the content-location.

>While the -negotiation- draft has some special rules and `should's
>regarding variant resources as neighbours of negotiable resource,
>it doesn't state that responses are always invalid if this is not the
>case.  (It seems at least acceptable for list responses).

Ah, you _can_ make a variant list with non-neighboring variants, and I
consider this a definite feature.  It allows you to point to a variant
delivered with a non-http protocol for one thing, as in video streaming.

The only thing you cannot do is send send non-neighboring variants in a
choice response.  I'll add a discussion of this to the start of the choice
response section.

>B.t.w. do the rules of RFC 2068 3.2.3 for comparison of URLs apply when
>determining whether two resources are neighbors?  (Should probably
>be clarified.)

Yes, they do apply.  I'll add a reference.

[...]
>> >- 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.
>
>Since in most cases `Accept header' refers to the general meaning, you
>could use `"Accept" header' for the few other cases.

I don't know.  I'll count occurences to see just how bad this problem is.
Then I may do something.

[...]

>  Klaus

Koen.

Received on Monday, 24 February 1997 11:29:46 UTC