Re: Versioning HTML at the server and Accept-inline

Kee Hinckley ([email protected])
Thu, 27 Oct 94 12:55:27 EDT

[@!$#! 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.