Subject: Re: [urn] next steps

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 6 Nov 2014 20:37:13 +0000

Juha,

On 04.11.2014, Juha wrote:

> Some tentative answers below.
> 
> On 3.11.2014 19:10, Svensson, Lars wrote:
> > Peter, all,
> >
> >> 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.
> 
> 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.

OK. And trying to write some text to explain that, I realise that we haven't specified what a "valid URN" is. Is that a URN that has been registered or just one that adheres to a specific syntax?

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

I have seen some examples of strings starting with urn: that have slashes in them (IIRC it was the attempt to make a URN out of a DOI). While the intent probably was good, they currently cannot be URNs. If 2141bis allows slashes they could be (iff the namespace is updated accordingly). That said, I'm not sure it's a good idea since it could imply that relative URI references somehow could work.

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

I fully agree with that. What I think can / could / should be done is to specify some core things in 2483bis and to make the specification extensible (which can be done in other RFCs) and to keep an IANA registry of services and parameters.

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

I fear that introducing terminology such as "applies closely" or "applies loosely" will be more confusing than clarifying. Keith has argued that '"#" and "?" for URNs should be handled 
exactly like they are for the most common URLs - by being interpreted in 
the context of the resources themselves' and I tend to agree with that. (Please keep in mind that I'm still prepared to accept 2141bis-8). We could write something along the lines that if we have a string urn:example:123:456:abc?some=q-component&parameters=here, the URN ends at the last character before the '?' and that the part after the '?' is intended to be sent to a resolution service. I consider it an important engineering principle to separate concerns.

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

Yes. The question is if it's part of the identifier. If we say that URNs are identifiers, we need to be specific regarding the role of all components.

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

Would it be OK for you if we move all resolution-related features of the URN specification to 2483bis?

Best,

Lars

---

From: Juha Hakala <[email-masked]>
Date: Fri, 07 Nov 2014 09:58:00 +0200

Hello Lars,

> OK. And trying to write some text to explain that, I realise that we haven't specified what a "valid URN" is. Is that a URN that has been registered or just one that adheres to a specific syntax?
Valid URN is one which

1. Meets the syntax requirements in RCF 2141(bis),
2. Uses a registered NID,
3. Is well formed according to the administrative / semantic / syntactic 
requirements of its namespace.

For instance URN like "URN:ISNI:0000-0000-3176-4784" does not fulfill 
the requirement 2, since there is no namespace registration yet for the 
International Standard Name Identifier.  URN:DOI:10.1000/182 fails on 
two points: there is no namespace registration for DOI, and there is 
invalid character in NSS. However, both of these URNs could be 
actionable in the web in spite of not being valid.

If the identifier assigned to the resource is invalid or has been 
canceled (for instance, books sometimes have invalid ISBNs assigned to 
them by the publisher) the URN based on such identifier must be invalid 
as well, although it may nevertheless be actionable in the Web. Invalid 
ISBN is always catalogued, alongside the correct one.

> I have seen some examples of strings starting with urn: that have slashes in them (IIRC it was the attempt to make a URN out of a DOI). While the intent probably was good, they currently cannot be…

Alas, even the people with best intentions do not always know what they 
are doing ;-).

> <snip> What I think can / could / should be done is to specify some core things in 2483bis and to make the specification extensible (which can be done in other RFCs) and to keep an IANA registry of services and parameters.

The plan has been that 2483bis specifies just the mechanism via which 
the list of services and service parameters is maintained. But - for the 
sake of backwards interoperability - the document could also provide an 
initial list of these services (including the ones from RFC 2483, plus 
perhaps some more) and service parameters. For instance I2C and I2Cs 
must have such parameters, since URC never materialized and the 
preferred metadata format has to be included in the request (whether we 
can / should specify a default value is an open issue; I think Dublin 
Core might serve such purpose well).
> the context of the resources themselves' and I tend to agree with that. (Please keep in mind that I'm still prepared to accept 2141bis-8). We could write something along the lines that if we have a…

It is hard to see how "#" could be handled differently in URNs than in 
other URIs. We can't  convince the browser developers to change the 
behaviour of their applications just for URNs.

"?" behaviour is a mixed bag to start with. What resolvers do with them 
will be specific to the URN context, but such actions are not out of 
bounds from URI syntax point of view.
> Yes. The question is if it's part of the identifier. If we say that URNs are identifiers, we need to be specific regarding the role of all components.

My take on this has been that fragment and query cannot be part if the 
NSS. The same applies to f and q components. If we leave this question 
open in RFC 2141bis, then all ISO identifiers at least will not approve 
f or q components to be added to the NSS. An NSS like 
978-952-242-275-0#chapter2 would violate the ISBN community rules. But 
if we say that NSS consists of the ISBN only and the f component can be 
added to it any time after the URN has been minted, we solve a lot of 
administrative and other problems.

> Would it be OK for you if we move all resolution-related features of the URN specification to 2483bis?

Perhaps. As far as I am concerned, RFC 2141bis is OK in its current form 
and should not be modified any more without a good reason. We have spent 
enough time and effort on this project already.

Best regards,

Juha

>
> Best,
>
> Lars
>
> _______________________________________________
> 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

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Nov 2014 08:47:51 -0500

On 11/07/2014 02:58 AM, Juha Hakala wrote:
>> OK. And trying to write some text to explain that, I realise that we 
>> haven't specified what a "valid URN" is. Is that a URN that has been 
>> registered or just one that adheres to a specific syntax?
> Valid URN is one which
>
> 3. Is well formed according to the administrative / semantic / 
> syntactic requirements of its namespace.

I would claim that it needs to also actually be registered by that 
namespace, at least for those namespaces that register names.  (i.e. not 
UUIDs but nearly everything else)   We don't want people thinking that 
any syntactically valid string that begins with urn: is a valid URN and 
using that as an excuse to bypass registration requirements that ensure 
uniqueness.

Keith

---

From: Sean Leonard <[email-masked]>
Date: Sun, 9 Nov 2014 12:45:20 -1000

On Nov 7, 2014, at 5:47 AM, Keith Moore <[email-masked]> wrote:

>> 3. Is well formed according to the administrative / semantic / syntactic requirements of its namespace.
> 
> I would claim that it needs to also actually be registered by that namespace, at least for those namespaces that register names.  (i.e. not UUIDs but nearly everything else)   We don't want people thinking that any syntactically valid string that begins with urn: is a valid URN and using that as an excuse to bypass registration requirements that ensure uniqueness.

That is why (in [this post][]) I used the term “registrable” rather than “registered”. It is not necessary for an elaborate registry to be created and unfailingly maintained; it is only necessary that the names be assigned using a process that ensures uniqueness, and that those unique names can be registered if someone wants to maintain such a registry. The registry makes the names discoverable, but the registry is not a bedrock requirement for a valid URN namespace. UUIDs can be generated and assigned randomly, yet the IDs are registrable, and that works for URN purposes.

[this post]: http://mailarchive.ietf.org/arch/msg/urn/1xNZg-0JzRe-BGRROEQ6eyarXKc

Cheers,

Sean