Subject: [urn] URN and URI semantics

From: "Hakala, Juha E" <[email-masked]>
Date: Thu, 19 May 2016 12:49:44 +0000

Hello, 

Julian Reschke said_

"WG consensus isn't IETF consensus. If this WG wants to update a standards track document, it will have to be able to answer the questions that I asked.

I hear from you and John: "RFC 3986 syntax, but not semantics", as if there was agreement about what parts of RFC 3986 are which (or is there?).

So, once again, if we say "updates: 3986" we need to be able to explain
*precisely* which parts of RFC 3986 are affected (and why, fwiw)."

I provide a short description, from the point of view of the identifier community, which parts of RFC 3986 are affected, and in which manner. 

RFC 3986 says this about query in chapter 3.4:

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).

Chapter 3.5 says that:

The fragment identifier component of a URI allows indirect
   identification of a secondary resource by reference to a primary
   resource and additional identifying information.  The identified
   secondary resource may be some portion or subset of the primary
   resource, some view on representations of the primary resource, or
   some other resource defined or described by those representations.

>From URN point of view, the idea that fragment and query always have a role in identification is problematic both from semantics and syntax points of view.

When URI syntax is applied to a managed URN namespace in which the identifier syntax and scope are strictly controlled, difficulties will emerge. I shall use ISBN as an example, but the issues are not ISBN-specific. 

According to URI syntax, urn:isbn:<isbn> can be extended into urn:isbn:<isbn>#fragment to identify some portion of the primary document. The namespace specific string is <isbn>#fragment since fragment must have a role in identification. 

This creates two problems. First, according to the ISBN standard, ISBN consists of 13 digits, so "#" and fragment cannot be part of the ISBN string. So fragment-augmented ISBN must not use the ISBN namespace, but e.g. namespace ISBN-frag.  In order to use fragments or queries as required by the URI syntax, some URN namespaces should therefore have two additional namespaces, one for fragments and another for queries (say, isbn-frag and isbn-query in addition to urn:isbn). Such namespace registrations do not exist and there are no plans to create them. It would be difficult to specify the scope of such namespaces, especially for query since we do not know what kind of queries will be used.  

Second, ISBN cannot be used to identify portions of books, such as chapters. There are other identifier standards such as BICI and DOI for this purpose. So fragment usage augments the scope of ISBN system in an unacceptable way. Note that it is not possible to modify the ISBN standard in such a way that fragments (or queries) could be used, first and foremost because after this kind of change it would be very difficult to manage ISBN assignment in the same quality level as before. 

The current version of the revised URN syntax says that fragment and query have no role in identification. This means that for instance in urn:isbn:<isbn>#f-component, the namespace specific string is <isbn> only, and f-component, although part of the URN, has no role in identification. The fragment only pinpoints a location within the resource identified by the ISBN. With this simple change it is possible to avoid both URN namespace and identifier scope related problems described above.

Generally, I think it is a bad idea to require that URI fragment and query must have a role in identification, and the prose describing this practice in RFC 3986 is not crystal clear.   

As regards query, I am not sure what "resource within the scope of the URI's scheme" means. If the URI scheme is URN, potentially anything is within the scope and we need to do what rfc2141bis currently does. But if the scheme is specified in the namespace level, then the scope of urn:isbn is defined by the ISBN standard to be monographs only, and for instance urn:isbn:<isbn>?q-component which "identifies" metadata record describing the book identified by ISBN is definitely not within the scope and should not identify anything even according to the RFC 3986. Does the URI syntax allow that some resources "identified" by query are outside the scope of the URI scheme. Or, how to specify "within the scope" and "outside the scope" in this context? This might well be one of those sections in RFC 3986 have been understood in different ways by different people, which in a standard document is not a good thing. Be that as it may, if the scope is a priori everything that queries may cover past, present and future - good luck with it.  

