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
