Re: Conventions for Sharing User Agent Profiles

Having been in the same meeting as Dave I agree that this is an
important issue. It arose from a discussion with the managers of 
a prominent Web sit in the DC area. Basically the complaint made
was that under the current regime content providers are forced
to apply a lowest common denominator approach. Customising the
content on the basis of the user agent field is very unsatisfactory:

1) It limits competition, sites cannot track every browser's 
capabilities so they tend to track the main browsers in use. This
in turn means that people with non mainstream browsers get the
lowest common denominator even when their site is capable of
handling much more.

2) The User agent is likely to become a smaller part of the package 
in future. In a componentware situation a browser may well have the
ability to upgrade its redering code independently of its protocol
code. This may become an important consideration in future releases
of O/S like Windows 97 where the ability to replace components in
the architecture would appear to be very much part of the idea.

3) The user agent field is badly specified and badly implemented. 
It is treated like a comment field by many browsers. It is not possible
to make a simple extrapolation from the user agent ids passed about 
to the capabilities of the browser.


I see this issue as one which must be addressed while the Web is
still in a relatively fluid stage. Users are still upgrading
browsers, if only because so many out their at the moment crash
every 50 downloads or so.


I see version number on MIME types as a part of a solution to this
problem. This allows a "low watermark" to be established in a cheap
and convenient manner. If a browser advertises text/html; version=3.2
then it had better comply with the standard. The version numbering
scheme could even be extended to provide for beta drafts etc, for
example text/html; version=3.2b24 would refer to W3 Consortium 
draft number 24. Support for 3.2b24 would imply that all features of
3.1 were supported, but not that features of 3.2b23 were necessarily
present - allowing specs to loose features rather than simply
accumulate them.

Private extensions are harder to cope with. One might posit that
each vendor wishing to propose new tags could submit a draft and 
request a draft id number from the standards body for the mime type 
concerned (eg W3C for HTML, Adobe for Postscript, 
Boeing for text/plane).

Another approach would be to introduce an opaque identifier on the
"lets think of a big number unlikely to collide by random chance"
principle and add it to the mime type as a variant :-

text/html; version=3.2c21384498123946123423148976

This is effectively the opaque tag that Dave describes.


Besides this there is a parallel need for the browser to tell the
server about the features that that installation of the code
can support. Eg:-

Are images turned off
Are Animated Gifs disabled
	(Probably the number one item on my browser wish list.
	I have a script that obliterates animated gifs in
	the cache each night but its clunky).
What is the resolution of the screen
What colour models are supported
Is the device linear text or page mode


This is more in the area that Dave's proposal addresses. I think that
both aspect of the problem should be explored.

I like the idea of emulates fields. Note that the objection that
people may not have a 100% emulation is bogus. It would be as 
pointless for Netscape to claim that they supported a feature set
of IE that they did not as for a terminal emulation company with a
VT100 emulator to have it announce itself as VT320. Boasting about
ones abilitites in this area is self policing, the user will simply
get a page of garbage.

One benefit of this approach may be to encourage the vendors to put
a bit more thought into some of the "enhancements" released with 
<blink>perhaps insufficient thought</blink>. Rather than dribble
them out there would be an interest in collecting together a
reasonable package of enhancements and deliver them as a collection
rather than the current trend of "dribbling" them out.


		Phill

Received on Saturday, 10 August 1996 12:51:16 UTC