Re: Content negotiation

> Content negotiation and the type attribute 
> are distinct topics.

Distinct but related.

If we keep them, I'd rather split the checkpoints along the line
author's job/webmaster jobs.
> I would say:
> 1. Serve your documents with the correct Content-Type HTTP header. 
> Include a charset parameter whenever might be ambiguity the encoding.
> [Priority 1]

This is mixed as "serving" the document is a matter of server conf,
while including a charset can be done in HTML.
> 2. When refrering from an HTML document to a document with 
> a MIME type which is not natively undertood to many user agents, 
> specify the type attribute.
> [Priority 3] 

Adding a type attribute to an A is just a more formal way to indicate
the type of the target otherwise done thru the url file extension.

I wonder how many agents use that and how useful it will prove to be
in the field, compare to asking author to indicate the type of the
resource inline, in the text, as in 
 Click here for the <A HREF=foo.pdf>Foo spec in PDF (200K)</A>.

Of course, both can be done.

> The rationale for this is that this may save the user agent 
> work, and reduce internet traffic (I am not sure that this has 
> to do with accessibility). E.g., if the type of an OBJECT is 
> not supported by a browser it can avoid making an HTTP 
> request for it. Or save indexing robots retrieving documents 
> that they can't analize.

They usually do a HEAD to get the content-type, losing a round-trip
but not retrieving the entire document.
> Content negotiation.
> 3. If a resource is served in various formats or languages
> use content negotiation to determine the format/language 
> preferred to the user. [priority 3]

This is a webmaster job, or a combination of webmaster/author (adding
a .conf file locally to indicate binding can be done by the author if
the webmaster allows for it).

> Also provide a "manual option" (e.g., a link) to switch from 
> one version to another. [priority 1]

Yes, this is useful, and there is nothing in HTTP today that let you
do that transparently. Saying it's a P1 now is a little too much I

Overall, I question the accessibility relevance of all this, and I
think it's more usability than anything else.

We started with browser sniffing where some servers just reply "Go get
a real browser" when they see lynx in the User Agent field, but we
seem to have lost this track (I don't see any mention of that

Even as P3, these sounds like very HTML/HTTP generic practices and I'm
not sure we should pursue them.

Received on Wednesday, 27 January 1999 07:03:14 UTC