Subject: [urn] version -18

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 5 Sep 2016 20:31:03 -0600

First, my apologies (as the pen-holder) for taking so long to publish 
version -18 after the WG meeting in late June.

Yesterday I finally found time to listen to the recording of that 
meeting and to address the issues discussed at that time.

The only exception is the concern about relative resolution that Julian 
Reschke raised, which I posted about to the list yesterday. After 
thinking about it further, my feeling is that it would be very helpful 
for Julian (and perhaps Henry Thompson) to review the text again and to 
post to the list with a description of their concerns so that John and I 
can address them. And, as always, proposed text is welcome.

Also, please note that, because of his many other responsibilities, John 
has not yet had time to review this version in detail (and I wanted to 
publish it sooner rather than later in the interest of making progress). 
All errors are mine, and feedback would be appreciated.

Peter

---

From: Julian Reschke <[email-masked]>
Date: Tue, 6 Sep 2016 07:24:54 +0200

> can address them. And, as always, proposed text is welcome.

...the main concern is that it is indeed overriding RFC 3986, which, in 
the call, we decided wasn't necessary.

Best regards, Julian

---

From: [email-masked] (Henry S. Thompson)
Date: Sun, 25 Sep 2016 12:08:13 +0100

Peter Saint-Andre writes:

> The only exception is the concern about relative resolution that
> Julian Reschke raised, which I posted about to the list
> yesterday. After thinking about it further, my feeling is that it
> would be very helpful for Julian (and perhaps Henry Thompson) to
> review the text again and to post to the list with a description of
> their concerns so that John and I can address them. And, as always,
> proposed text is welcome.

Here's an (overlong) attempt to be helpful here.

*TL;DR*

 _Actually_, since we have kept URN syntax compatible with 3986,
 strictly speaking the 3986 syntactic approach to relative resolution
 works just fine with a URN as base URI, that is, does not trigger any
 error conditions;

 _But_ with two exceptions the result is unlikely to be a useful, or
 even valid, URN:

   Exception 1: The base URN's namespace is hierarchical in
   structure and its NSS syntax uses / to delimit steps in that
   hierarchy;

   Exception 2: The relative reference consists entirely of q- and/or
   f-components (r-components, no so sure);

 _However_ in practice the issue only arises when delivering a
 resource representation which includes one or more relative
 references in ways which identify themselves as such;

 _So_ section 4.3 [1] can and should be simplified to something like
 the above summary, followed by advice to resolvers that _deliver_
 resource representations which may contain relative references to be
 sure to deliver them in such a way that the base URI _for that
 representation_ does use an appropriate hierarchical locator scheme,
 e.g. http: or https:.

Below here are some lengthy discussions of supporting arguments for
the above summary.

*Background*

The starting point for any consideration of relative references and
the resolution thereof is an understanding of the circumstance in
which questions arise.  Yes, 3986 treats this in the abstract, but I'm
going to go concrete in order to clarify some things.

First point: Relative reference resolution is a _process_, carried out
by some agent.  Some reflection leads to a list of requirements which
must be satisfied before this will happen:

 1) We have to have a structured artefact (document/data
    structure/...) which 'has' a base URI;

 2) We have to know something about the nature of that artefact which
    allows us to identify strings in it as being relative references.

The most likely ways this can happen are

 a) We have a document accessed via some means, and that means itself
    lets us know both a base URI and a media type (the HTTP protocol
    is such a means).  The media type in turn lets us identify parts
    of the document which are URIs, and 3986 lets us tell when those
    are relative references.  The media type _may_ also tell us how
    parts of the document change the base URI for delimited regions
    therein;

 b) We have a structure (think e.g. JSON or SQL) which is either
    intrinically or extrinsically typed.  Base URI information may
    come either extrinsically, or via the structure and its types, or
    an interaction between those and an agent's processing.  That
    certain values in the structure are URIs can be assumed to be
    determined similarly.

Even for those rare cases distinct from (a) and (b), it is _very_
likely that the _author_ of any artefact including strings intended to
be understood/treated as relative references will have had such
scenarios in mind.

