Eran, agreed that hegemony of DNS and HTTP admins is very important. This
proposal strikes me as relatively clean, but we need to vet it thoroughly.
I put it first on the agenda for tomorrow's XRI TC call.
=Drummond
> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:]
> Sent: Wednesday, January 07, 2009 3:41 PM
> To:
> Cc: David Orchard; Jonathan Rees; Mark Nottingham
> Subject: [xri] Designating DNS discovery for non-HTTP URIs
>
> 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.
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
