Subject: [urn] The persistence paragraph

From: John C Klensin <[email-masked]>
Date: Fri, 17 Apr 2015 14:28:53 -0400

Hi.  There was some confusion on the phone about the proposed
persistence paragraph for 2141bis-12.  While it was posted to
the list, it embedded in a much longer note and discussion.
So, for everyone's convenience, here is is again:

> 	(i) Rename the present Section 4 to "Equivalence and
> 	Persistence of URNs".
> 	
> 	(ii) Add a new subsection 4.2, incrementing the number
> 	for the current 4.2 to 4.3, titled "URN Persistence"
> 	that reads:
> 	
> 	For consistency with the "persistence" property
> 	[RFC1737] and as a logical consequence of the
> 	equivalence procedure described immediately above, only
> 	the <assigned-name> (see Section 3 above) are
> 	necessarily treated as persistent.  Individual
> 	namespaces may, however, impose more stringent
> 	requirements on the use of q-components or f-components.

The final sentence may or may not be needed -- that is one of
those relatively minor issues.  Someone, probably Keith, asked
for it and Leslie said in a note earlier today that it was worth
keeping, so anyone who disagrees should speak up.  Even more
important, anyone who thinks the whole paragraph is wrong or
doesn't solve the problem should speak up soon and vigorously.

    john

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Apr 2015 19:24:15 -0400

> doesn't solve the problem should speak up soon and vigorously.

I don't recall asking for the final sentence.  If I did, I no longer 
think it's a good idea based on what seems to be the emerging consensus.

Assuming relative references are to be evaluated with respect to a URL 
that is obtained during resolution or specified in the resource itself,  
I think that implies that the f-component and q-component are not within 
the purview of the namespace, except to the extent that a namespace can 
choose to not assign URNs to resources for which fragments and/or 
queries are meaningful.

More generally, I think only the assigned-name portion of the URN is 
really under control of the namespace.

Keith

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Fri, 17 Apr 2015 20:24:41 -0400

This gets filed under "I want to see the whole document before I feel 
it's clear in my mind."

Leslie.

On 4/17/15 7:24 PM, Keith Moore wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------

---

From: John C Klensin <[email-masked]>
Date: Fri, 17 Apr 2015 21:53:54 -0400

--On Friday, April 17, 2015 19:24 -0400 Keith Moore
<[email-masked]> wrote:

>> for it and Leslie said in a note earlier today that it was
>> worth keeping, so anyone who disagrees should speak up.  Even
>> more important, anyone who thinks the whole paragraph is
>> wrong or doesn't solve the problem should speak up soon and
>> vigorously.
> 
> I don't recall asking for the final sentence.  If I did, I no
> longer think it's a good idea based on what seems to be the
> emerging consensus.

Ok.  We still have an open question about that, which I will
note.

> Assuming relative references are to be evaluated with respect
> to a URL that is obtained during resolution or specified in
> the resource itself,  I think that implies that the
> f-component and q-component are not within the purview of the
> namespace, except to the extent that a namespace can choose to
> not assign URNs to resources for which fragments and/or
> queries are meaningful.
> 
> More generally, I think only the assigned-name portion of the
> URN is really under control of the namespace.

Keith, I'm having trouble mapping "under control of the
namespace" to my view of the world.  With the assumption that
this is at least as likely to be misunderstanding as
disagreement, I think it is quite natural for a namespace
definition to say "<whatever-things-or-abstractions> this
namespace identifies, the following types of q-components are
natural to them, others are not and will be ignored (or
trashed)".  Equally so, I think it is meaningful for a namespace
definition to say "no q-components tolerated here" -- if it is
not, then I wonder what we mean when we say things like "if the
namespace definition does not explicitly permit q-components,
they are invalid".  

Now, "invalid" doesn't mean someone cannot type one.  As was
pointed out on the call, someone can type any sort of nonsense
one can imagine and the fact that it is valid syntax doesn't
mean it has a reasonable interpretation.  It is easy to
construct examples of that for HTTP UPLs -- nothing special
about the URN scheme, much less a namespace.

