The deployment strategy has to come first, how can this address a pain
Deployment strategy from whose perspective? The developer -- who's
writing server-side code? Or the update in client?
In both the cases, I think, it's trivial to have a small patch. MS
already gives automatic updates for IE. Task for Mozilla is trivial.
Safari -- Apple as also has automatic updates feature.
From developer's perspective -- most servers, specially J2EE and
.Net based - used a central authentication / tracking system. So do
most of the popular systems in PHP and Perl/CGI.
IMHO, there's no deployment problem. If there needs to be a
demonstration by writing a piece of code, I can patch up Mozilla and
my server-side code. :-)
point that is recognized by the user? What incentives ar there for Web
sites and browser providers?
Websites no longer have to rely on cookie. Several times, as one of
my friends in Yahoo says, users report that they are unable to login
only to find that cookies have been disabled by the proxy server
(transparent or otherwise) in their organizations.
For browsers -- cookies can be disabled by default. For now, cookies
are enabled in "safe" mode. From now on, default configuration can be
even more restrictive (read: secure).
Not sure if I have been able to convince you.... but I think, I
should have succeeded. :D
btw, can you provide details of your proposal that you gave 1995?
And what was Dave's proposal in 1992?
Remember, again, that the ID expires immediately. And there's a
provision to unset. The former addresses Section 2.2.2 of RFC 2964
(pointed out by Florian). The latter addresses what current HTTP
Authentication fails to do -- logout without killing the process /
browser instance.
--
Cheers,
Gaurav Vaish
http://www.mastergaurav.org
http://mastergaurav.blogspot.com
--------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf