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

Re: Conventions for Sharing User Agent Profiles

From: David W. Morris <dwm@shell.portal.com>
Date: Wed, 14 Aug 1996 17:38:56 -0700 (PDT)
To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.SUN.3.93.960814172743.11308C-100000@jobe.shell.portal.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1351

On Wed, 14 Aug 1996, Jeffrey Mogul wrote:

>     Also, the bit about the signing of the profiles might need a little
>     thought, because it isn't necessarily the vendor that you want to
>     have being responsible for the profile.  Vendors might be less
>     likely to note bugs or count them as worth including.
> The vendor is an obvious choice, both because the browser vendor
> has an obvious incentive to keep the user relatively happy (at

I'll say it again... vendors have already demonstrated they don't rate
the trust to be designed in as the sole source of the profile information.
One well known vendor was statistically sampling bug reports 1-1/2 years
ago. What they are doing now, I haven't heard but as an ISV I can't
tolerate a solution which leaves my customers wondering if the profile
will be maintained.

> least, until the browser market is back to being dominated by
> a single vendor!) and because if you don't trust the vendor
> who gave you the browser binary in the first place, you can't
> really trust anything done with a browser profile.

There is trust where intent is involved and there is trust where 
the issue of things falling thru the cracks is involved. I am not
suggesting evil intent ... a bug is a bug.

Furthermore, the original suggestion did not involved the browser at 
all and a solution only need depend on the browser correctly and
uniquely identifying its identity. Some other collaborative repository
owned by the content suppliers can provide the actual data base ...
or the effective profile can be a compendium of multiple sources.

If we work on this issue, it needs to address coding and precedence for
merging first. Storage and exchange is a secondary issue.

Dave Morris
Received on Wednesday, 14 August 1996 17:44:31 UTC

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