Subject: Re: [urn] 2141bis Section 5 Conformance consensus

From: John C Klensin <[email-masked]>
Date: Fri, 12 Dec 2014 16:11:05 -0500

--On Thursday, November 20, 2014 14:33 +0000 "Henry S. Thompson"
<[email-masked]> wrote:

> Julian Reschke writes:
> 
>>> 5. URI Conformance
>>> 
>>> 
>>>    Because a URN is, syntactically, a URI under the "urn"
>>>    scheme, in theory a URN can be placed in any protocol
>>>    slot that allows for a URI (e.g., an XML namespace name
>>>    [XML-NAMES]).  However, this does not imply that,
>>>    semantically, it makes sense in practice to place a URN
>> 
>> maybe s/makes sense/always makes sense/
> 
> Yes, this is very important.
>...
>> It's not clear to me why it would be wrong to use a URN in
>> a/@href.
> 
> In fact, it's clear to me that it will often make sense to use
> URNs in a/@href and even image/@src, and it will become
> increasingly common to do so, if implementation of
> registerProtocolHandler [1] becomes widespread.  I note that
> 'urn' is already specified as a whitelisted (i.e. open to have
> a handler registered).
>...

Henry,

Without having a strong position on the specifics of the a/@href
question, we come back to the comment I made earlier.  URNs may
be just names, with no notion of an associated object.  Even a
URN namespace that is typically associated with objects, like
the ISBN one, isn't obviously clear about that -- to go back to
a discussion the WG had parts of a long time ago, sometimes an
ISBN may be a reference to a book.  It is still not a locator
for a book.  Through an indirection process, it might be used to
find a copy of the book, but that indirection ("resolution")
process is not inherently bound to the URN because the URN could
also be used to find pictures of the binding of the book, a
discussion of typestyles used in the book, and any number of
other things.  

Now 3986 and the associated documents could have included the
notion of either some recursion operations or two different
kinds of URI, one of which (sometimes?) gets mapped into one of
the others.  <a> elements could be expanded to include, not only
a URI but instructions as to what to do with it (as far as I
know, they have been -- I haven't been following that work).  Or
one could take a more strict "locator" point of view for a/@href
and adopt the sort of slightly bizarre
   http://example.com/...?urn="..."
model I discussed on-list and in Appendix B.3 of
draft-ietf-urnbis-semantics-clarif-00.

I'm ok with changing the statements to use "not always" and "may
not be appropriate", but I'm opposed to this WG getting into an
argument about what is or is not appropriate to include in a
particular HTML element.  Let the folks who are trying to
produce and document new versions of HTML sort that out, specify
whatever semantics make sense to them, and, if they can figure
out in a sufficient generic way what they want to do with URNs,
more power to them.

best,
    john