Re: distinguishing browser types

Brian said:
>On Mon, 24 Apr 1995, lilley wrote:
>> Brian Behlendorf wrote:
>Alright, I'll concede that - in fact that makes the inline vs. external
>app question have a very nice answer.  Cool.

Now, if only browsers would actually do that... instead, we have hacks on
top of hacks on top of hacks, and nobody dares implement the real spec
because so many broken clients will cause it to behave in unreasonable
ways.  Most urgent is to put a quality value that is less than 1 on
the type */*, unless the client really does mean to say that it can display
every content-type in the entire world completely losslessly.

>> 3) The quality factor for each listed type should be user-editable via
>> some sort of dialog box or whatever.

I've long wanted there to be a quality parameter in mailcap files to allow
specification of exactly that.  The syntax is pretty simple (just
"quality=value") and I think somebody would probably be fairly safe in
implementing it that way.

The quality value is likely an aspect of the viewer used and the hardware
configuration; I don't think it's something users should have cluttering
up their preferences screen.

Here's how I suggested phrasing the spec.  Don't remember what ever happened
to it.
--
The "quality" field specifies the degradation factor associated
with the view-command for this rule.  The value must be a number in
ANSI-C floating point text representation ranging from 1.0 (no
degradation) to 0.0 (total degradation.)  This value should be assumed
to apply to the print command, too, if it exists.  If the quality
field is absent, a default value of 1.0 may be assumed.  Note that
this field SHOULD NOT be considered to override the use of the first
matching mailcap entry.
 
This field has the same semantics and syntax as the "q" parameter for
Accept: headers in HTTP requests {cite the draft for HTTP from the Tim
BL and the IIIR WG} and is primarily intended for use by WWW clients.
However, mail readers may use its value for other quality decisions;
for example, a reader might warn the user not to expect much before
invoking rules with a very low quality, or check whether the
sender-arranged ordering of body parts in a multipart/alternative
entity contradicts quality comparisons.
-- 
		  Marc VanHeyningen  marcvh@spry.com
Disclaimer:
 If this were an official announcement from Spry-CompuServe Internet Division,
 it would have begun with the phrase "FOR IMMEDIATE RELEASE."

Received on Thursday, 27 April 1995 16:17:50 UTC