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

Re: Conventions for Sharing User Agent Profiles

From: Shel Kaphan <sjk@amazon.com>
Date: Mon, 12 Aug 1996 11:26:17 -0700 (PDT)
Message-Id: <199608121826.LAA15264@piranha.amazon.com>
To: jg@zorch.w3.org
Cc: hallam@etna.ai.mit.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1313
jg@zorch.w3.org writes:
 > 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.
 > 				- Jim

I definitely like the level of indirection implied by using a URL for
this, but I don't like the reliance it puts on a specific "profile
server" being available.  It doesn't sounds like a solution that
scales all that well.  Let's not underestimate the number of servers
that may exist in the future.  Can we "prove" that the number of
servers and number of different UAs is sufficiently small to allow
this kind of scheme to work?

Instead of using a URL, could we not arrange to use the USER_AGENT
string as a key to databases maintained by replicated servers, using
some standardized URL-based addressing scheme to fetch the profile
document associated with a specific user agent?  Then it would be a
matter of server configuration to tell it where to look for this database.
It has a bit of the flavor of DNS.

Received on Monday, 12 August 1996 11:47:55 UTC

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