RE: [xri] Solution for host-meta

["Scott Cantor" <cantor.2@osu.edu>]

John Bradley wrote on 2009-08-25:
> The trust profile for SSL certs is going to have to deal with those
> issues.

Ok. I'm just saying that no matter how you mock up a URI to wrap a host (or
a host/port or scheme/host/port), there's some kind of extraction to do.
Whether it's a URN or a wholly invalid fake URI doesn't change that. My
point was just that if I was making the choice, I'd use a URN that at least
I could defend the validity of.

> In any event we need a URI that can contain the host name for
> hostmeta,  and not be confused with a regular resource URI.

Right. And URNs represent...whatever you define them to represent. That's
what makes them different from URLs, which are always constantly being
confused with web-accessible resources.

There are places where I've come around on that and just accept that URLs
work better, but as we see, identifying a host doesn't seem to be one of
them.

> We are close to http range-14 territory.   If we don't want to
> describe a host as a non-information resource,  what is the URI.
> That is the crux of the problem.

Recall that I argued for not using a URI here, and simply using <Host>.
Having lost that argument, I'm just explaining why I find this idea of
making up URIs that aren't actually URIs but look like them to be rather
silly. A URN is a perfectly valid URI and can mean anything you damn well
please, and OASIS hands them to its TCs for free.

-- Scott