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

>>Well, you DID say */*;q=.9.... Try */*;q=.01.... 
>
>*/*;q=.01 is almost the same as not using any * in the Accept header.

No.  Both have problems, which you adequately described in your 'list of 4'
message, but those problems are completely different.  (Low qs documents VS
Reactive negotiation round trips)

>See the discussion of the second case in my original message for the
>disadvantages of that.
>>- send small Accept without *: risk getting responses with inferior quality

Separate issue.  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.

>>And I don't think the case
>>of a server trying really hard to force a particular MIME type down a user
>>agent's throats is going to be a frequent one.
>
>The case I discussed was the case of the mime type with the best
>_source_ quality not being listed in the Accept header.  This is a
>frequent one.

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

[Sidebar: I have a problem with the way the spec describes the computation
of Q.  The q*qs*ql*qc*qe algorithm seem to me to be a server implementation
decision.  but if we stick with requiring servers to perform that algorithm,
then what does become an implementation issue is the choice of q's and qs's.
It's obvious to me that the variation in qs should be much smaller than the
variation in q, because the user's wishes are more important than the
server's wishes.  But that's not obvious from a reading of the spec.  I see
qs as being a factor that distinguishes between two MIME types that the user
is basically apathetic about.  I'd rather see qs defined to be between .8
and 1.  But maybe that's just me.]

>  With short enough Accept headers, it occurs whenever a
>document not written in HTML (but in tex, latex, word, wordperfect,
>...) is published, both in the original form and in a (much less
>attractive) HTML form, on the web.

Most people will not have a yen for including 5 different word/document
processing applications to be externally launched as they browse the web.  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.  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.

>>  Negotiation is going to come
>>into play mostly for deciding whether to send a GIF or a JPG, and servers
>>will generally trust the UA's preferences when it comes to
>>negotiation.
>Trust has nothing to do with it.  This is not about the UA's q values,
>it is about qs, source quality values.

When I say trust, I mean to indicate that the average server will care very
little about it's own concept of source quality (if it even has a such a
concept), and will use the UA's preferences fully for content negotiation.

>You Have Greatly Misunderstood The Purpose Of Content Negotiation.

You haven't convinced me of that.  Even with the really impressive use of
capital letters.

>Negotiation is _not_ about making the client software `happy' because
>it gets a format that can be displayed internally.  
>
>It is about making the _user_ happy by making the client retrieve and
>display the format that has the highest overall quality.

I still don't think these things are that different.  90% of the users on
this planet will be very content with only HTML documents.  90% of those
left will be perfectly content with HTML or word-processor-X documents.
Good UA's will let the user send out Accept headers indicating such.
Documents that can't be rendered are practically useless to a user, no
matter how nicely formatted the server thinks they are.  People like us
computer guys who will have framemaker, AND postscript viewers, AND word,
AND latex, AND tex will be complete aberrations.

>The user will not be happy if the client does a `save as' for a format
>the user likely has no viewer for anyway, 

This is why I recommend an incredibly low q for */*.  Separate problem.

>nor if the client displays a
>crappy html version of a tex document while a much better dvi version
>could have been displayed.

This is true, but it's a somewhat contrived case.  A contrived case can
probably be made for any scheme we plan.

>Problems without a fix are not problems?

Yes... Then they are just laws of physics, facts of life, etc...  I don't
think of not being able to teleport a problem.

>too.  My fix would however lead to reactive negotiation on only a
>small percentage of all URI's.

I agree that is desirable, and am increasingly open to the idea of sending
out 300 responses in cases other than those currently described in the spec.

>>A.  if (q[maxQitem] != maxq)
>>        then send 300
>
B.
>     if ( every maxQitem was derived from a media _range_ (something
>          with *) in the Accept header )
>        then you should send a 300.

A. might be better.  (And not just because I thought of it :)  Again
presuming that fully specified MIME types are listed with higher q's than
media ranges, they would be effectively the same.  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" if they don't place their q's in that order.

>>PS: With keepalives, reactive neg. becomes alot cheaper.  Maybe 300's
>>should be sent under a greater number of circumstances on a keepalive
>>connection?
>
>No.  With keepalives, round trip times for reactive negotiation do not
>go away, 

Round trip time - (tear down & reopen time) << round trip time, so yes, it
does become much cheaper.  You seem intent on contradicting me on every turn?

>>  Did I just make an evil statement?
>You just made a wrong statement.

My statement was correct.  But then, yes, *everything* becomes cheaper with
keepalives.  [The subtlety of my 'evil' remark may have been lost.  I found
the idea of behaving differently based on browser capabilities (keepalive
enabled) uncomfortable.  Probably because I've been on the wrong side of
user-agent-based table-sending servers before.]
-----
Dan DuBois, Software Animal                          ddubois@spyglass.com
(708) 505-1010 x532                     http://www.spyglass.com/~ddubois/

Received on Monday, 11 September 1995 09:02:45 UTC