(Note that for URNs which are "abstract designators", no such
scenarios can ever arise.)

Second point: There are _lots_ of HTML or XML or RDF or JSON documents
out there on the Web which have been authored with the expectation
that they will be accessed via HTTP using an http: URI which in turn
therefore will be the base URI during processing of that artefact, and
thus that relative references in that document can be used to access
e.g. siblings in the tree-structured information space in which the
retrieved representation's resource can be assumed to be situated.
The toolchains which support this on the receiving end are many and
varied, and we _really_ don't want to include anything in urnbis which
makes them suddently non-conformant.

But this appears to put us in difficulties.  If such documents are
accessed via some URN resolution process, the last assumption above
(about sibling access) would appear to be at risk, as resolving
e.g. "../foo.html" against e.g. urn:isbn:0451450523 is unlikely to
produce anything that will resolve at all (see below at *Algorithms*).

But that of course is only true if the outcome of the resolution
process identifies the base URI of the result as urn:isbn:0451450523.

So don't do that.  That is, resolvers should deliver resource
representations with hierarchical locator URIs, not URNs, as their
base URIs.

*3985 Algorithm*

First, the relevant section [1] begins with an assertion I find
perplexing:

   Section 5.2 of [RFC3986] describes an algorithm for converting a URI
   reference that might be relative to a given base URI into "parsed
   components" of the target of that reference, which can then be
   recomposed per RFC 3986 Section 5.3 into a target URI.  This
   algorithm cannot be applied directly to URNs because their syntax
   does not support the necessary path components.

Earlier in the draft there is a careful explanation that URN syntax as
described is compatible with URI syntax as specificed in RFC 3986.  As a
result, the 3986 algorithms [2], [3] work just fine, albeit not perhaps
in a way that's very useful.  For example, if we take one of the example
URNs from 2141bis as the base URI:

  urn:example:a123,z456

and a simple string as the relative reference

  xyzzy

the algorithms proceed as follows:

1) Pre-parse the base:

 scheme:            urn
 path:              example:a123,z456
 auth, query, frag: undefined

2) Transform references
  a) Parse:
      path:                      xyzzy
      scheme, auth, query, frag: undefined
  b) Merge paths:
      new path: xyzzy
  c) Copy query and fragment
      new query, fragment: undefined
  d) Reuse scheme, auth
      new scheme: urn
      new auth: undef

3) Recompose

  result: urn:xyzzy

For URN namespaces which happen to use / as a separator, the 3986
algorithms will work as perhaps as expected in some cases, but not in
others:

   urn:example:a123,z456/bar + baz --> urn:example:a123,z456/baz
but
   urn:example:a123,z456/bar + /foo --> urn:/foo

Behaviour in the presence of one or more '..' segments is left as an
exercise for the reader.

All of this may suggest that a minor edit saying "don't do this unless
you are _very_ sure you know what you're doing" might seem to be all
that's required.

But there is a large set of cases where the right thing will happen and
these are likely to be quite useful: that is, those where the reference
consists entirely of the optional post-assigned-name part of the URN
syntax.  In these cases the r- and or q- components will override the
base if present and the f-component will be copied over.

ht

[1] https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-18#section-4.3
[2] https://tools.ietf.org/html/rfc3986#section-5.2
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: John C Klensin <[email-masked]>
Date: Sun, 25 Sep 2016 13:09:11 -0400

--On Sunday, September 25, 2016 12:08 +0100 "Henry S. Thompson"
<[email-masked]> wrote:

>> The only exception is the concern about relative resolution
>> that Julian Reschke raised, which I posted about to the list
>> yesterday. After thinking about it further, my feeling is
>> that it would be very helpful for Julian (and perhaps Henry
>> Thompson) to review the text again and to post to the list
>> with a description of their concerns so that John and I can
>> address them. And, as always, proposed text is welcome.
> 
>...

Henry,

Speaking as an individual contributor only (and as one who is,
personally, quite frustrated with how long this and some closely
related issues have preventing the WG from completing its work,
driven people away, etc.), I'd like to suggest a different
approach.  This is strongly inspired by your summary, but even
shorter and less prone to errors and misinterpretations.  In
addition to what is in your summary, I note that, if URNs are
going to serve the function of a [very long term] stable
identifier, a program or engine that processes a URN cannot, in
the general case, know how a particular namespace will resolve
or otherwise interpret that URNs at a particular time.

The suggestion below was strongly stimulated by your note,
especially by the section titled "*3985 Algorithm*" (sic).   I
believe, even more strongly than I did before, that saying more
about relative references in 2141bis just gets us into more
trouble and that we should say less, ideally almost nothing.

Consequently, I suggest that we remove all of the present
discussion of relative resolution from 2141bis and replace it
with two statements, exact wording to be determined, but whose
substance should be (the footnotes should probably not be part
of the statement(s), but that is an editorial matter):

	(i) A system that encounters a <URI-reference> [1] that
	obeys the syntax for <relative-ref>, whether it
	explicitly has the scheme "urn" or not, will convert it
	into a target URI as specified in RFC 3986.[2]
	
	(ii) Because of the persistence and stability
	expectations of URNs, authors of documents, etc., that
	utilize URNs should generally avoid the use of the "urn"
	scheme in any <URI-reference> that is not
	self-contained, specifically including those that would
	require processing of <relative-ref>. [3]
	
[1] All terminology and definitions in these statements
are references to 3986, presumably as it may be updated,
replaced, or interpreted by some sort of consensus in
the future.

[2] Finding an appropriate Base URI is a 3986 problem,
not a URN one.  If such a Base URI cannot be found in an
acceptably unambiguous way, that is a 3986 problem too.
If the community concludes that more advice (or
requirements) are required about edge or failure cases
than 3986 provides, that is a 3986-bis or 3986 update
matter, not a URN one.

[3] A more succinct way of saying that is that using a
relative reference with a URN is probably crazy behavior.

Now, the effect of that approach is to take us back to where we
should have been at the beginning: 3986 effectively says that
relative references/URIs are a lexical matter, to be resolved by
parsers that are not scheme-dependent.  2141bis should not be
required to say more about them than, e.g., RFC 6068 ("Mailto")
does and that is nothing.  I'd suggest removing the section
entirely except that I believe that the explicit warning should
be given that use of relative references with URNs is likely to
result in nonsense.

_Anything_ more than the above, including your proposed
paragraph or explanation, is likely to put us into the business
of updating 3986, even if only updating it by additional
explanation, or arguments about whether or not we are doing
that... and, at least IMO, we just need to move on.

In particular, I note that

> advice to resolvers that _deliver_
>  resource representations which may contain relative
> references to be  sure to deliver them in such a way that the
> base URI _for that  representation_ does use an appropriate
> hierarchical locator scheme,  e.g. http: or https:.

is really advice for an improvement to 3986 because it is
independent of whatever scheme might be associated with the
resource representation and makes a scheme-independent (except
by example) statement about appropriate base URIs.

Even more strongly, your "First point" about the relative
resolution process is, to me, an entirely worthy update and
clarification to 3986.  Your explanation under "*3985
Algorithm*" is hugely more clear than Section 5.2 of 3986
(although I agree they say just about the same thing).  I
suggest you turn one or both into an I-D and submit it as a 3986
update and clarification.

  best,
      john

---

From: Sean Leonard <[email-masked]>
Date: Sun, 25 Sep 2016 17:17:35 -0700

Hello URNies:

Henry’s observations are all very interesting and such. It’s a bit too much in the weeds for me.

I only have the following points to add:

* At this point, less is more. Say less, and URNBIS will do more (i.e., people will actually start using it). More or less echoes John’s observations.

* There are many examples of permanent URI schemes that yield nonsense when used as a base URI and combined with relative references. For example, data: and mailto: . Short answer remains the best: “don’t do it.” *How* you “don’t do it” is left as an exercise for the reader. :)

But my hint would be: “as much as you want to think of urn: as the base URI for an HTML document, “don’t do it.” Would you use data: or mailto: as the base URI for an HTML document? “Don’t do it.” Figure out some way--ANY WAY--to compute some other base URI for the subject that gives you trouble, and use that.

* . and .. have no meaning when / is not in the p-component (NSS), noting that / is not part of NID anyway. Therefore, all this stuff about relative references goes away when we prohibited / (the “old way”). The complications raised here suggest that keeping / prohibited was a good choice with RFC 2141. Those who want to use / in identifiers, could use %2f instead. I would characterize the “need” to add / in URN strings as “desperate”. Nothing’s wrong with : , and it doesn’t suffer from these problems, by design. Maybe this ship has sailed. Just pointing out the consequences.

* The NSS in this draft corresponds to path-rootless. No matter what, sufficient ../../… will knock out the NID. There is no way to avoid this, unless we changed the way that NID works, to have it start with //, in which case, it could be “protected” from excessive ../../… .

> base if present and the f-component will be copied over.

To me, the case where this is useful is where the additional media content is operatively associated with the URN, but using different query data. Specifically, consider:

urn:ietf:rfc:9999

let’s suppose that:

urn:ietf:rfc:9999?+ct=text/html#Section-2

gets the text/html version from say tools.ietf.org. Then:

urn:ietf:rfc:9999?+rel=embed;ct=image/svg;id=fig3#icon-clock-view

gets the SVG content that was archived along with the main document blob, and focuses on the clock icon (see SVG <view>). Then the following URI-reference would be useful:

<a href="?+rel=embed;ct=image/svg;id=fig3#icon-clock-view">blah blah</a>

…still though, if urn:ietf:rfc:9999?+ct=text/html#Section-2 amounts to a “redirect” to https://tools.ietf.org/html/rfc9999#Section-2 , I don’t see why an HTML client (web browser) would see <a href="?+rel=embed;ct=image/svg;id=fig3#icon-clock-view"> in the first place. The better way to think about it, would be that <a href="?+rel=embed;ct=image/svg;id=fig3#icon-clock-view"> would be stored in some content management system as the internal reference to the content, to be rewritten when serialized out to a web browser. (Note that the content management system is aware of the base URI being a URN, by design; it never exposes this fact to web browser clients, as it “rebases” the content.)

Kind regards,

Sean

> On Sep 25, 2016, at 4:08 AM, Henry S. Thompson <[email-masked]> wrote:
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 26 Sep 2016 15:37:48 +0900

Hello John, Henry, others,

Just one comment below.

> 	into a target URI as specified in RFC 3986.[2]

In general, references that contain a scheme (such as "urn") are treated 
as absolute, and are therefore not involved in this process.