So, can you explain what "under control of the namespace" means?

thanks,
    john

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Apr 2015 22:51:59 -0400

> So, can you explain what "under control of the namespace" means?

Let me try to describe it in another way:

1. Handling of URNs should be, to the extent reasonable, independent of 
namespace.
2. So when a client of some kind encounters a URN of the form:
*urn:example:foo?bar*
the client's behavior should invariably be to find the resource named by 
*urn:example:foo* and try to transmit "bar" to it (if the protocol via 
which *urn:example:foo* is accessed permits that)
3. Similarly, when a client of some kind encounters a URN of the form:
*urn:example:foo#zot*
the client's behavior should invariably be to try to obtain the content 
named by *urn:example:foo*, and having done that, try to find the 
fragment within named zot (if the client understands the content-type of 
that content, the content-type supports fragments and there is a 
fragment named zot)

So given the above rules, whether namespace example "permits" 
q-components and/or f-components is kind of irrelevant.  In practice, IF 
the name resolves to a resource that accepts queries, the q-component 
will be used as a query, and IF the name resolves to a resource that has 
fragments, the f-component will be interpreted as a fragment name.

A namespace can of course choose what it assigns names to.  So a 
particular namespace could create a policy that says "we won't assign 
names to anything that accepts queries".   However, it's not clear that 
a particular namespace can actually say "we won't assign names to 
anything that contains fragments" and make that stick, because a number 
of fragment types have been defined in such a way that doesn't require 
the content to actually specify those fragments.   For instance, someone 
could standardize a convention that a fragment of the form 
/page-[0-9ivxlcdm]+/ refers to a numbered page in a book, and someone 
could implement software that interpreted such fragments with respect to 
PDF or any other format representing page-oriented content, and in 
practice referencing an ISBN containing an f-component matching that 
regular expression would cause that page to be displayed - even if the 
ISBN namespace refused to assign ISBNs to any resources with explicit 
fragment markers.

Now, we could write rules 2 and 3 above in slightly different ways, and 
get slightly different results.   For instance, we could say IF a URN 
resolves to a URL, then you interpret any q-component of that URN as a 
query to be passed to that URL, and any f-component of that URN as the 
name of a fragment to be attached to that URL.   So if *urn:example:foo* 
resolves to *http://example.com/xyzzy* then *urn:example:foo?bar#zot* is 
interpreted as *http://example.com/xyzzy?bar#zot* .   That keeps 
interpretation of q-components and f-components for resources that 
resolve to URLs consistent with the interpretation of queries and 
fragments for those URLs, and preserves the ability to specify queries 
and fragments with URNs that resolve to URLs.  But it doesn't say 
anything about how q-components and f-components are evaluated for 
resources that don't resolve to URLs.

But I think the latter rules (by themselves) are slightly problematic, 
for two reasons.  One is that it's conceivable that there are multiple 
ways to resolve a resource, some involving URLs and some not.   (e.g. 
you could ask the resolution service for a URL, or you could ask it for 
the resource content directly). Ideally you shouldn't get inconsistent 
behavior with the same content depending on how the URN is resolved.   
The other reason is that the way a resource is resolved could reasonably 
change over time.   So one day it might only be available as physical 
media, and at some later time it might have been scanned and be 
accessible over the Internet.   Ok, maybe this isn't actually a problem, 
except for a namespace that doesn't want to permit fragments to be used 
with its URNs.

It might be important here to emphasize that as a matter of the URN 
architecture, resolution isn't under control of the namespace. The 
namespace can supply a resolution service if it wishes to do so, and it 
might well be a good one.   But we expect resolution services to evolve 
over time for various reasons, and we expect that multiple parties might 
wish to provide resolution services also for various reasons, and 
central points-of-control are quite reasonably regarded as threats to 
information dissemination.   So URNs were designed to not be dependent 
on any particular resolution service.    A client might reasonably query 
several different resolution services in order to try to find 
information about a resource or how to access it.

Keith