Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 26 May 2015 20:35:27 -0600

On 4/17/15 10:01 AM, Leslie Daigle (ThinkingCat) wrote:
>
>
> I think this is a rational, if hypothetical, reason for p-components,
> and my requirement would be for the document to be clear about the use:
>
>> For those namespaces that need additional qualification (beyond
>> the traditional NSS) that still participates in equality
>> checking, that has so far left p-components as the only logical
>> option.  Perhaps there is some other syntax that would do the
>> job --a hypothetical X-component -- but, so far, no one has
>> proposed one and the logic of 3986 is such that I think we can
>> expect any such syntax proposal to produce cries of pain about
>> generic URI parsers and related topics.
>
>
> IMO, that can be achieved by being clear about what the NSS is, assert
> that relative URNs are not expected/permitted, and attest that "/"
> should not be used in a URN simply because one is importing a namespace
> that happens to use them and it's a matter of syntactic convenience not
> to escape them with %-encoding.

How is this for proposed text?

    The namespace specific string (NSS) is a unique identifier that is
    assigned in a consistent way and that conforms to the definition of
    the relevant namespace.  The combination of the NID (unique across
    the entire "urn" scheme) and the NSS (unique within the namespace)
    ensures that the resulting URN is a globally unique URI.

    This document modifies the syntax of the NSS to allow the following
    characters: "/", "~", and "&".

    In particular, allowing the "/" character effectively makes it
    possible to encapsulate hierarchical identifiers from other naming
    systems.  For instance, consider the hypothetical example of a
    hierarchical naming system in which the identifiers take the form of
    a series of numbers separated by the "/" character, such as "1/406/
    47452/2".  If the naming authority for such identifiers were to use
    URNs, it would be natural to place the existing identifiers in the
    NSS, resulting in URNs such as "urn:example:1/406/47452/2".
    Nevertheless, it is not appropriate the "/" character be used in a
    URN merely because the URN namespace is importing a naming system
    that happens to use the character; it is simply a matter of syntactic
    convenience not to escape the character with percent-encoding.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 May 2015 07:05:57 -0400

--On Tuesday, May 26, 2015 20:35 -0600 Peter Saint-Andre - &yet
<[email-masked]> wrote:

>...

Peter,

Up to the last sentence (and including the parts not quoted
above, this seems ok to me.  But I can't quite parse that last
sentence or figure out what it means -- it seems to be
contradicting the text above it.

    john

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Wed, 27 May 2015 18:03:42 -0400

My recollection aligned with Keith’s — that we agreed to do away 
with p-components.   Digging back, have a look at the thread that 
started with Keith’s message with subject “suggested text changes 
for -12 on p-components, f- and q-components in URN resolution, and 
relative references”.

It made sense to Keith, me, Juha and Sven at the time, it seems.  (And 
it still makes sense to me, FWIW :^) ).

Leslie.

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------
On 26 May 2015, at 22:35, Peter Saint-Andre - &yet wrote:

> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 27 May 2015 21:06:30 -0600

On 5/27/15 4:03 PM, Leslie Daigle (ThinkingCat) wrote:
>
> My recollection aligned with Keith’s — that we agreed to do away with
> p-components.   Digging back, have a look at the thread that started
> with Keith’s message with subject “suggested text changes for -12 on
> p-components, f- and q-components in URN resolution, and relative
> references”.
>

As I recall, we got rid of p-components but didn't disallow "/" in the 
NSS. A rose by any other name...

Peter

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 27 May 2015 21:07:45 -0600

> contradicting the text above it.

Hmm, yes. I'd be fine with removing that final sentence (this is one of 
the problems with trying to stitch together proposed text from different 
contributors).

Peter

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 May 2015 23:46:55 -0400

--On Wednesday, May 27, 2015 21:07 -0600 Peter Saint-Andre -
&yet <[email-masked]> wrote:

>>>      NSS, resulting in URNs such as
>>>      "urn:example:1/406/47452/2". Nevertheless, it is not
>>>      appropriate the "/" character be used in a
> Hmm, yes. I'd be fine with removing that final sentence (this
> is one of the problems with trying to stitch together proposed
> text from different contributors).

Simply removing it works for me.
   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 28 May 2015 00:01:48 -0400

--On Wednesday, May 27, 2015 21:06 -0600 Peter Saint-Andre -
&yet <[email-masked]> wrote:

>> My recollection aligned with Keith's — that we agreed to
>> do away with p-components.   Digging back, have a look at the
>> thread that started with Keith's message with subject
>> "suggested text changes for -12 on p-components, f- and
>> q-components in URN resolution, and relative references".
>> 
>> It made sense to Keith, me, Juha and Sven at the time, it
>> seems.  (And it still makes sense to me, FWIW :^) ).
> 
> As I recall, we got rid of p-components but didn't disallow
> "/" in the NSS. A rose by any other name...

So, we allow "/", we don't treat it in any way as a special
delimiter that serves the delimiter function described in
Section 1.2.3 of RFC 3986, breaks the opacity discussed in the
last paragraph of that section and breaks the path into segments
regardless of whether we interpret those separately. 

It also takes us into relative reference territory.  The only
thing 2141bis says on that subject right now is the second
paragraph of Section 5, 

I'm ok with all of the above, but want to check and make sure
everyone else is too because this is pushing the boundaries of
"conform to 3986 syntax".

   john

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Thu, 28 May 2015 07:09:59 -0400

As I understand it (which may be wrong), the real desire in URNBIS has 
been to be able to have “/“, not a belief in the need for 
“p-components” or relative URNs (which are, as you note, different).

With that:

> regardless of whether we interpret those separately.

I don’t believe that is the case in what we discussed on that thread 
— because the belief and expectation is that “/“ appears in single 
instances within the NSS, and the whole string is treated as 
“path-rootless”.

As I wrote at the time — I am not a URI parser and I still wouldn't 
object to hearing confirmation from someone who does deal in non-URN URI 
parsing for a living.

If that’s a mis-understanding, then, indeed, we’re not where I (at 
least) thought we were.

Leslie.