However, there's an exception in RFC 3986, called a "non-strict parser" 
(see http://moo.sw.it.aoyama.ac.jp/mod/quiz/view.php?id=1850), which 
allows to ignore the scheme if it's the same as the scheme on the base.

I'm not sure how widely these "non-strict parsers" are deployed. Maybe 
very widely, but maybe they are rather non-existent. We'd probably have 
to as Roy directly about this.

Anyway, that suggests that the wording above might need to be a bit more 
cautious.

Regards,    Martin.

P.S.: I generally agree with the direction that John is suggesting.

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Sep 2016 05:18:25 -0400

Martin,

(top post and very quick comment)

I was aware of the non-strict parser text when I wrote my note.
I favor "more cautious" whether there are extensive
implementations or none as long as it can be done without adding
length, complexity, and the opportunity for more controversy and
questions about whether 3986 is being updated or contradicted.   

However, because a new implementation could come along tomorrow,
I think we are stuck with what 3986 says rather than
implementation-counting unless someone proposes to immediately
create an I-D to explicitly amend those provisions out of 3986
or deprecate their use and a plan for getting that I-D approved.
As long as 3986 contains those provisions, "no one actually
supports this" (even if that were true) is not particularly
relevant to what goes in 2141bis, at least other than supporting
a statement advising  against the use of relative references
where URNs are concerned.

best,
    john

--On Monday, September 26, 2016 15:37 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

>> --On Sunday, September 25, 2016 12:08 +0100 "Henry S.
>> Thompson" <[email-masked]> wrote:
> 
> In general, references that contain a scheme (such as "urn")
> are treated as absolute, and are therefore not involved in
> this process.
> 
> However, there's an exception in RFC 3986, called a
> "non-strict parser" (see
> http://moo.sw.it.aoyama.ac.jp/mod/quiz/view.php?id=1850),
> which allows to ignore the scheme if it's the same as the
> scheme on the base.
> 
> I'm not sure how widely these "non-strict parsers" are
> deployed. Maybe very widely, but maybe they are rather
> non-existent. We'd probably have to as Roy directly about this.
> 
> Anyway, that suggests that the wording above might need to be
> a bit more cautious.
> 
> Regards,    Martin.
>

---

From: [email-masked] (Henry S. Thompson)
Date: Wed, 28 Sep 2016 17:11:46 +0100

John C Klensin writes:

> especially by the section titled "*3985 Algorithm*" (sic).

Oops :-(

> I believe, even more strongly than I did before, that saying more
> about relative references in 2141bis just gets us into more trouble
> and that we should say less, ideally almost nothing.

Works for me.

> 	into a target URI as specified in RFC 3986.[2]

Yes.

> 	require processing of <relative-ref>. [3]

Not at all sure what you mean by "<URI-reference> that is not
self-contained".  I _think_ what you mean is captured by this rewrite:

	(ii) Because the result of (i) may well fail to be a valid URI,
	using a URN to identify a resource (any of) whose
	representation(s) may contain <relative-ref>s should be avoided.

> than 3986 provides, that is a 3986-bis or 3986 update

I'd actually argue that its a delivery-protocol problem, but the
distinction is moot, since what matters is that it's _not_ a urnbis
problem.

> by example) statement about appropriate base URIs.

Very true -- the intentional advantage of the passive voice in my
reformulation of (ii) above is that it leaves open the question of who
might be in a position to do the avoiding -- authors might be (your
formulation), resolvers might be (the bit of my message you quote
immediately above), user agents might be, etc.

ht

---

From: John C Klensin <[email-masked]>
Date: Wed, 28 Sep 2016 15:15:35 -0400

--On Wednesday, September 28, 2016 17:11 +0100 "Henry S.
Thompson" <[email-masked]> wrote:

> self-contained". 

I could have said "<URI-reference> that is not strictly a <URI>
as specified in RFC 3986."

> I _think_ what you mean is captured by this
> rewrite:
> 
> 	(ii) Because the result of (i) may well fail to be a valid
> URI, using a URN to identify a resource (any of) whose

Actually, I think the part about persistence and stability
expectations is important, in part because it makes the
recommendation squarely about URNs and anchors that in URN
reasons.  It thereby avoids cases implied by the "may" in the
3986 discussion of non-strict parsers that I get a headache when
I try to think about.  I think your rewrite drifts back toward
interpretations of 3986, but see also below.  I'm ok with your
version if that is what others prefer.

> I'd actually argue that its a delivery-protocol problem, but
> the distinction is moot, since what matters is that it's _not_
> a urnbis problem.

Exactly.  And, again, I was not proposing to put that in the
document.

>...
> Very true -- the intentional advantage of the passive voice in
> my reformulation of (ii) above is that it leaves open the
> question of who might be in a position to do the avoiding --
> authors might be (your formulation), resolvers might be (the
> bit of my message you quote immediately above), user agents
> might be, etc.

Whether I agree or not about the details above, we definitely
agree that 2141bis should not address the issue.

For those who are reading this, please remember that 2141bis
started out saying nothing, or virtually nothing, about relative
references.  The text we are now talking about went in because
some WG participants insisted on it.  I'm delighted to be
discussing the details of taking it back out but, before we do,
I'd like to be confident that those who want details of relative
references in 2141bis have been convinced by the argument
against doing to -- I don't want to spend weeks and a draft or
two getting to minimal text only to have to put the longer
explanation back in again.

Co-chairs, please figure out how (and if and when) to make a
consensus call on this subject.

    john