W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Conventions for Sharing User Agent Profiles

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Mon, 12 Aug 96 10:52:28 MDT
Message-Id: <9608121752.AA03530@acetes.pa.dec.com>
To: jg@zorch.w3.org
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1310
    If a user agent profile is a URL, rather than some silly static
    database, there is no monopoly involved; a server would just
    fetch the profile from the URL when first talking to the client,
    and cache it.
    Unless such a cache of profiles were tiny, it is very likely that
    any significant server will have profiles for almost any user agent
    in use (and you can roll your own, anyone who has the ability to
    provide a web page, and since this seems to be standard these days
    with Internet accounts by ISP's, this means everyone).
    This is the scheme Simon Spero suggests in his NG work, and it looks
    like a fine one to me.

It has some obvious advantages (indirection is often a Good Idea
in computer systems design), but I can think of several problems
that could make it difficult to implement universally.

How would this work, for example, in an isolated intranet (one
in which, by policy, no access to the Internet is allowed)?  Would
the intranet's operators have to mirror the set of user agent
resources internally, and perhaps rebind the URLs for the browsers
used internally?  Or build a translation table for the internal
servers to use?

How would this work in a flakey Internet (supposing that, in
spite of our current efforts, Internet reliability gets worse
rather than better)?  I.e., a server has a less-than-100% chance
of actually reaching the user-agent-profile URL?

What are the security implications of trusting the Internet
to deliver the correct user agent profile?  (Not that we necessarily
do any better today!)

Anyway, I would guess that if we can come up with a standard
encoding for the u-a-p resource pointed to by a u-a-p URL (and
which would be a prerequisite for any such scheme) then with
a little more effort we might be able to come up with compressed
encoding that could be transmitted in the request headers without
many more bytes that it would take to transmit the u-a-p URL.  And
transmitting it in-band does solve the problems that might arise
from indirection.

So perhaps the first order of business is to think about what the
u-a-p would actually encode, before thinking about what the most
efficient way to transmit it might be.  After all, as you pointed
out in another recent message, special-purpose encodings can yield
impressive compression ratios.

Received on Monday, 12 August 1996 11:05:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC