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

Daniel DuBois:
>[Koen Holtman:]
>>[Daniel DuBois:]
>>>Well, you DID say */*;q=.9.... Try */*;q=.01.... 
>>
>>*/*;q=.01 is almost the same as not using any * in the Accept header.
>
>No.

You are right in general.  In my particular example, both q=.9 and
q=.01 would cause the server to send me the text/html version, not the
text/x-tex version.  This is what I meant.

[...]
>Again, I have to object to your use of "inferior quality"
>without qualification.  (I'll try to get in the habit of saying low q
>documents or low qs documents.)  I think we have a fundamental difference in
>our theories.

Yes, our theories seem to be different.  My theory of "inferior
quality" derives from the Q definition in the draft http 1.1 spec, so
my theory takes both qs (source quality) and q (browser-side mime
viewer quality) into account.  Yours seems to disregard source
quality.

My definition of a response with `inferior quality' is: a response
that has a Q function value lower than the maximum Q function value,
where only the alternative representations that are understood at the
browser side count when determining the maximum).  I don't think this
is a very controversial definition.

>I think you're greatly overestimating the usefulness and deployment on the
>qs portion of content negotiation.

It seems that our argument boils down to how important qs is: I think
you are greatly *under*estimating its potential usefulness.

Not that I think that qs is used very much now: my argument is more
along the lines of `using qs will fail if the user has short Accept
headers, this should be fixed to make qs really useful'.

[...]
> 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
taking a particular variant (because the quality of its contents are
lousy).  You seem to think of qs as a means of overriding the mime
type preferences of the user.

Well, the service author does not need qs for that: if the author
absolutely wants you to see a .dvi file, he will just put up a .dvi
file, and no other alternative.  Why bother with negotiation at all if
you want to force some particular type down the user's throat?

As a side remark, maybe the spec does need to specify the `badness' of
partcicular q/qs/qe/... values, e.g.

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 needed to let browser authors/users and service authors
know about the effect of their factors.  With the help of such a
table, you could say that with

  Accept: text/html;q=1, text-xdvi;q=0.25  ,

you only get the .dvi version if the html has a very bad source
quality.  

The table would help service authors at not being too strong in their
negative (qs) advice.

[...]
>Most people will not have a yen for including 5 different word/document
>processing applications to be externally launched as they browse the
>web.

Home PC users would not even have 5 different document vieuwing
applications.  They may however have two applications each supporting
4 versions only: thus already gives 8 mime type variants: too many for
a short Accept header.

But qs negitioation will be mainly important on large office/campus
LANs, where viewers are abundant.  Especially if the office/campus
wants to put all their internal documents (written in, say, either tex
or word) on the local part of the web, mainly for internal use.  In
that case, the html version for the outside world would be relatively
unimportant, and I could imagine it having a much lower source
quality.

>I know I personally would just as soon get a HTMLized version of a word
>document rather than have to wait for word to launch so I can view the
>supposedly superior version.

I would also not like to wait if the HTML version is only marginally
less good.  But for source quality that is a lot less good, and a
document that is long enough, I would not mind waiting a few seconds.

>  And my chosen Accept headers will reflect
>that.  Any server who tries to "out skew"/overrule my q's with their qs's
>will piss me off.

Yes. This is why we need the `meaning of quality factors' table above,
so that the qs value meaning `this html is marginaly less good as the
word version' at the server is unlikely to overrule your `I just hate
to launch word if there is a html version' q in the browser.

[..version A of `when to send a 300'..]
>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.


I think we can go on all day inventing examples of situations where qs
(source quality) is important, or not important, but that is
not my main point.

The bottom line is that, if the spec is to have content negotiation,
it should, if possible, be made in such a way that there is no
tradeoff between shortening accept headers and risking inferior
responses.

Just showing that the tradeoff does not hurt in the situations we can
imagine now, as you are trying to do, is not sufficent.

>Dan DuBois, Software Animal                          ddubois@spyglass.com

Koen.

Received on Tuesday, 12 September 1995 08:59:14 UTC