Designating DNS discovery for non-HTTP URIs

[Eran Hammer-Lahav <eran@hueniverse.com>]

There seems to be strong resistance in various communities to the idea that
an HTTP server can speak authoritatively for non-HTTP URIs. There is also
strong resistance to using DNS as the entry point for resource discovery. At
the same time, it is clear we need to support non-HTTP URIs and there is
strong desire to include a DNS flavor.

My proposed solution is to limit discovery to the three methods: <Link>
element, Link: header, and /site-meta for HTTP URIs, and to use a
"/site-meta"-like solution with a DNS verification for all non-HTTP URIs.

If the resource is an HTTP resource such as: http://example.com/resource/1,
the consumer can look for a <Link> element, Link: header, or fetch
/site-meta and look for a Link-Template record with the appropriate mapping.

But if the resource is not an HTTP resource such as mailto:user@example.com,
the consumer must look for a DNS record for the example.com domain
identifying an HTTP resource using the /site-meta format with the
Link-Template record. Basically, instead of just doing a GET /site-meta, the
consumer must first find out where the non-HTTP /site-meta is located. It
will usually point to /site-meta (the location) but might not.

This will ensure that the DNS admin has full control over discovery
information of non-HTTP URIs and not the HTTP admin. But it will also allow
both HTTP and non-HTTP to use exactly the same /site-meta file and mechanism
for most use cases.

The reason the content of the Link-Template isn't placed directly in the DNS
record is mostly to keep the discovery workflow as uniform as possible, and
to use DNS in the simplest way to increase adoption.

Thoughts?

EHL