Not true. Take, for example, the instance where I have an external viewer
for Targa images, but my browser can't handle them internally (or I don't
want it to, since Targa images tend to be large - perhaps I only want to
allow GIFs.)
>> o An extensions specification.
>> This is most important for the HTML, although again it could apply
>> the rest. 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.
Agreed. It seems like the HTML version, plus a "level" parameter would be
sufficient. It won't determine every little feature supported on the
client, but it will allow the level of support for standardized features
to be determined by the server.
>> scripts, but it doesn't really do much otherwise. So now you need
>> to think about server smarts.
>Which is where you get into problems with the above scheme. What's wrong
>with giving each unique type a unique name (i.e. x-mozilla-html) That's
>much easier than trying to make a server understand all kinds of different
>pieces and how they might fit together (can you say AI).
Seems to be the smartest thing to do, for experimental stuff like a
document making heavy use of the new NetScape tags. In answer to those
who say, "then we'll have 50 million 'x-<insert-client-name>-html' types",
I say not really, because any tags of value will probably make their way
into the standard, and will then become part of the level specifications.
>> on the fly and then cached). Ditto for inline images. This is
>> kind of multi-part alternative where I send them the right alternative
>> and just that alternative.
>That's what Accept: is supposed to be for.
Again, inlined images (and the types that may be supported for them) are
not necessarily the same as externally-handled images. Another example is
that I may want to limit the size of inlined images via the q, mxb and msx
parameters to the Accept-inline (or what) line, while I'll take anything
for externally handled images.
Just a few random thoughts...
-Chris Wilson
:::::::::::::::::::::<<< NETWORKING THE DESKTOP >>>::::::::::::::::::::
Chris Wilson Spry, Inc.
WWW Technology Lead 316 Occidental Avenue S. 2nd Floor
Email: cwilson@spry.com Seattle, WA 98104
Phone: (206) 447-0300 FAX: (206) 447-9008
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::