Subject: [urn] Considerations for Relative Resolution of URNs

From: Andrew Newton <[email-masked]>
Date: Tue, 7 Apr 2015 17:29:10 -0400

All,

There has been discussion on this list lately about p-components and
f-components. Some of those discussions center around the ability for
parsers to perform relative resolution on URNs. Past threads on this topic
have shown that relative resolution of other URI schemes can yield unusable
results and relative resolution of URNs can yield non-sensical answers.

Given that relative resolution of URNs is a thorn causing somewhat of a
limp to our forward progress, my inclination is to instruct the document
authors to pull it out. But first I'd like to hear from the group. If you
feel relative resolution of URNs is to remain a consideration, please tell
us why.

-andy, co-chair

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Apr 2015 17:40:29 -0400

On 04/07/2015 05:29 PM, Andrew Newton wrote:
> parsers to perform relative resolution on URNs. Past threads on this 
> topic have shown that relative resolution of other URI schemes can 
> yield unusable results and relative resolution of URNs can yield 
> non-sensical answers.
>
> Given that relative resolution of URNs is a thorn causing somewhat of 
> a limp to our forward progress, my inclination is to instruct the 
> document authors to pull it out. But first I'd like to hear from the 
> group. If you feel relative resolution of URNs is to remain a 
> consideration, please tell us why.
>

Pulling this out looks like ignoring the problem, and I don't think 
ignoring the problem will help.   I suspect it introduces more "known 
technical omissions" that RFC 2026 forbids.

I haven't come to the point where I can make a proposal yet, but I have 
been looking into different options, e.g.:

a) Handle relative references with respect to URNs just as 3986 
specifies, and document the various
constraints on NSS assignment, path component persistence, etc., that 
this implies; or

b) Require that resolution of web content (i.e. content that uses 
3986-style URIs and relative references) be through an intermediate URI, 
(e.g. an http URL) which is treated as a base URI, and that all relative 
references are evaluated relative to that intermediate URI rather than 
the URN.    (This leaves URNs relatively unconstrained and avoids 
burdening them with "web baggage", but still leaves open the question of 
how {f,p,q}-components of a URN are interpreted.)

Keith

---

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Apr 2015 12:19:20 -0400

> technical omissions" that RFC 2026 forbids.

This would not be an omission. It would be a deliberate re-evaluation of
design criteria.

> a) Handle relative references with respect to URNs just as 3986 specifies,
> and document the various
> constraints on NSS assignment, path component persistence, etc., that this
> implies; or
>

If I understand you correctly, this would require us to define relative
resolution of fragments, queries, and paths against all URNs. That is one
option.

I suppose another option is allow each namespace to define relative
resolution.

Either case is better than what we have today, which is a completely
undefined process.

> references are evaluated relative to that intermediate URI rather than the
> URN.    (This leaves URNs relatively unconstrained and avoids burdening
> them with "web baggage", but still leaves open the question of how
> {f,p,q}-components of a URN are interpreted.)
>

An example would be helpful. However, this appears to mean that URN
relative resolution is dependent on the implied URI scheme of the relative
reference or is application context specific.

If we can come to some agreement on how to deal with relative resolution,
that would be good. However, allowing the topic to continue to cause
conflicts is not acceptable.

-andy

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Apr 2015 12:35:27 -0400

On 04/08/2015 12:19 PM, Andrew Newton wrote:
>
>
> On Tue, Apr 7, 2015 at 5:40 PM, Keith Moore 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Pulling this out looks like ignoring the problem, and I don't
>     think ignoring the problem will help.   I suspect it introduces
>     more "known technical omissions" that RFC 2026 forbids.
>
>
> This would not be an omission. It would be a deliberate re-evaluation 
> of design criteria.

I disagree.   Again, I don't think this group is chartered to redefine URNs.

>     I haven't come to the point where I can make a proposal yet, but I
>     have been looking into different options, e.g.:
>
>     constraints on NSS assignment, path component persistence, etc.,
>     that this implies; or
>
>
> If I understand you correctly, this would require us to define 
> relative resolution of fragments, queries, and paths against all URNs. 
> That is one option.

Right.   Of course, 3986 already do this, and it defines relative 
references to URIs purely as a matter of syntax, so the "only syntax" 
choice already leads down this path.   If a URN is permitted to be a 
base URI, and URNs are parsed according to 3986, we effectively have 
relative resolution of fragments, queries, and paths with respect to URNs.

> I suppose another option is allow each namespace to define relative 

Right.   Though that would impair generic handling of URNs by both 
clients and resolution services.

>     3986-style URIs and relative references) be through an
>     intermediate URI, (e.g. an http URL) which is treated as a base
>     URI, and that all relative references are evaluated relative to
>     that intermediate URI rather than the URN.    (This leaves URNs
>     relatively unconstrained and avoids burdening them with "web
>     baggage", but still leaves open the question of how
> relative resolution is dependent on the implied URI scheme of the 
> relative reference or is application context specific.

Yes.   One way to think of it is that URNs aren't specific to "the web", 
they're from a larger domain.   (which is arguably true, since URNs also 
name printed matter, sound recordings, etc.)   But when you use a URN to 
name something that's in "the web", you have to map from that URN to a 
"web" identifier, so that the conventions for evaluating relative 
references to "web" identifiers work within "the web".

Note that there appear to be other options besides just a and b above - 
there are at least subdivisions of either (as you pointed out with a) 
and there are combinations of the two.   I'm still trying to sort out 
the bounds of the options that appear to me to be worth considering (not 
that I'm the arbiter of such things, but putting too many options on the 
table also hinders discussion, so I might as well try to winnow them 
down a bit)

>
> If we can come to some agreement on how to deal with relative 
> resolution, that would be good. However, allowing the topic to 
> continue to cause conflicts is not acceptable.

It's not the topic that's causing conflicts.   The conflicts are 
(mostly) created by the goals of URNs and the language in RFC 3986 that 
forces URL syntax and relative name resolution onto URNs.    If we 
weren't constrained by 3986 syntax, the discussion, and presumably 
resolution of any conflicts, would be much easier.

More generally, we can't address technical problems by ignoring them or 
refusing to discuss them.

Keith