<html>
<body>
<font size=3>I like what Michael Graves wrote at 10:13 AM 11/19/2005 (my
time). I'm running out the door now, but will send something to the
list this weekend.<br><br>
<br>
<blockquote type=cite class=cite cite="">1. As someone working on plans
to support YADIS/OpenID/LID in some of our core <br>
infrastructure - ping servers, trackback engines, reputation systems,
<br>
tagging/metadata frameworks, etc. - the concern here for us and service
<br>
providers like us isn't *bandwidth* per se. CPU cycles are important to
<br>
conserve, but the down side of multiple fetches is really tied to *time*
<br>
delays, rather than the bandwidth an additional step would consume. Not
saying <br>
bandwidth shouldn't be a concern -- hold on, yes I am. Bandwidth is
something <br>
we should happily trade off for better adoption and flexibility.
<br><br>
Identity systems do not fail because they are bandwidth hogs.<br><br>
2. One of the profound advantages of OpenID is what I've come to call
<br>
the "ISO" -- "in spite of" -- factor. OpenID has a
high "in spite of" <br>
advantage; users can boot strap their own URLs with little or no help
from the <br>
service provider of the actual URL. As long as I have control over the
HTML <br>
that is being served, I don't need anything from my service provider to
play, <br>
just a way to edit the <head> section of my HTML page.<br><br>
This is such a small, humble-looking feature, that it's *very* easy to
<br>
overlook or underweight its importance. <br><br>
3. Johannes and I have discussed this, but I think it's worth pointing
out. A <br>
CGI call is impossible (with standard configurations) to serve with a
static <br>
file. If my request looks like this:<br><br>
<a href="http://idserver.net/mgraves?meta=capabilities" eudora="autourl">
http://idserver.net/mgraves?meta=capabilities</a><br><br>
I'm stuck if I don't have control over my Apache environment. Even then,
<br>
there's a mod that must be bolted on to Apache to support the semantics
of the <br>
CGI. Now if my request is:<br><br>
<a href="http://idserver.net/mgraves/yadis.xml" eudora="autourl">
http://idserver.net/mgraves/yadis.xml</a><br><br>
I've now got the ability as a user to "bootstrap" myself, by
starting up <br>
notepad, and configuring the file as needed, and saving it to <br>
<a href="http://idserver.net/mgraves/" eudora="autourl">
http://idserver.net/mgraves/</a><br><br>
The interesting thing here is that orienting things toward static file
<br>
semantics ( GET "yadis.xml" vs. CGI call) does *not* hinder the
service <br>
provider from serving static file requests with dynamic responses. In
other <br>
words, this URL:<br><br>
<a href="http://idserver.net/mgraves/yadis.xml" eudora="autourl">
http://idserver.net/mgraves/yadis.xml</a><br><br>
is *ostensibly* a static file on the server, but with straightforward
changes <br>
to the Apache configuration, this same URL can be served from a database
or <br>
other resource, rather than just feeding back a static file.
"yadis.xml" may <br>
not exist as a discrete file on any user's home directory for a given
service <br>
provider. It may just be synthesized on demand and spit back as the <br>
appropriate file by Apache.<br><br>
The bottom line here is that URL semantics are not symmetric. Orienting a
<br>
specification around CGI semantics generally *precludes* users from <br>
bootstrapping themselves without the help, knowledge, or permission of
the <br>
host/webserver. Orienting a specification around static file semantics
<br>
(Get "yadis.xml") does *not* preclude service providers from
automating and <br>
virtualizing the serving of "yadis.xml" or any other
"static" request.<br><br>
It is for this reason that I have urged that wherever possible, static
file <br>
semantics be embraced in HTTP requests, as it lets end users work things
out <br>
for themselves independently when needed -- a huge advantage in gaining
<br>
adoption for the spec.<br><br>
(I realize this can't be extended completely. You can ask for a complete
VCard <br>
for example
"<a href="http://idserver.net/mgraves/xvcard.xml" eudora="autourl">
http://idserver.net/mgraves/xvcard.xml</a>", and that can be served
<br>
with a user-edited static file, but that's the simplest case. In the real
<br>
world, the "view" of a VCard is predicated on who's asking.
When you need to <br>
know the identity/credential of the asking party to determine the proper
<br>
response, a simple static file name won't suffice as a request. So the
<br>
question isn't whether parameterized URLs will be necessary -- they will
-- <br>
but whether they will be necessary even for a core minimum functionality.
I'm <br>
currently thinking that a minimal setup would *need* parameterized URLs,
which <br>
would enable the adoption-friendly "notepad principle" to help
this thing <br>
spread.)<br><br>
4. There's some interesting suggestions here about the "ideal"
approach to <br>
this problem -- HTTP OPTIONS, etc. Anything that is going to require
<br>
extensions to conventional behavior of existing web servers is kryponite
for <br>
adoption, however. There are lots of priorities represented on this list,
but <br>
for my part, and for the direction I'd like to see the infrastructure
evolve, <br>
the priority is just one thing: adoption. Anything that slows
adoption <br>
(changes to Apache) should be included grudgingly if at all. "The
great is the <br>
enemy of the good" comes to mind here.<br><br>
5. URL squatting. While Microsoft did its typical blunder in the
"Favicon" <br>
introduction (unregistrered MIME types, etc.), I don't think that the
Wiki is <br>
correct in saying that favicon.ico is an example of what the W3 folks
complain <br>
about as "URI squatting". Also, I don't think I'd even agree
that it works <br>
against the architecture principles of the Web. If it does, then the
<br>
conventional use of "index.html" does too, and it seems we've
learned to live <br>
with that. :-)<br><br>
If you're OK with "index.html" being a *convention* for serving
HTTP requests <br>
on a directory, then I can't see any problem with "yadis.xml"
becoming an <br>
analogous convention to "index.html". Again, this is
straightforward advocacy <br>
of "convention over configuration", but I think that in this
case, it's <br>
crucial for minimizing the amount of accomodation by users and hosts to
<br>
achieve maximum adoption in the shortest possible timeframe.<br><br>
6. Something to consider: Maybe Brad's right and the HTML <head>
section is <br>
all that should ever be changed to configure a URL for being used as an
<br>
OpenID/YADIS-enabled URL. What if we changed the architecture from one
that <br>
relied on the identity URL to answer a bunch of questions, and simply
asked <br>
the identity URL to do one thing: tell us your authoritative identity
server.<br><br>
If we did this, a given URL would only point to the identity server, and
<br>
rather than querying the identity URL for its capabilities, we would
simply <br>
ask the identity server for anything else we needed. (I know Brad will
<br>
probably read this and think "Duh! This is what I've been saying all
<br>
along!"). Instead of asking for this:<br><br>
<a href="http://superhost.com/mgraves/yadis.xml" eudora="autourl">
http://superhost.com/mgraves/yadis.xml</a><br><br>
The identity consumer would determine the delegated ID server for the URL
(a <br>
la OpenID), and ask that server: "What are the capabilities for
<br>
<a href="http://superhost.com/mgraves" eudora="autourl">
http://superhost.com/mgraves</a> ?" <br><br>
Once that indirection is achieved, the game is completely changed in
terms of <br>
the web server semantics. If we simply scrape some HTML to determine the
<br>
delegated ID server for the URL, and carry out everything else with the
ID <br>
server, we have a) minimal (maybe zero) impact on the hosting provider
for the <br>
Identity URL, and maximum flexibility in terms of features for the ID
server.<br><br>
The ID server can be written anyway that's necessary. It's new machinery,
and <br>
has to be developed and deployed somehow anyway. The Host server can't be
<br>
required to change, or adoption will be severely constrained. Right
now I'm <br>
thinking if we just bow to Brad's (and David Recordon's) original
instincts, <br>
and make the Identity URL simply a lightweight pointer to a powerful
Identity <br>
server (based on open standards defined here), then we escape a lot of
the <br>
boxes were are trapped in in this discussion currently.<br><br>
Sorry for such a long rambling post. I've been reading along for a while,
but <br>
just don't have time to chip in here for the most part.<br><br>
-Michael Graves</font></blockquote></body>
</html>