This is one of the options (see my reply to Peter). But it has
to be “Add DNS record to authorize” and not “Add DNS record to forbid”. The
real problem is that an eager HTTP admin will be able to hijack an organization
identity services or other sensitive discovery-based data without anyone having
any control over it. In most companies, there is a clear separation between the
postmaster and webmaster and we need to make sure not to introduce security
issues.
EHL
From:
[mailto:] On Behalf Of David Fuelling
Sent: Thursday, January 08, 2009 7:44 AM
To: Eran Hammer-Lahav
Cc: ; David Orchard; Jonathan Rees; Mark
Nottingham
Subject: Re: [xri] Designating DNS discovery for non-HTTP URIs
On Wed, Jan 7, 2009 at 11:40 PM, Eran Hammer-Lahav <> wrote:
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:,
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.
For non-http URI's, could we be clear to make the DNS verification
authoritative, but optional? That way, if an admin wants to allow an HTTP
server to be authoritative for 'mailto' URI's, this can be done by just not
setting anything in DNS.
Libraries will still need to perform the DNS check, but the fallback behaviour
would be to use /site-meta just like HTTP URI's (as long as we're explicit
about this behaviour).
