W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Problems with content negotiation (was: Re: Preemptive and

From: Daniel DuBois <ddubois@rafiki.spyglass.com>
Date: Tue, 12 Sep 1995 12:08:01 -0500
Message-Id: <9509121708.AA15264@rafiki.spyglass.com>
To: Koen Holtman <koen@win.tue.nl>, Daniel DuBois <ddubois@rafiki.spyglass.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>> I'd rather see qs defined to be between .8
>>and 1.  But maybe that's just me.
>I don't want such a restriction on qs.  I think I have a completely
>different interpretation of qs: I see a low qs as an advice against

Well, a qs of zero in nonsensical.  It makes a variant completely
unservable.  Why is it even on the server.  (Why even serve a document
that's of "very bad quality")  But a q of 0 has important functionality.  So
in a 'theory' sense there must be something fundamentally different between
q and qs, and hence a multiplication of the two might not be an appropriate
algorythm to determine what to send.

>1           = very good quality
>1<x<=0.75   = good quality
>0.75<x<=0.5 = acceptable quality
>0.5<x<=0.25 = bad quality
>0.25<x<0    = very bad quality
>0           = unacceptable quality

This would be an improvement certainly, if not the answer.

>>And this allows for
>>someone to say "I really don't want text/plain no matter what, and no I
>>don't want to renegotiate"
>You can already say that with
> text/plain;q=0
>in the Accept header, irrespective of whether A or B is chosen as the
>`when to send 300' definition.

Sorry.  I didn't say what I meant at all. I was thinking of something like
"Accept:text/plain;q=.1, */*".  I should have described this as "I prefer
anything over text/plain, and I don't want to reactively negotiate".  */*
under the Koen Scheme would trigger a 300.

That's certainly a contrived example.  Maybe we just need a "reactive
negotiation is way OK with me" directive.  "Accept-300s"...

A.  if (q[maxQitem] != maxq)
        then send 300
B.  if (every maxQitem was derived from a media range)
        then send 300.

If we have no directive, then one of the above, or an as-of-yet unproposed
algorythm similiar to the above should be settled on as a way of generating
a 300 response.  Any other opinion on this besides me and Koen?

>it should, if possible, be made in such a way that there is no
>tradeoff between shortening accept headers and risking inferior

C.  if (q[maxQi] != maxq) && (qs[maxQi] != maxqs)
        then send 300
D.  if (q[maxQi] != maxq) && (qs[maxQi] != maxqs) && (ql[maxQi] != maxql)
        then send 300
E.  if (maxQ != 1)
        then send 300
F. if (minqs == maxqs)
        then only send 300 as specd (on multiple maxQs)
G. ???

Which is the most flexible, powerful, simplest, and 'best' way to go I have
no clue.
Dan DuBois, Software Animal                          ddubois@spyglass.com
(708) 505-1010 x532                     http://www.spyglass.com/~ddubois/
Received on Tuesday, 12 September 1995 10:12:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC