"until user agents" and resource media diversity

Note:  This is from a thread on the GL list.  William suggested it is an idea
we should share with the Device Independence group.

The summary is a version of "make what you send strict and what you accept
loose."

The "send strict side is that all media you use shall be squeaky clean per
specification."

The "accept loose" side is to accept the incomplete deployment of
standardization achieved by published specifications from W3C and wherever
else.  The way we do this is to "treat ill-supported media features the way we
treat modality-limited media: ensure that there is an alternative that works
well."

In other words it is a parallel application of "eliminate or provide paths
around predictable failure modes."

The rest below is quoted from a message to GL, which was sent with
Subject: [technology - workarounds] Re: .rpm file extension

Al

-- quote

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 Sunday, 11 November 2001 08:21:08 UTC