Please demonstrate how this is done. No fair spreading Fear,
Uncertainty, and Doubt.
>B) Should be shorter (optional marketing gunk has low priority)
This is not just marketing. It's a quality of service issue.
And if we want to start optimizing bytecounts in HTTP headers,
let's do that -- but let's keep the issues separate for now.
>C) Belongs as a comment in From:
OK. We've each said our piece on this.
>>******* II. The business-card authentication scheme
>
>I don't like this proposal, because it combines two orthogonal
>concepts.
>
> 1) A way for users to keep a standard business-card stored in
> the client, so they don't have to re-type it by hand.
>
> 2) authentication, which should never include unnecessary information
I'm really interested in part 2), and only incidentally happy that it
may solve part 1). Which part of the business card is unnecessary? My
proposal is explicitly aimed at information providers who want to
operate under a policy of "give me your card and I'll show you my
stuff" unobtrusively. Are you telling them: "go away -- you can't do
that"?
>Defining a standard business-card format for browsers is a good idea.
>However, I would implement it by also defining standard FORM input
>names, such that when presenting an HTML form for the first time,
>the browser could pre-fill the data fields for field names that
>match its predefined business-card field names.
The server could take the business card auth data and fill in the
form fields in advance. So my proposal covers your needs. Your
proposal _doesn't_ allow for the no-user-interaction case, which
I think is critical.
Daniel W. Connolly "We believe in the interconnectedness of all things"
Research Associate, MIT/W3C PGP: EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21
<connolly@w3.org> http://www.w3.org/hypertext/WWW/People/Connolly