Subject: Re: [apps-discuss] URN "semantics clarification", aka "syntax only" draft

From: Graham Klyne <[email-masked]>
Date: Fri, 20 Feb 2015 10:31:10 +0000

Hi John, all,

(bcc: [email-masked])

I've just taken a skim of 
http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-01, and I think 
the intent is fine but have a couple of questions or points of clarification.

My main concern is that URNs should be considered to be a kind of URI, and 
should be consistently usable in all contexts where a URI is usable (though, 
clearly, use in a context that requires dereferencing would be undefined in the 
same way as use of an unknown URI scheme would be).  Failure to satisfy this 
constraint would, IMO, force a bifurcation between URIs and URNs, which is 
something you say you want to avoid.

This means that not only should they conform to URI syntax, but also should 
conform to RFC3986 URI relative resolution rules.  For example, my code applies 
relative resolution without concern for the URI scheme used.  ("Traditional" 
URNs avoid syntactic constructions that include the possibility of relative 
references.)  (FWIW, I also happen to find that relative references are useful 
in naming contexts as well as retrieval contexts.)

Jumping to section 4, which appears to be the substantive part of this document, 
the main change I am seeing is a change of terminology from "path", "query" and 
"fragment" to "p-component", "q-component" and "f-component".  I take this to be 
a distancing of these elements in URNs from some commonly used conventions used 
with location-based URIs (aka URLs).  To the extent that this helps to reduce 
confusion, this seems fine to me (thought I also think it's an open question as 
to whether new terminology does reduce confusion).

...

You claim:

"In particular, the Generic URI Syntax specification goes beyond
    syntax to specify the meaning and interpretation of various fields,
    especially the "query" and "fragment" ones and the various syntax
    forms and interpretations it allows for <hier-part>. "

I disagree with this characterization with respect to "query" elements ("The 
query component contains non-hierarchical data that, along with data in the path 
component (Section 3.3), serves to identify a resource within the scope of the 
URI's scheme and naming authority (if any)." -- 
http://tools.ietf.org/html/rfc3986#section-3.4), though I accept it's commonly 
used to invoke dynamic search type operations.

For fragments, I accept that for a URN, where there is no dereferencing, the 
dependence on media type is difficult.  RDF 
[http://www.w3.org/TR/rdf11-concepts/] addresses this by simply treating the 
fragment as part of the overall name string, without further interpretation.

It then becomes an application design/implementation issue to avoid use of 
fragments of retrieved entities in ways that conflict with their use in names 
(cf. http://www.w3.org/TR/webarch/#fragid, 
http://www.w3.org/TR/webarch/#media-type-fragid).  In partyicular: "If no such 
representation exists, then the semantics of the fragment are considered unknown 
and, effectively, unconstrained." [ibid]

For paths, it's not clear to me whether you consider the relative resolution 
algorithm of RFC3986 to be part of the path semantics.  Per my comments above, I 
would be very concerned if you try to say that the resolution algorithm is not 
applicable to URNs, as that would mean that an application needs to know if its 
dealing with a URN or URI when performing otherwise scheme-independent processing.

...

In summary, assuming that you do not intend to exclude relative resolution from 
URN handling, the documents appears to me to be a "null specification", in that 
it does not actually exclude anything that is required by RFC3986.  I don't mean 
that its not useful - I think there are issues here that are usefully 
articulated and explained, but in the final analysis these clarifications should 
apply to *any* URI scheme used as a name rather than a locator.

And URI schemes are always allowed to layer their own semantics on top of 
RFC3986, so again the notion "removes URN semantics from the scope of RFC 3896" 
isn't really saying anything new that I can see.

So I think section 4 would more usefully be titled "Clarifications to RFC3986 as 
applied to URNs".

#g
--

By way of (partial) background to these comments, I'm currently working on a 
tool for small-scale research data management for which these are very real 
issues [https://github.com/gklyne/annalist].  I use URIs as both names and as 
locators, depending on context (not on the form of URI used).  Goals of my work 
include facilitation of data sharing, and provision of a path for data on 
researchers' desktops to library-managed data repositories - so both location 
and naming issues come in to play.

---

From: Sean Leonard <[email-masked]>
Date: Fri, 20 Feb 2015 12:05:09 -0800

(also bcc’ing apps-discuss…although not exactly sure why it’s bcc’ed)

On Feb 20, 2015, at 2:31 AM, Graham Klyne <[email-masked]> wrote:

> I've just taken a skim of http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-01, and I think the intent is fine but have a couple of questions or points of clarification.
> 
> My main concern is that URNs should be considered to be a kind of URI, and should be consistently usable in all contexts where a URI is usable (though, clearly, use in a context that requires dereferencing would be undefined in the same way as use of an unknown URI scheme would be).  

+1. I agree with Graham, namely, that a URN should be considered a kind of URI. (On that particular sentence I agree +1000.) It’s not just that they are syntactically the same—a URN is a species of URI, namely, a URI scheme. Compare with HTTP URI being a URI. It’s worth pointing out that since RFC 3986 says that URIs are semantics-free (mostly), that part of the URI spec may be cited in support of the premise that just because a URN is a kind of URI, it doesn’t imply much else with regard to semantics.

> Failure to satisfy this constraint would, IMO, force a bifurcation between URIs and URNs, which is something you say you want to avoid.
> 
> This means that not only should they conform to URI syntax, but also should conform to RFC3986 URI relative resolution rules.  For example, my code applies relative resolution without concern for the URI scheme used.  ("Traditional" URNs avoid syntactic constructions that include the possibility of relative references.)  (FWIW, I also happen to find that relative references are useful in naming contexts as well as retrieval contexts.)

There are philosophical and practical problems with URI’s relative resolution rules as applied to urn: URIs, which have been covered extensively on the urn mailing list around October-November 2014, so best to check that. I am happy to elaborate on my understanding if that helps things but want to keep this e-mail short now.

> 
> Jumping to section 4, which appears to be the substantive part of this document, the main change I am seeing is a change of terminology from "path", "query" and "fragment" to "p-component", "q-component" and "f-component".  I take this to be a distancing of these elements in URNs from some commonly used conventions used with location-based URIs (aka URLs).  To the extent that this helps to reduce confusion, this seems fine to me (thought I also think it's an open question as to whether new terminology does reduce confusion).

I actually disagree with the terms p-component, q-component, and f-component on editorial grounds. The problem is that “path”, “query”, and “fragment” were thought to imply some things that URNBIS people disagreed with. However, calling them x-component is annoying to me…particularly because a fragment is a fragment is a fragment.

For discussion purposes in I-Ds I was okay with it, but in any final RFCs I request that we go back to calling them “path”, “query”, and “fragment”. Specifically, how about referring to them as the “path production of [RFC3986]” and similar? By calling it “path production” you are specifically referring to the RFC 3986 URI ABNF grammar, which is about syntax, and does not imply that URNs are “path-oriented” or the like.

Cheers,

Sean