OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Designating DNS discovery for non-HTTP URIs


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: sappenin@gmail.com [mailto:sappenin@gmail.com] On Behalf Of David Fuelling
Sent: Thursday, January 08, 2009 7:44 AM
To: Eran Hammer-Lahav
Cc: xri@lists.oasis-open.org; 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 <eran@hueniverse.com> 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: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.


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).

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]