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

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 1 Jun 2015 11:34:11 +0000

On Thursday, May 28, 2015 1:10 PM, Leslie Daigle wrote:
> 
> 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).

That is at least my desire.

> With that:
> 
> On 28 May 2015, at 0:01, John C Klensin wrote:
> 
> > --On Wednesday, May 27, 2015 21:06 -0600 Peter Saint-Andre -
> > &yet <[email-masked]> wrote:
> >
> >> 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".
> >>>
> >>> 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.
> 
> 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.

Well, path-rootless is defined as

path-rootless	= 	segment-nz   *( "/"   segment )

so it _does_ split into segments. I don't understand how that breaks the opacity of rfc 3986 §1.2.3, though. Could someone please explain?

Thanks,

Lars