[technology - workarounds] Re: .rpm file extension

I want to trace the relationship of this point to the current strucuture of
the
guidelines just a little differently.

At 03:23 PM 2001-10-31 , Charles McCathieNevile wrote:
>There is an issue here - that of correctly configuring software. 

AG::  The issue could also be described as delivering the whole content.  In
the presence of user side vicissitudes.  The type information that guides the
correct interpretation of data is part of the content.  The inconsistency of
user agent type recognition behavior is a fact of Web compliance to standards
that content preparers should understand and work around.

In the guidelines, this hooks in under Guideline 4 (use technology
effectively).

Here there is a missing checkpoint or sub-guideline that follows from the
super-principle
"be strict in what you send, and loose in what you accept."

We have the "be strict in what you send" part, asking content providers to
provide data that conforms to the specifications for the formats used.  And in
particular, as Charles says, if you are using an HTTP server, this includes
getting the Content-Type headers set right when the data encoding your content
are transferred from server to user agent.

What is less well covered is the "be loose in what you accept" category.  Here
it is a matter of User Agent implementation of the specifications which is
what
we accept with a little looseness.  The point is that the content should
not be
critically dependent on provisions in the specification where it is known the
implementation in the field is incomplete or buggy.

So there should be a checkpoint "work around known gaps in standards
deployment."  The detailed description of this one is that where there is a
problem in the consistency or availability of some specification provision,
then if you use it this feature, it generates a redundancy requirement just as
if you had used content in media that is sensory-modality-specific.  The
overall service should under these circumstances contain alternative ways to
achieve the same effect. 

And we don't in Guideline 4 wash our hands of technology because the consensus
process is administered by the IETF and not the W3C.  Not at all.  So when we
say "conform to standards" this does mean that the Content-Type header in the
HTTP transmission should bear metadata which correctly characterizes the data
contained in the body [RFC-822 language] of the data package transmitted.  But
because lots of user agents in the field key off the file extensions, these
should be set well, too.

In the specific case of downloading Red Hat code packages where there is in
the
Windows context a file suffix conflict, the site should be set up to
facilitate
downloading and opening the package with an appropriate application, and not
simply clicking on a link which will by default attempt to play the data as
media if there is a file suffix match.  This is non-ITEF behavior, but it is
common.  So the site should work around this at least to the extent of making
it clear to the user that the download path is safe if there is any problem. 
For Red Hat packages I suspect that a lot of their public is on Windows and I
would argue they have to assume the burden of warning their users that this
mis-application of the data may appear, and how to cope.  It's not spec, it's
life.

Our customers who run websites do care to care for their customers, and we,
whether as WAI or as W3C, should assist them in knowing where the soft
spots in
standards deployment are.  Honesty in this regard is part of our customer
service quality.  We serve the webmasters with standards; we need to be up
front with information about where the standards are not working, and to the
greatest extent possible aid in the development and dissemination of
workarounds until the problem is fixed.

Al

>The problem
>is either that the Web server is sending incorrect information about the type
>of the content (you should be able to find out by looking for file
>information or similar in your browser, or by using a tool like Lynx or
>libwww to get the Header information) or that you browser is not respecting
>that information and trying to guess on its own.
>
>The W3C does not deal with file extensions at all - they are only used in
>Windows and some unix applications anyway. The issue of sending and
>recognising content types is about how to implemenet http, which is now
>developed by the IETF. I presume in the server-sde techniques for WCAG we say
>that servers should be configured correctly - this is one of the things they
>can really do wrong.
>
>Chaals
>
>On Tue, 30 Oct 2001, Jonathan Chetwynd wrote:
>
>  Is there part of w3c that considers file extension names?
>  I was trying to download an .rpm (something like: redhat packet manager)
>  today and found that Real Player Media opens and tries to play it.
>
>  I've been careful to not specify any default applications, and don't appear
>  to have set this up, Real are currently investigating...
>  Obviously as time goes by this type of issue could become more prevalent.
>
>  btw: I tried to set iexplore as the default for .rpm and this naturally
sent
>  it into an infinite loop, anyone have an idea about how to differentiate
>  these very different files under windows?
>
>  jonathan chetwynd
>  IT teacher (LDD)
>  j.chetwynd@btinternet.com
>  <http://www.peepo.com/>http://www.peepo.com         "The first and still
the
best picture directory
>  on the web"
>
>
>-- 
>Charles McCathieNevile   
<http://www.w3.org/People/Charles>http://www.w3.org/People/Charles  phone: +61
409 134 136
>W3C Web Accessibility Initiative    
<http://www.w3.org/WAI>http://www.w3.org/WAI    fax: +1 617 258 5999
>Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
>(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
France)
>

Received on Friday, 9 November 2001 10:14:51 UTC