I like to think we've gotten close with Apache.... certain presumptions
were made (an implicit text/html; q=0.5) to account for broken
(excuse me, all :) browsers.
> >> 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.
Why shouldn't the mime-type fields in the mailcap entries look exactly
like the Accept: headers (i.e., why "quality" instead of "q"?).
> 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.
Er, I dunno, my TV at home does a pretty cool job of giving me control over
certain things (contrast, tint, etc) without looking cluttered. q factors
are something that the user might want to change - I'm really interested in
reading the New York Times (and other publications that offer PDF files as
alternatives to HTML) exactly as it looks on paper, so I'll set my
application/pdf setting to 1.0. The browser might even be smart
and group settings by major type and let me set them relatively - i.e.
presents me with a list of all video formats I can see, and I can say
"well I'd really prefer mpeg over quicktime" so it'd set mpeg to 1.0 and
quicktime to 0.9, avi to 0.8, etc... this really could be quite a
powerful mechanism.
> 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.
Good, but I still think "q" should be used. Isn't this really a MIME
issue?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/