Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs

From: John C Klensin <[email-masked]>
Date: Mon, 02 Feb 2015 20:39:24 -0500

--On Monday, January 12, 2015 18:39 -0900 Melinda Shore
<[email-masked]> wrote:

> On 1/5/15 6:03 PM, "Martin J. Dürst" wrote:
>> On 2015/01/05 20:23, Juha Hakala wrote:
>>> On 25.12.2014 8:28, John C Klensin wrote:
>>>> The first part of Section 7, "Defining a URN Namespace",
>>>> outlines broad requirements.  Under item (2), it seems
>>>> worthwhile to clarify that the status of *-components be
>>>> specified here (it is explained in more detail in Section
>>>> 7.2, as promised).
>>>> 
>>>> Suggestion:
>...
>>>> New:
>>>>     2.  The syntax of URNs assigned within the namespace,
>>>>     including whether p-, q-, and/or f-components are
>>>>     allowed.
>...
>>> The downside of this is that people creating registration
>>> requests must find out what the implications of these
>>> components are for their identifier systems. But it should
>>> be easy both to supply this information, and to check if the
>>> information provided in the registration request is OK.
>>> 
>>> Namespaces which do not intend to support resolution
>>> services should not allow q-component. Namespaces which deal
>>> with digital manifestations may be able to support
>>> f-component.
>> 
>> We should make sure we write so in the draft.
>... 
> If nobody has any issues with this, we'll consider it closed.
> The resolution is that the draft will include John's "New"
> text along with some text along the lines of what Juha
> specified.

Sorry for the delay in getting back to this.  I'm fine with the
above but think we should be extremely careful about giving
guidance that someone could construe as a firm rule when we are
not confident we have identified all the cases.  I propose to
add the following to the end of the introduction to Section 3.3
(which introduces the three ?-component types):

	"As general guidance that may not apply to all cases,
	namespaces which do not intend to support resolution
	services should not allow q-component. Namespaces which
	deal with digital manifestations may be able to support
	f-component."

Does that work for everyone?   Can anything think of something
similar to say about p-components?   My personal guess at the
moment is that we are going to have to resolve the question of
whether p-components are a special part of the NSS, presumably
delimited by a "/" after the NSS begins, or an integral part of
the the NSS -- I've inserted a placeholder in the working draft
so we don't forget the question.

    john

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 02 Feb 2015 20:29:56 -0700

On 2/2/15 6:39 PM, John C Klensin wrote:
> Does that work for everyone?

I think that's fine as-is, although I also think we don't want to 
suggest that q-components and f-components in URNs are, necessarily, 
semantically related to queries and fragments in URIs (some might think 
"I want to pass parameters to a resolution service so I need URI 
queries" or "I want to point to sub-parts within media types so I need 
URI fragments").

> Can anything think of something

I'm not clear on the distinction between "special part of the NSS" and 
"integral part of the NSS".

Peter

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 02 Feb 2015 22:36:14 -0500

On 12/25/2014 01:28 AM, John C Klensin wrote:
> specified here (it is explained in more detail in Section 7.2,
> as promised).
>
> Suggestion:
>
> Old:
> 	2.  The syntax of URNs assigned within the namespace.
>
> New:

Sorry to take so long to reply; I got backlogged over the holidays even 
more than usual.

I am still very uncomfortable with making the meanings of p-, q-, and 
f-components specific to a namespace.

I'm not sure how uncomfortable I am with making the syntax (whether such 
components are supported) specific to a namespace.   It seems like a 
slippery slope to me.

I fundamentally don't believe that they type of resource named should be 
specific to a namespace as a matter of URN architecture. I realize that 
there are namespaces that are defined specifically for certain kinds of 
resources, but it should not be assumed by a consumer of a name that a 
particular kind of namespace indicates a particular kind of resource.   
This is something that should be learned at resolution or access time.

So therefore, on balance, I don't think it's appropriate to make the 
syntax for p-, q, or f- components namespace specific.

Keith

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 03 Feb 2015 13:57:20 +0900

> similar to say about p-components?

Just some grammatical comments:

1) I prefer to be called a 'body' rather than a 'thing', although in 
isolation, the former doesn't sound very nice, either :-).

2) I'd change "q-component" and "f-component" to "q-components" and 
"f-components" in accordance with usual language conventions.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Feb 2015 21:00:13 -0500

--On Tuesday, February 03, 2015 13:57 +0900 "\"Martin J.
Dürst\"" <[email-masked]> wrote:

> 1) I prefer to be called a 'body' rather than a 'thing',
> although in isolation, the former doesn't sound very nice,
> either :-).

