One site-meta to rule them all

Eran & Mark's site-meta proposal is... interesting. I have a gut feel that it's a bit like democracy: The worst method for whole-site discovery, except for all the others. The killer app for this, IMHO, is the ability to solve things like "lookup metadata for user x on domain y" in a general way. An immediate practical application is translating things like email addresses and Jabber IDs, all of the form (user@domain), to something you can perform discovery on.

Other than the embarrassment of hacking another hard-coded magic name alongside favicon.ico and robots.txt, I really only have one issue with the proposal: It requires a directory lookup via an XML document. I have nothing against XML, but it seems like overkill for this purpose.

An alternative would be to use a very, very simple text-based format that is NOT very extensible. Fortunately, there's already a proposal for this type of format from Mark, for a Link header:

Link: http://example.org/ch rel="previous";
       title="previous chapter"

Just for simplicity, we can take the same format and embed it in an application/site-meta document. The sample site-meta XML would then transform into something like this (with newlines delimiting each type of metadata):

/robots.txt rel="robots"
/p3p.xml rel="privacy"
http://other.example.net/example rel="http://example.com/rel"

We lose the ability to use namespaces and inline (embedded) metadata in this site-meta document. Or alternatively, we gain the ability to ignore namespaces and we don't need to download inline metadata we don't care about.

One closing thought: A persistent issue with XML, unfortunately, is problems with cryptographic signatures, primarily due to complexity of signing and verifying something whose canonical representation is really an Infoset rather than a text stream. This hypothetical format, or any of a number close to it in configuration space, could solve that problem easily:

/robots.txt rel="robots"
/p3p.xml rel="privacy"
http://other.example.net/example rel="http://example.com/rel"
data:application/x-pkcs7-signature;base64,iVBORA...rkJggg== rel="signature"

...with some simple rules to determine which octets get signed.