Implementing YADIS with no new software

[Christopher E. Granade]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sam Ruby wrote:
> Martin Atkins wrote:
>> With a few changes to the discovery mechanism, I believe that it would
>> be possible to support all this YADIS business with no further
>> implementation.
>>
>> There are two key changes:
>> * The <link> element in the retrieved HTML document, rather than being
>> required to point at an identity server, is instead specified as
>> pointing at a capability document. This doesn't really change much
>> except the terminology used.
>> * The capability declaration document (the x-meta-identity thing) is
>> extended to support the specification of a URL to use as the endpoint
>> for each declared capability.
> 
> Why require two network interactions to simply find a server?
> 
> Why not simply put a single link tag in for each server that you support?
> 
>   <link rel="openid.server" href="OPENID.SERVER">
>   <link rel="lid.server"    href="LID.SERVER">
> 
> If this ever gets to the point where it is unweildy, then one could go
> the route of the meta-identity server:
> 
>   <link rel="meta.server"   href="META.IDENTITY.SERVER">
> 
> I suspect, however, that few of us will find a need for it.
> 
> - Sam Ruby
> 
The trouble, as I have enumerated in other messages, is that many other
things are competing for space in the header. Between DC, FOAF, CC,
etc., it is possible to have the header upwards of 5K. For those pages
which have only YADIS/OID/LID metadata, the kind of scheme you describe
is ideal, but it is important to realize that this is far from the only
 situation that arises.

Put differently, the data model of RDF allows us to specify such things
as (using N3):
<> openid:server <http://www.example.com/>
<> lid:server <http://www.example.com/>
This data, in turn, can be represented by means of <link /> elements, or
by an RDF metadata document. More generally, an N3 statement that starts
with <> can be represented as <link rel="pre.type" href="uri" />, where
pre:type is the RDF type, and where uri is the subject. This
dual-representation can be transparent to developers not well versed
with RDF, as the <link rel="" /> construction is very simple and
straight-forward.

Thus, we can preserve the benefits of both models:
* Easily understood by new developers.
* Powerful enough to support new protocols.
* Metadata can be off-loaded from a dynamically-generated page to a
static page for performance.
* Metadata can be cached client-side for performance.
* Compatible with other RDF-based notations (CC, DC, FOAF).
* Supported by arbitrary XML document types.

- --Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDZ43e0dXuuZr00J4RAmrwAJ48laBH4TiM40JWS0sYiwDJ1jLzxgCfViwY
FXOBiZ9m0GRtw1HxU15ZjBw=
=NPj9
-----END PGP SIGNATURE-----