Subject: Re: [urn] next steps

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 3 Nov 2014 17:10:17 +0000

Peter, all,

> I have a revised I-D almost ready for consideration by the WG, which I
> plan to submit tonight.
> 
> Two things to note:
> 
> 1. Because of his significant contributions to the concepts and text, I
> have added John Klensin as co-author.
> 
> 2. To reduce confusion and cross-references (and with approval of the WG
> chairs), I have combined 2141bis and 3406bis into a single document that
> covers both URN syntax and URN namespaces.
> 
> Naturally, there are still some open issues being discussed on the list.
> I cannot promise that the revised I-D closes them all, but I think it
> brings us much closer to having a specification we can live with.

Having finally come around to read 2141bis-08, it certainly brings me towards a spec I can live with. There are some things I have issues with (particularly the relation between q-components and resolvers), but I'm not concerned enough about them that I'd try to stop it from becoming a specification. 

Comments (please read them in the light of the above):
1) §1 states that "a string that conforms to the URN syntax is not necessarily a valid URN [...]." Is there a way to find out if something just looks like a URN or if it actually is one? If so, I think we should add some text explaining that.
2) My reading of §3 is that p-component is not part of the NSS. Is that correct? If so, the URN comparison becomes a bit counter-intuitive since the p-component is used to determine comparison and it would be easier to state that for comparison, only the schema, the NID and the NSS are relevant.
3) The last sentence in §3 has two verbs in it (describe provide), to me "provide" sounds best.
4) §3.1: This shouldn't be a problem since there currently are no NSS ending with '-', but we should add some text about that.
5) §3.3 (this is my main concern): the third paragraph says "For example, it is possible that the q-component might be used in requests to URN resolution services." I still think that the components of a URN should apply to the identified resources and not be hijacked to pass information to other services (e. g. resolvers). Information related to resolution services should be part of 2483bis.
6) In §4.2 is would be helpful to have some examples using p-, q- and f-components, too.
7) §5: What is a URI browser? A short search did not reveal any really useful information...

So yes, from me there is rough consensus that we can move forward with this.

Best,

Lars

---

From: Juha Hakala <[email-masked]>
Date: Tue, 04 Nov 2014 15:15:56 +0200

Hello Lars,

Some tentative answers below.

>> 1) §1 states that "a string that conforms to the URN syntax is not necessarily a valid URN [...]." Is there a way to find out if something just looks like a URN or if it actually is one? If so, I…

URNs must conform both to the general requirements set by URI syntax 
and  constraints specified in the namespace registration request (if 
any). Within URN:ISBN namespace only those URNs are valid in which NSS 
is conformant to either ISBN-10 or ISBN-13 (or some future version of 
the ISBN standard).

If the namespace registration request specifies the NSS syntax in 
sufficient detail it is possible to determine if the URN is valid. But 
there are many namespaces including URN:NBN in which there is no way to 
determine whether the NSS is well formed or not.
>> 2) My reading of §3 is that p-component is not part of the NSS. Is that correct? If so, the URN comparison becomes a bit counter-intuitive since the p-component is used to determine comparison and…

Agreed. Alas, I have to admit that I don't understand the role of 
p-component in the URN syntax / URN comparison. I wonder if this 
uncertainty concerning the role of p element is just one aspect of a 
more general question: what path actually means in the URN context. I am 
tempted to say that it is allowed in theory in order to maintain 
conformance to RFC 3986, but any namespace which plans to allow its 
usage should consider that decision carefully. I am pretty sure that ISO 
identifiers shall not use it, but URN:NBN may be a different story.
>> 5) §3.3 (this is my main concern): the third paragraph says "For example, it is possible that the q-component might be used in requests to URN resolution services." I still think that the componen…

Based on the practical experiences we know that resolution services 
required / available will change over time. I don't think that carving 
resolution services (and service parameters) in stone (standards track 
RFC) is a good idea, since we have to be able to add (at least in the 
context of ISO bibliographic identifiers and systems using them) new 
services & service parameters easily but in a controlled manner.

Whether the components apply to the identified resource strictly or 
loosely is determined by the URI syntax. F-component, assuming that it 
bears resemblance to fragment, has to be closely linked to the 
identified resource which in this case has to be a single manifestation 
of a work. The relation between the identified resource and the result 
of the resolution process is less strict (but it still exists) if the q 
component is applied. I see no problem in applying the q component for 
e.g. retrieving descriptive / administrative / etc. metadata about the 
identified resource.

Usage of q component for passing requests to resolution services is 
likely to happen even if URNBIS cannot agree on if and how the q 
component should be used. Information sciences community must make its 
URN resolvers more versatile, and q component seems to be the simplest 
means for this. Other persistent identifiers (ARK and Handle) are 
already using query for passing resolution requests. If IETF version of 
URN syntax does not provide the functionality my community urgently 
needs, then one option we must consider is to develop our own, enriched 
version of the URN syntax. Unlike URNBIS, we would approach this 
challenge mainly from practical point of view. Whether our version would 
be 100 % compliant with whatever it is that some people think URI syntax 
requires /allows would not be the topmost priority for us. And to be 
honest, we don't care too much if there is something wrong with RFC 
3986, as long as the real / imaginary issues do not prevent URNBIS from 
achieving useful results.

  Best regards,

Juha

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

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678