>From URN point of view, the easiest solution would be to say in rfc3986bis that no resources "identified" by query are within the scope of the URN scheme and therefore in the URN syntax q-component has no role in identification unlike other URIs. Or, to formulate this less strictly, it is possible that in some URN namespaces some resources "identified" by queries may be out of the scope and therefore, to avoid any false positives, in URN syntax q-component never identifies anything.  

Fragments have their own general issues when used as "identifiers". It is non-trivial - at least to me - to see exactly what has been identified, since fragment isn't an identifier, but just a locator. Just to give you a simple example, my library has millions of digitized text documents which have very detailed XML schemas. Without going to any technical details, we could create the following URNs:

urn:isbn:<isbn>#chapter1
urn:isbn:<isbn>#chapter1para1
urn:isbn:<isbn>#chapter1para1line1
urn:isbn:<isbn>#chapter1para1line1word1
urn:isbn:<isbn>#chapter1para1line1word1letter1

According to the rfc2141bis, all these URNs are equivalent (they identify the same book, and only that), but they indicate different locations within the first chapter of the identified book. Anyone could create these URNs once the national library has established the base URN. This is not a mandate problem since fragments have no role in identification. 

According to RFC 3986, we would have something like 

urn:isbn-frag:<isbn>#chapter1
urn:isbn-frag:<isbn>#chapter1para1
urn:isbn-frag:<isbn>#chapter1para1line1
urn:isbn-frag:<isbn>#chapter1para1line1word1
urn:isbn-frag:<isbn>#chapter1para1line1word1letter1

and each URN would "identify" a different portion of the book, but it is not obvious what that portion is and how these fragment identifiers relate to one another, or who would have the authority to mint these identifiers. When resolved, they would all take the user to the beginning of the actual text.   

All the best,
 
Juha
--

