Subject: Re: [urn] 2141bis questions - (4) Section 5 on URI Conformance

From: John C Klensin <[email-masked]>
Date: Mon, 02 Feb 2015 16:38:38 -0500

--On Monday, January 26, 2015 13:02 +0900 "\"Martin J. Dürst\""
<[email-masked]> wrote:

> Julian wrote...

>> I believe I asked this before when a variation of this text
>> was proposed before: why wouldn't be appropriate to have a
>> URN in a/@href?
> 
> I think it might be appropriate for some, but not for others.
> So I suggest to change the text to (including Peter's change)
> "it might not be appropriate to place a certain URN" or some
> such.

I think that is more or less what the text I proposed in
response to Peter says.   What changes to it do you believe are
needed?

I think the above illustrations a general issue that we are
having.   Each of us has a slightly (or more than slightly)
different perspective on which types of URNs are important and
how they will be used.   I have as little trouble as Julian
identifying possible URNs that would be appropriate in a/hrefs.
I don't know about his, but many of mine would be URNs that are
themselves location-independent but that resolve, in ways that
are sensitive to the location of the user making the request,
into network-appropriate URLs that can be used to locate and
retrieve the objects.    

IMO, all of us need to be sensitive to the cases that don't
match our expectations and easily-found examples so that we
don't do things that lock those other cases out.  In that
regard, we need to remember that the statements we have been
avoiding, e.g., "URNs are just like any other URI and are
therefore suitable for use an a/hrefs", both constrain what
constitutes a URN and, at least for examples like the one above,
require that an href resolver be able to work recursively when
URI resolution produces a URL rather than producing an object.

IMO, these are really issues for HTML and the definition of
a-elements and what is to be done with them.  And that is
precisely why the text I proposed tries to say "figuring out
whether (and which) URNs are valid in a particular use context
is a problem for that context, not for URNs".  Again, if that
isn't clear or adequate in the text I proposed, please suggest
alternate text.

Note that this situation may shed some light on Sean's comment
about q-components and part of my response to it.   URLs don't
have media types even though many or most URLs identify objects
that do.  So, if f-components are defined as depending on media
types, they cannot be used in a URN that might return a URL
unless they are defined strictly as passing through.... and that
might be incompatible with other types and uses of URNs. 

Because q-components (or even 3986 queries) have no such
limitations, one might, at least in principle, be used to tell
the URN resolver that was going to select among applicable URLs
the location nexus or other information to be used in doing the
selection.  

Before someone mentions it, a fully-functional and reasonably
deterministic semantic web might be an alternative to several
parts of the examples above.  But we don't seem to be there yet
so, to paraphrase Sean, these issues matter and matter now even
if one were to anticipate their mattering less at some point in
the future.

     john