[6372] in www-talk@info.cern.ch
Re: Versioning HTML at the server and Accept-inline
daemon@ATHENA.MIT.EDU (Kee Hinckley)
Thu Oct 27 16:14:46 1994
Date: Thu, 27 Oct 1994 21:03:26 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: nazgul@wraith.utopia.com
From: nazgul@wraith.utopia.com (Kee Hinckley)
To: Multiple recipients of list <www-talk@www0.cern.ch>
[@!$#! pain exporting my mail messages so I can reply to www messages
without crashing people's mailers. Ack. No response from the developer
of the listserv software yet.]
> No, you don't need to send a bug report to Spry. AIR Mosaic does indeed only
> send Accept: headers for the inline image types (currently only image/gif and
> image/xbm) that it knows how to handle. :^) However, this does NOT solve
> the problem in the long run. What happens when we move to a system that
> requests the document _AND_ its components (e.g. inline images) via either an
> MGET or a smart server with multipart MIME handling? At that point, we are
Ah. That's a problem. Sounds like we're back to my original proposal
of a separate set of Accept headers.
> >> >> So then you might have a browser that supported (this
> >> >> isn't a syntax, it's a concept) HTML/2.0+IMG_ALIGN/1.0+MAILTO/1.0
> >> >Ugh.
> > ...
> >Okay, so you could do HTML/2.0+Mozilla
> >...
> >The problem with having an entirely new type is that you now put the
> >onus on the user to add that type to their list of accepted ones, or
> >else you put them in a situation where their browser will claim not
> >to be able to read certain documents which in fact it could read, just
> >not well.
>
> You've just kind of contradicted yourself - doing an "HTML/2.0+Mozilla"
> scheme would also require the user deliberately specifying that their
> browser can handle those extensions, so where's the win? At any rate,
I was assuming that browsers would handle a whole new type (x-mozilla-html)
different than a version difference on a known type.
Your points on a strong standard are reasonable.