Juha Hakala

 Senior advisor
 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Kaikukatu 4)
 FIN-00014 Helsinki University

 Gsm: +358 50 3827678
 email: [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 May 2016 09:39:24 +0200

Hi Juha,

thanks a lot for your feedback; this is extremely helpful in that we can 
consider a concrete concern and analyze it.

See more inline.

On 2016-05-19 14:49, Hakala, Juha E wrote:
>  ...

It's not optimal to discuss query and fragment together.

The query is part of of the absolute-URI ABNF production 
(<https://greenbytes.de/tech/webdav/rfc3986.html#absolute-uri>).  What 
the absolute-URI contains is under full control of the URI scheme. So 
it's up to the definition of the "URN" URI scheme to define whether 
queries are allowed, and if they are, what they mean (or of course it 
can be delegated to the URN namespace definitions).

Also, just because RFC 3986 says that the query plays a role in the 
definition *in general* doesn't mean it has to for a particular scheme.

Fragment is a different case; RFC 3986 also says:

"The semantics of a fragment identifier are defined by the set of 
representations that might result from a retrieval action on the primary 
resource. The fragment's format and resolution is therefore dependent on 
the media type [RFC2046] of a potentially retrieved representation, even 
though such a retrieval is only performed if the URI is dereferenced. If 
no such representation exists, then the semantics of the fragment are 
considered unknown and are effectively unconstrained. Fragment 
identifier semantics are independent of the URI scheme and thus cannot 
be redefined by scheme specifications." -- 
<https://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.1>

So for a URN this leaves the door wide open; note "If no such 
representation exists, then the semantics of the fragment are considered 
unknown and are effectively unconstrained.

> This creates two problems. First, according to the ISBN standard, ISBN consists of 13 digits, so "#" and fragment cannot be part of the ISBN string. So fragment-augmented ISBN must not use the ISBN…

Hm, no. The fragment is not part of the absolute-URI definition, so by 
definition it is not part of the URN's namespace-specific string.

> Second, ISBN cannot be used to identify portions of books, such as chapters. There are other identifier standards such as BICI and DOI for this purpose. So fragment usage augments the scope of ISBN…

OK, I agree that using fragment identifiers with ISBN URNs doesn't make 
sense. So the choice is between making them illegal/invalid (essentially 
saying "don't do that") or leaving their meaning undefined (as per 
current RFC 3986). Does the difference really matter?

> The current version of the revised URN syntax says that fragment and query have no role in identification. This means that for instance in urn:isbn:<isbn>#f-component, the namespace specific string…

This is perfectly ok and does not require any change to RFC 3986. The 
fragment isn't part of absolute-URI anyway. With respect to the query 
component: what it means and how (or whether) it affects resource 
identification is under the control of the URI scheme definition anyway.

> Generally, I think it is a bad idea to require that URI fragment and query must have a role in identification, and the prose describing this practice in RFC 3986 is not crystal clear.

RFC 3986 does not *require* anything about the query component for 
particular URI schemes. It just says that in *general*, it does play a 
role in identification. The "URN" URI scheme definition can easily say 
"but it doesn't in our case".

With respect to fragments: RFC 3986 says that the primary resource is 
identified by what's in the absolute-URI, and the meaning of the 
fragment either depends on the media type of the associated 
representation, or, in absence of a representation, is unconstrained.

> As regards query, I am not sure what "resource within the scope of the URI's scheme" means. If the URI scheme is URN, potentially anything is within the scope and we need to do what rfc2141bis curr…

It means "resource identifiable by the URI scheme". Maybe you're trying 
to read more into this statement than there is.

>>From URN point of view, the easiest solution would be to say in rfc3986bis that no resources "identified" by query are within the scope of the URN scheme and therefore in the URN syntax q-component…

That's under control of the URN scheme definition. If you want do define 
that, you can.

> Fragments have their own general issues when used as "identifiers". It is non-trivial - at least to me - to see exactly what has been identified, since fragment isn't an identifier, but just a loca…

How do you come to the conclusion that fragment are locators, not 
identifiers, and what's the difference in practice?

> According to the rfc2141bis, all these URNs are equivalent (they identify the same book, and only that), but they indicate different locations within the first chapter of the identified book. Anyon…

Wow, they are *equivalent*, but indicate *different* locations? That's 
IMHO a very very surprising definition of equivalence. It probably would 
be good to use a more specific term.

> urn:isbn-frag:<isbn>#chapter1para1line1word1letter1

These seem to be identical to the first set of examples, except for the 
differing namespace name...

> and each URN would "identify" a different portion of the book, but it is not obvious what that portion is and how these fragment identifiers relate to one another, or who would have the authority t…

I find this very very confusing. In the first case the URI identifies a 
book and also indicates a location within the book. In the second case, 
the URI identifies a location within a book.

Both use exactly the same syntax except for the URN namespace name. What 
do you base the distinction on, and who is supposed to understand that?

 > ...

Best regards, Julian

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 20 May 2016 12:57:37 +0000

Hello Julian, 

Thank you for the feedback. I hope we are getting closer to sufficient alignment of our views. Some comments below. 

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: 20. toukokuuta 2016 10:39
> To: Hakala, Juha E <[email-masked]>; [email-masked]
> Subject: Re: [urn] URN and URI semantics
> 
> Hi Juha,
> 
> 
> the absolute-URI contains is under full control of the URI scheme. So it's up
> to the definition of the "URN" URI scheme to define whether queries are
> allowed, and if they are, what they mean (or of course it can be delegated to
> the URN namespace definitions).

In the URN syntax context, we don't want to prevent a priori the usage of r/q/f-components. The only exception to this are namespaces were fragments are out of scope since nothing tangible is identified, or namespaces which have no intention to support resolution services. These exceptions can be clarified in the namespace registration requests. 

Even if e.g. the usage of q-component is not possible when the identifier is minted, it may become relevant later when the technical infrastructure within which URNs are used becomes more mature. Note that for every URN, over time there could be literally hundreds of different q-components, facilitating various kinds of service requests. 

So from absolute-URI point of view, we need to allow queries (q-components). The one thing we cannot allow is that they would actually have a role in identification. 

> Also, just because RFC 3986 says that the query plays a role in the definition
> *in general* doesn't mean it has to for a particular scheme.
> 
> though such a retrieval is only performed if the URI is dereferenced. If no
> such representation exists, then the semantics of the fragment are
> considered unknown and are effectively unconstrained. Fragment identifier
> semantics are independent of the URI scheme and thus cannot be redefined
> by scheme specifications." --
> So for a URN this leaves the door wide open; note "If no such representation
> exists, then the semantics of the fragment are considered unknown and are
> effectively unconstrained.

The problem URN has with this starts from the very concept of "fragment identifier". URN considers fragment as something that pinpoints a location within the document identified by URN. Therefore f-component, unlike fragment, does not identify anything.  
> 
> > When URI syntax is applied to a managed URN namespace in which the
> identifier syntax and scope are strictly controlled, difficulties will emerge. I
> shall use ISBN as an example, but the issues are not ISBN-specific.
> >
> > According to URI syntax, urn:isbn:<isbn> can be extended into
> urn:isbn:<isbn>#fragment to identify some portion of the primary document.
> The namespace specific string is <isbn>#fragment since fragment must have
> a role in identification.
> >
> > This creates two problems. First, according to the ISBN standard, ISBN
> consists of 13 digits, so "#" and fragment cannot be part of the ISBN string.
> So fragment-augmented ISBN must not use the ISBN namespace, but e.g.
> namespace ISBN-frag.  In order to use fragments or queries as required by
> the URI syntax, some URN namespaces should therefore have two
> additional namespaces, one for fragments and another for queries (say,
> isbn-frag and isbn-query in addition to urn:isbn). Such namespace
> registrations do not exist and there are no plans to create them. It would be
> difficult to specify the scope of such namespaces, especially for query since
> we do not know what kind of queries will be used.
> 

Do you mean that since fragment is not part of the NSS, it does not identify anything in the URN context? Would URI syntax nevertheless mean that since fragment is part of the URI (though not part of the NSS) it will still identify something in the URI sense of the term, which in this case would be very different from the URN meaning of the term? If so, we are definitely better off using the term f-component which does not identify anything even as a part of URI. 

Having both URN identification (in which fragment is ignored) and URI syntax identification (where fragment counts) incorporated in the same URN would be confusing. We must be very clear on which parts of the URN string have a role in identification and which principles are being applied. 

> > Second, ISBN cannot be used to identify portions of books, such as
> chapters. There are other identifier standards such as BICI and DOI for this
> purpose. So fragment usage augments the scope of ISBN system in an
> unacceptable way. Note that it is not possible to modify the ISBN standard
> in such a way that fragments (or queries) could be used, first and foremost
> because after this kind of change it would be very difficult to manage ISBN
> assignment in the same quality level as before.
> 
> saying "don't do that") or leaving their meaning undefined (as per current
> RFC 3986). Does the difference really matter?

Yes. We want to allow their usage, without giving them a role in identification. An obvious use case is a researcher who wants to cite an e-book. If the book happens to have an urn:isbn and media type supporting fragments, it is easy to make a HTTP URI into the exact location wanted. But we have to explicitly allow this in the syntax, and explain that this does not mean that the researcher is creating an identifier (in the URN sense of the word) for that particular location in the book. 

> > The current version of the revised URN syntax says that fragment and
> query have no role in identification. This means that for instance in
> urn:isbn:<isbn>#f-component, the namespace specific string is <isbn> only,
> and f-component, although part of the URN, has no role in identification.
> The fragment only pinpoints a location within the resource identified by the
> ISBN. With this simple change it is possible to avoid both URN namespace
> and identifier scope related problems described above.
> 

OK. 
> 
> > Generally, I think it is a bad idea to require that URI fragment and query
> must have a role in identification, and the prose describing this practice in
> RFC 3986 is not crystal clear.
> 
> particular URI schemes. It just says that in *general*, it does play a role in
> identification. The "URN" URI scheme definition can easily say "but it
> doesn't in our case".

That "in general" has been a problem. I have not known that we could just say in the URN syntax that in the URN context query does not identify anything, and based on past discussions I wonder if some followers of this list might disagree. Therefore, even if you were correct, in order to avoid any possibility of confusion and misinterpretations I prefer the current approach in rfc2141bis which makes the difference between URIs and URNs clear already in the syntax.  

> identified by what's in the absolute-URI, and the meaning of the fragment
> either depends on the media type of the associated representation, or, in
> absence of a representation, is unconstrained.
> 
> > As regards query, I am not sure what "resource within the scope of the
> URI's scheme" means. If the URI scheme is URN, potentially anything is
> within the scope and we need to do what rfc2141bis currently does. But if
> the scheme is specified in the namespace level, then the scope of urn:isbn is
> defined by the ISBN standard to be monographs only, and for instance
> urn:isbn:<isbn>?q-component which "identifies" metadata record describing
> the book identified by ISBN is definitely not within the scope and should not
> identify anything even according to the RFC 3986. Does the URI syntax allow
> that some resources "identified" by query are outside the scope of the URI
> scheme. Or, how to specify "within the scope" and "outside the scope" in
> this context? This might well be one of those sections in RFC 3986 have
> been understood in different ways by different people, which in a standard
> document is not a good thing. Be that as it may, if the scope is a priori
> everything that queries may cover past, present and future - good luck with
> it.
> 
> It means "resource identifiable by the URI scheme". Maybe you're trying to
> read more into this statement than there is.

Perhaps so, but since the definition of resource in chapter 1.1 of RFC 3986 covers everything, the assumption of the URI syntax is that nothing is outside the scope of combined URI schemes. This enables everything to be part of the semantic web, but it also makes the management of identifiers difficult. 

> >>From URN point of view, the easiest solution would be to say in
> rfc3986bis that no resources "identified" by query are within the scope of
> the URN scheme and therefore in the URN syntax q-component has no role
> in identification unlike other URIs. Or, to formulate this less strictly, it is
> possible that in some URN namespaces some resources "identified" by
> queries may be out of the scope and therefore, to avoid any false positives,
> in URN syntax q-component never identifies anything.
> 
> > Fragments have their own general issues when used as "identifiers". It is
> non-trivial - at least to me - to see exactly what has been identified, since
> fragment isn't an identifier, but just a locator. Just to give you a simple
> example, my library has millions of digitized text documents which have very
> detailed XML schemas. Without going to any technical details, we could
> create the following URNs:
> 
> > According to the rfc2141bis, all these URNs are equivalent (they identify
> the same book, and only that), but they indicate different locations within
> the first chapter of the identified book. Anyone could create these URNs
> once the national library has established the base URN. This is not a
> mandate problem since fragments have no role in identification.
> 
> IMHO a very very surprising definition of equivalence. It probably would be
> good to use a more specific term.

Equivalence in this case means that all the URNs above identify the same book because NSS in each case is the same ISBN.  

Fragments in these examples cover different portions of the text. From URI syntax point of view, they would not identify the same thing. However, had I used f-component, it would have been clear that these f-components do not identify anything, neither under URN syntax nor URI syntax.   

> differing namespace name...

Yes, but they identify a location (the beginning of the text) or a portion of the text or both, depending on what urn-frag namespace specification says.
> 
> > and each URN would "identify" a different portion of the book, but it is not
> obvious what that portion is and how these fragment identifiers relate to
> one another, or who would have the authority to mint these identifiers.
> When resolved, they would all take the user to the beginning of the actual
> text.
> 
> I find this very very confusing. In the first case the URI identifies a book and
> also indicates a location within the book. In the second case, the URI
> identifies a location within a book.

.. or a portion of a book. Without having the namespace registration request at hand, we would not be sure which. 
> 
> Both use exactly the same syntax except for the URN namespace name.
> What do you base the distinction on, and who is supposed to understand
> that?

Sorry, I made a mistake in this example. The ISBN namespace examples should be using the q-component instead of URI query. 

URN namespaces are important. It is possible to have two URNs with identical namespace specific strings but different namespace IDs. These URNs would identify different resources and they would be resolved differently. No human needs to understand this, it is up to URN resolvers to deal with the situation. 

In this rather theoretical example, resolvers for urn:isbn and urn:isbn-fraq might produce similar results. But from identification point of view these namespaces are very different. urn:isbn only identifies books, urn:isbn-frag only locations within / portions of books. There is no overlap between these namespaces, and both of them would be managed, although probably by different kinds of organizations.   

All the best,   

Juha

PS. I shall be on holiday next week and do not intend to read my work email.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 May 2016 16:54:20 +0200

> In the URN syntax context, we don't want to prevent a priori the usage of r/q/f-components. The only exception to this are namespaces were fragments are out of scope since nothing tangible is ident…

I continue to focus on the relation between URNs and RFC 3986. From RFC 
3986's point of view, it doesn't matter at all how you name this stuff, 
as long as it doesn't conflict with RFC 3986.

Looking at the urnbis grammar:

>
>       namestring    = assigned-name
>                       [ rq-components ]
>                       [ "#" f-component ]
>       assigned-name = "urn" ":" NID ":" NSS
>       NID           = (alphanum) 0*30(ldh) (alphanum)
>       ldh           = alphanum / "-"
>       NSS           = pchar *(pchar / "/")
>       rq-components =  ( "?="  q-component
>                           [ "?+" r-component ] ) /
>                        ( "?+" r-component
>                           [ "?="  q-component ] )
>       q-component   = pchar *( pchar / "/" / "?" )
>       r-component   = pchar *( pchar / "/" / "?" )
>       f-component   = fragment

I note that f-component is only referenced in "namestring", and that 
term occurs only once in the whole spec.

It *looks* that it intends to make the fragment part of the NSS 
(right?), which would violate the RFC 3986 *syntax*. You can't have an 
unescaped "#" in an absolute-URI.

> Even if e.g. the usage of q-component is not possible when the identifier is minted, it may become relevant later when the technical infrastructure within which URNs are used becomes more mature. N…

This is not a problem. It's totally up to the definition of the URI scheme.

> So from absolute-URI point of view, we need to allow queries (q-components). The one thing we cannot allow is that they would actually have a role in identification.

Again, the URI scheme definition can define how URIs in *that* scheme 
identify things, which implies that parts of the URI do not. (I 
personally find that idea very strange, but then, I'm currently not 
focusing on that).

> The problem URN has with this starts from the very concept of "fragment identifier". URN considers fragment as something that pinpoints a location within the document identified by URN. Therefore f…

That doesn't make any sense to me. How can something "pinpoint a 
location" but not "identify"?

That being said it sounds like you're looking for something that isn't a 
fragment identifier. If this is that case, create a new syntactical, 
URN-specific component that can not be confused with a URI fragment 
identifier.This rules out introducing it with "#".

> Do you mean that since fragment is not part of the NSS, it does not identify anything in the URN context? Would URI syntax nevertheless mean that since fragment is part of the URI (though not part…

A literal "#" can not appear in the NSS, thus the NSS can't contain a 
fragment identifier in the sense of RFC 3986. You can *append* a 
fragment identifier to a URN: URI, but that means it's still falls under 
what RFC 3986 says about it.

(This discussion shows why it's essential that it's clear what exactly 
the URN specs try to "update" in RFC 3986)

> Having both URN identification (in which fragment is ignored) and URI syntax identification (where fragment counts) incorporated in the same URN would be confusing. We must be very clear on which p…

I'm still not convinced that there's a problem here.

Do

   http://example.net/#foo

and

   http://example.net/#bar

identify the same resource? No (or not necessarily). Do the absolute-URI 
parts of these URIs identify the same primary resource? Yes.

Is this really so different from your problem space?

> Yes. We want to allow their usage, without giving them a role in identification. An obvious use case is a researcher who wants to cite an e-book. If the book happens to have an urn:isbn and media t…

As the fragment identifier by definition isn't part of the 
namespace-specific string, how is that a problem? (Apart from the urnbis 
spec grammar getting this wrong?)

> That "in general" has been a problem. I have not known that we could just say in the URN syntax that in the URN context query does not identify anything, and based on past discussions I wonder if s…

No, it's really not a problem. URI schemes vary on normalization thus on 
what identifies different things. See all of 
<https://greenbytes.de/tech/webdav/rfc3986.html#normalize-scheme>.

> Perhaps so, but since the definition of resource in chapter 1.1 of RFC 3986 covers everything, the assumption of the URI syntax is that nothing is outside the scope of combined URI schemes. This en…

That maybe true, but what's the concrete conclusion with respect to 
URNs? Just because RFC 3986 says that a URI essentially can identify 
anything doesn't mean the same things needs to be true for URI in the 
URN scheme.

> Equivalence in this case means that all the URNs above identify the same book because NSS in each case is the same ISBN.

Let's use "URN-quivalent" instead of "equivalent" for a moment.

So you want that two URIs are "URN-equivalent" when their absolute-URI 
parts identify the same primary resource.

You can define this sort of equivalence (as any URI scheme can have it's 
own scheme-specifc equivalence rules). I just don't find that type of 
equivalence definition very useful (because it's very counter-intuitive).

> Fragments in these examples cover different portions of the text. From URI syntax point of view, they would not identify the same thing. However, had I used f-component, it would have been clear th…

You lost me. What's the difference if you had used f-components instead 
of fragments? What would these URIs look like?

> Sorry, I made a mistake in this example. The ISBN namespace examples should be using the q-component instead of URI query.

OK, can we please re-do the examples, and the re-start the discussion?

> URN namespaces are important. It is possible to have two URNs with identical namespace specific strings but different namespace IDs. These URNs would identify different resources and they would be…

Yes. I don't believe anybody disagrees with that.

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Fri, 20 May 2016 11:18:09 -0400

Julian,

I'm still trying to wait for instructions from the co-Chairs
before getting drawn into this thread, but one substantive
clarification below...

--On Friday, May 20, 2016 16:54 +0200 Julian Reschke
<[email-masked]> wrote:

> I note that f-component is only referenced in "namestring",
> and that term occurs only once in the whole spec.

Yes, that was our interpretation of what the WG told us to do
when we were told quite forcefully (IIR, by a 3986 co-author)
that fragment was strictly a matter of the definition in 3986
and that 2141bis should not say anything about it.   If 3986 is
now to be read the way you suggest such that, (approximately)
because URNs do not resolve directly to an object with a media
type, they can and should be defined by the scheme and maybe on
a per-namespace basis, I think we can find some old text to put
back in.     Speaking personally (but as the person holding the
pen at the moment) I really don't care which option is chosen,
only that we do not keep going around in circles about it.

> It *looks* that it intends to make the fragment part of the
> NSS (right?), which would violate the RFC 3986 *syntax*. You
> can't have an unescaped "#" in an absolute-URI.

How do you reach that conclusion?    I see

The NSS is part of <assigned-name> (see syntax quoted above) and
f-component (and therefore "fragment") hangs off the end of the
namestring, following "#".

If that is not compatible with the 3986 syntax (especially the
syntax that conforms to RFC 2234/ 4234/ 5234), I need help in
understanding why.

best,
    john

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 May 2016 17:38:21 +0200

> and that 2141bis should not say anything about it.   If 3986 is

But then why *does* it say something about fragments?

> back in.     Speaking personally (but as the person holding the

When say "they", are you referring to fragments? In which case: no, 
that's not what I meant. I was just trying to understand what the 
grammar says, ans was confused by the way it's currently defined.

> namestring, following "#".

Ah, ok. So what *is* a namestring then? It now sounds it is a RFC 3986 
URI ("URI" ABNF production) in the "urn" URI scheme. In which case the 
spec should say so (and "namestring" is really a confusing term).

Best regards, Julian