RE: [xri] XRD for host-meta

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

First, this is mostly an issue for LRDD to deal with (since host-meta will be withdrawn as a separate spec and reintroduced by LRDD using XRD as its schema).

Your analysis is correct and so far I could only come up with two options:

1. Make a special case exception that when the subject is http://example.com/.well-known/host-meta, it is treated differently than any other URIs in that it means the XRD is not about that URI, but about the abstract host entity.

2. Define a new kind of URI that can be used for abstract entities such as "the host" or "the domain" but which is not an http URI because that will bring us right back to #1.

I am going to propose something along the lines of #2. It will either be a new URI scheme or a new URN namespace (most likely 'abstract'). So it will look something like:

urn:abstract:domain:example.com
urn:abstract:host:example.com:8080
urn:abstract:origin:example.com:8080:http

or

abstract://example.com/domain
abstract://example.com:8080/host
abstract://example.com:8080:http/origin

But I need to first float this idea across some key communities (IETF APP Area and W3C TAG).

EHL

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Tuesday, June 09, 2009 10:02 PM
> To: XRI TC
> Subject: [xri] XRD for host-meta
> 
> One of the things talked about at IIW was how there is movement toward
> establishing the "/.well-known/" directory to serve as a container for
> well-known files of various types.  This makes the /host-meta file
> somewhat obsolete for many use cases, since anyone can simply register
> a filename within the .well-known directory directly.  The main group
> left with a real use for host-meta then was the XRD community, as host-
> meta is still the place where you define the Link Pattern used to get
> the XRD document for a given URI.  Since we were the only ones who
> still cared, we generally agreed that it made sense to drop the
> existing plain-text format for host-meta, and instead use XRD.  Two
> major reasons for this:
>   - consumers were going to have to parse XRD anyway, so why use two
> different formats?
>   - host-meta needs to be signed.  XRDs are going to be signable also
> so again, why use two different formats?
> 
> So with that in mind....
> 
> I've recently been going through a number of the XRD use-cases, and I
> can't actually figure out how to use XRD for a host-meta document.
> One particular piece of the puzzle doesn't seem to fit -- what is the
> <Subject> ?  The current host-meta draft states:
> 
> > Note that the metadata provided by a host-meta resource is
> > explicitly scoped to apply to the entire authority (in the URI
> > [RFC3986] sense) associated with it
> 
> host-meta is about an authority, but <Subject> is a URI.  This makes
> sense, because XRD is intended to describe a resource.  Authorities
> are not resources.  You could fudge it by converting the authority
> "example.com" into "http://example.com/";, but now the XRD is just
> wrong.  It's saying that it is describing the specific resource
> "http://example.com/
> ", when it's really intending to describe the entire authority.
> 
> How big of a problem is this?
> 
> I've actually come across a number of potential wrinkles, but this one
> was fairly discrete and easy to explain first.
> 
> -will
> 
> ---------------------------------------------------------------------
> 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