So I read that as your vote is for prefixing the host name with a
OASIS defined URN.
If we could make it Subject or Host I would be more comfortable with
<Host> but we cant do that in the XSD.
John B.
On 25-Aug-09, at 5:02 PM, Scott Cantor wrote:
> 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
>
>