Sorry... I was very tired when I wrote that and, as you have
probably noticed in other contexts, my typing fingers often get
too far ahead of what passes for my brain.   I am probably
equally tired now, so apologies in advance if I write something
equally careless and/or stupid tonight.

> 2) I'd change "q-component" and "f-component" to
> "q-components" and "f-components" in accordance with usual
> language conventions.

  That was basically Juha's text and I assumed the RFC Editor
would be able to straighten it out if necessary.   I didn't pay
more attention to it because it is connected to a difficulty
with the way we usually write about ABNF. With a different
metalanguage and way of talking about it, I would have written 

	"As general guidance that may not apply to all cases,
	namespaces that do not intend to support resolution
	services should not allow <q-component>. Namespaces
	which deal with digital manifestations may be able to
	support <f-component>."

>From that point of view, the plurals actually don't work because
we don't have productions for, e.g., "q-components".

But I made the change; the RFC Editor can change it back if that
amuses them.

    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Feb 2015 21:01:20 -0500

--On Monday, February 02, 2015 20:29 -0700 Peter Saint-Andre -
&yet <[email-masked]> wrote:

> I think that's fine as-is, although I also think we don't want
> to suggest that q-components and f-components in URNs are,
> necessarily, semantically related to queries and fragments in
> URIs (some might think "I want to pass parameters to a
> resolution service so I need URI queries" or "I want to point
> to sub-parts within media types so I need URI fragments").

That was a large fraction of the reason why I wanted to say "As
general guidance that may not apply to all cases".   Text to say
that better or more strongly would be welcome.

>> delimited by a "/" after the NSS begins, or an integral part
>> of the the NSS -- I've inserted a placeholder in the working
>> draft so we don't forget the question.
> 
> I'm not clear on the distinction between "special part of the
> NSS" and "integral part of the NSS".

Right now, the BNF says (with some irrelevant material removed):

      namestring    = assigned-name
                      [ p-component ]
                      [ q-component ]
                      [ f-component ]
      assigned-name = "urn" ":" NID ":" NSS
      NSS           = 1*(pchar)
      p-component   = "/" path-absolute

That relationship closely follows the syntactic structure of
3986.  The reservation on prohibition on "/" would allow

      namestring    = assigned-name
                      [ q-component ]
                      [ f-component ]
      assigned-name = "urn" ":" NID ":" NSS
      NSS           = 1*(pchar) [p-component]

Instead, but I don't see how we can avoid choosing one or the
other.

     john

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Feb 2015 03:20:48 -0500

Keith,

While noting your discomfort, even if the WG agreed with you (I
don't need to have an opinion about that at the moment), I don't
know how to translate that discomfort or the comments below into
something actionable wrt the document.  

I note that we've got a lot of experience with path, query, and
fragment components in HTTP URLs.  The interpretation and fine
details of the syntax of the first are determined on a
per-domain basis.  The interpretation and fine details of the
second and third are determined on the basis of the domain and
path and whatever objects they locate.  Sometimes the object to
be located is determined by the domain and path; sometimes it is
actually determined by information embedded in the query.    If
that object cannot be located or the location process doesn't
work, the user gets more or less specific error messages (often
less, amounting to "you lose").

I don't like those outcomes.  Indeed, I believe it is a
fundamental design flaw in the URL/ URI architecture.  But that
horse has left the barn and disappeared over the horizon and, as
the saying goes, no one has died.

URNs are more complicated in some ways, primarily because there
is no requirement for resolution, but it seems to me that an
objection to a certain amount of per-namespace interpretation
ultimately becomes an objection to URNs as part of the general
UR*/ URI model.  The decision to consider them part of that
model cannot be blamed on 3986: it was made long before 2141 and
even before 1630 and 1737.

The current proposed syntax is in the response I sent to Peter
some hours ago.   I've indicated what is in the proposed text.

What would you change and how?

   best,
    john

--On Monday, February 02, 2015 22:36 -0500 Keith Moore
<[email-masked]> wrote:

> Sorry to take so long to reply; I got backlogged over the
> holidays even more than usual.
> 
> I am still very uncomfortable with making the meanings of p-,
> q-, and f-components specific to a namespace.
> 
> I'm not sure how uncomfortable I am with making the syntax
> (whether such components are supported) specific to a
> namespace.   It seems like a slippery slope to me.
> 
> I fundamentally don't believe that they type of resource named
> should be specific to a namespace as a matter of URN
> architecture. I realize that there are namespaces that are
> defined specifically for certain kinds of resources, but it
> should not be assumed by a consumer of a name that a
> particular kind of namespace indicates a particular kind of
> resource.   This is something that should be learned at
> resolution or access time.
> 
> So therefore, on balance, I don't think it's appropriate to
> make the syntax for p-, q, or f- components namespace specific.