Subject: [urn] Comments on rfc3188bis

From: Tommi Jauhiainen <[email-masked]>
Date: Fri, 11 Jun 2010 15:32:13 +0300

Hi all,

I have some comments, questions and suggestions to and about the draft  
and I'll go through them in order of appearance in the draft.

---

Chapter 3 says:
"As a rule, NBNs identify finite, manageably-sized objects, but these  
objects may still be large enough that resolution into a hierarchical  
system is appropriate."

I find the definition of size as "manageably-sized" very vague. How  
about something like this? (I left the "as a rule" out from the  
beginning as well).

"NBNs identify finite objects, but sometimes these objects might be so  
large that resolution into a hierarchical system is appropriate."

---

In chapter 4.1. it says:
"National Bibliography Number (NBN) is a generic name referring to a  
group of identifier systems utilised by the national libraries and  
institutions authorized by them, such as universities."

First I wanted to reduce repetition by removing the ", such as  
universities" away from the end, as in the previous chapter it has  
just been declared that:

"National libraries may however allow other
    organizations such as university libraries or governmental
    organizations to assign NBNs to their resources."

Then I started to ponder about the usage of "utilised" and  
"assigning". Could we use a word like "administer" instead of  
"utilise" and "use" when referring to NBNs as a system?

For example I tried to rephrase the first section of 4.1:

"National Bibliography Number (NBN) is a generic name referring to a  
group of identifier systems administered by the national libraries.  
The NBNs are assigned to resources by the national libraries and  
institutions authorized by them. These institutions should be  
committed to preserve their collections for a long time; at least  
decades and possibly centuries."

---

Chapter 4.1 says:
"URNs may also be used in universities' open repositories when a  
resource already has another identifier -- often a DOI (Digital Object  
Identifier) -- that can only be resolved in a publisher's (or third  
party's) resolution service, which cannot be used to provide linking  
to the open repository.  URN:NBN-based resolution can deliver that,  
and may also be extended to include access to other repositories  
holding the same resource."

I believe that this isn't technically correct. Maybe the whole section  
could be left out?

---

In Chapter 4.2. there is an example of:
"For instance, the national library of Finland has given Statistics  
Finland (<http://www.stat.fi/index_en.html>) a sub-namespace  
"st" (i.e., urn:nbn:fi:st)."

I'd change that example to some other sub-namespace as it happens that  
the Statistics Finland has never really used the given namespace. For  
example:

"For instance, the national library of Finland has given the  
University of Jyväskylä (<http://www.jyu.fi/>) a sub-namespace  
"jyu" (i.e., urn:nbn:fi:jyu)."

I think that this example could be left out from 4.2.:
"(NBN assigned to Tero Frestadius's Master's Thesis "In and Out":  
Segmentary Gang Politics in Los Angeles)."

---

In 4.3. it says:
"URNs can be used to provide various services.  RFC 2483 [RFC2483]  
gives a few examples, such as retrieving a single URL or all URLs  
applying to the resource.  Services available may vary, depending on  
the technical implementation of the URN resolver and the target system  
contacted.  Please note that services must not be hard codedinto the  
URN itself."

This "hard coding" is not defined anywhere and is too general as it  
is. I believe this doesn't mean MUST must but perhaps SHOULD?

---

In 4.3. also:
"Eventually, URNs will be resolved with the help of a resolver  
discovery service (RDS).  However, no such system is widely available  
yet."

Is such system available at all at the moment? (which would work  
without embedding URNs into HTTP URIs) If not really, then we perhaps  
should leave that remark out?

---

One more example correction suggestion in 4.3:
"Thus the HTTP URI for the URN in the example is <http://urn.fi/URN:NBN:fi-fe201003181510 
 >.  This in turn resolves to the actual address of the thesis, which  
as of this writing (2010-03-27) was <https://oa.doria.fi/bitstream/handle/10024/59475/inandout.pdf?sequence=1 
 >."

The urn actually resolves to the splash-page of the thesis: <https://oa.doria.fi/handle/10024/59475 
 >.

---

Chapters 4.5. and 5. are the same. I believe it is the intention to  
leave the 4.5. out?

---

The formal declaration of the NSS in 4.6. is supposed to be RFC5234  
compliant but still uses the obsolete (mentioned in RFC 3986) rule  
"ALPHANUM" in definitions:
" subspc      = 1*ALPHANUM
                        ; as assigned by the respective national library

          reg_prefix  = 3*ALPHANUM
                        ; as assigned by the Library of Congress --
                        ; identifies a trusted third party
                        ; to which the bracnh is delegated"

Correct way is now "( ALPHA / DIGIT )" instead of "ALPHANUM" so:

" subspc      = 1*( ALPHA / DIGIT )
                        ; as assigned by the respective national library

          reg_prefix  = 3*( ALPHA / DIGIT )
                        ; as assigned by the Library of Congress --
                        ; identifies a trusted third party
                        ; to which the bracnh is delegated"

---

I don't remember seeing the reasoning behind this prohibition in 4.6.:
"Dividing non-ISO 3166-based namespaces further with sub-namespace  
codes MUST NOT be done."

Would you care to enlighten me why this MUST NOT exists in the first  
place?

---

Cheers,
Tommi
-- 
Tommi Jauhiainen (Mr.)

Information Systems Specialist		Tietojärjestelmäasiantuntija
The National Library of Finland		Kansalliskirjasto

PL 26 (Teollisuuskatu 23)		http://www.kansalliskirjasto.fi/
00014 University of Helsinki		Tel. +358 50 415 0 555

---

From: Juha Hakala <[email-masked]>
Date: Fri, 11 Jun 2010 16:21:18 +0300

Hello Tommi,

Thank you for comments. Please see the responses below.

Tommi Jauhiainen wrote:
> "As a rule, NBNs identify finite, manageably-sized objects, but 
> these objects may still be large enough that resolution into a 
> hierarchical system is appropriate."
>  

Your sentence is better than the original. And I agree that 
manageably-sized is a vague concept and should be removed from the text.
>  First I wanted to reduce repetition by removing the ", such as universities" away from the end, as in the previous chapter it has just been declared that: 
> 
>  Then I started to ponder about the usage of "utilised" and "assigning". Could we use a word like "administer" instead of "utilise" and "use" when referring to NBNs as a system?  

I'm not sure. Need to think about this a bit. However,...
>  "  National Bibliography Number (NBN) is a generic name referring to a group of identifier systems administered by the national libraries. The NBNs are assigned to resources by the national libraries and institutions authorized by them. These institutions should be committed to preserve their collections for a long time; at least decades and possibly centuries." 

...this feels OK. But I feel we should strengthen the wording that 
relates to the organisational commitment to preserve resources for 
future generations by stating that these organisation must be committed 
to preserve their collections for a long time.
> 
>  --- 
> 
>  Chapter 4.1 says: 
> 
>  "  URNs may also be used in universities' open repositories when a   resource already has another identifier -- often a DOI (Digital   Object Identifier) -- that can only be resolved in a publisher's (or   third party's) resolution service, which cannot be used to provide   linking to the open repository.  URN:NBN-based resolution can deliver   that, and may also be extended to include access to other   repositories holding the same resource." 
> 
> 

This section relates to the author's past belief that if a resource has 
a DOI, it might be difficult or even impossible to use this DOI as a 
means for resolving both to the URL of the publisher's copy of the 
resource and to the URL of the copy in the university's open repository.

We need to check from DOI experts if a DOI can resolve to multiple URLs 
and if so, if the publishers are likely to allow adding links to the 
resources held in open repositories to their DOI resolution services.

As I see it there is nothing wrong with a single resource such as a 
digital manifestation of a book having single ISBN but multiple 
persistent identifiers (DOI, URN or something else) which all resolve to 
different digital items.

Given that large portions of the text in RFC 3188bis remain in original 
form there may be statements there that are by now out of date and must 
be edited or removed.
> "For instance, the national library of Finland has given 
> Statistics Finland (< http://www.stat.fi/index_en.html >) a 
> sub-namespace "st" (i.e.,  urn:nbn:fi:st) ."
> 
> "For instance, the national library of Finland has given the University 
> of Jyväskylä (< http://www.jyu.fi/ <http://www.stat.fi/index_en.html> >) 
> a sub-namespace "jyu" (i.e.,  urn:nbn:fi:jyu) <urn:nbn:fi:st)> ."

OK. It would be nice to have real examples of sub-namespaces from other 
countries (Italy, perhaps?).
> "(NBN assigned to Tero Frestadius's Master's Thesis "In and 
> Out": Segmentary Gang Politics in Los Angeles)."

I wanted to show what a real NBN-based URN actually looks like when used 
as a hyperlink. But should we drop the example?
> 
> ---
> 
> In 4.3. it says:
> " URNs can be used to provide various services. RFC 2483 
> <http://tools.ietf.org/html/rfc2483> [ RFC2483 
> <http://tools.ietf.org/html/rfc2483> ] gives a few examples, such as 
> retrieving a single URL or all URLs applying to the resource. Services 
> available may vary, depending on the technical implementation of the URN 
> resolver and the target system contacted. Please note that services must 
> not be hard coded into the URN itself. "
> 
> This "hard coding" is not defined anywhere and is too general as it is. 
> I believe this doesn't mean MUST must but perhaps SHOULD?

No, I meant MUST. What hard coding means here is that there would be 
multiple URNs for a resource, each one providing a single service. A 
base version would resolve to the resource itself. With another version 
the user would get the bibliographic record, while yet another would 
facilitate retrieval of a list of URLs, and so on.

I suppose this is one of the points which may become implementation 
issues. If there is only one URN, then there should be some other way in 
which the applications agree on what service is being called for. And 
there does not seem to be anything widely implemented in place we could 
use in e.g. PersID.

> ---
> 
> In 4.3. also:
> "Eventually, URNs will be resolved with the help of a resolver discovery 
> service (RDS).  However, no such system is widely available yet."
> 
> Is such system available at all at the moment? (which would work without 
> embedding URNs into HTTP URIs) If not really, then we perhaps should 
> leave that remark out?

If my memory serves me right, an experimental DNS-based solution was 
built, but it was only ever supported via a plug-in in browsers. It is 
definitely true that there is no widely available resolver discovery 
services in place at the moment, but I did not want to give an 
impression that nothing has been done.
> "Thus the HTTP URI for the URN in the example is < 
> http://urn.fi/URN:NBN:fi-fe201003181510 >.  This in turn resolves to the 
> actual address of the thesis, which as of this writing (2010-03-27) was 
> < https://oa.doria.fi/bitstream/handle/10024/59475/ 
> inandout.pdf?sequence=1>."
> 
> The urn actually resolves to the splash-page of the thesis: 
> <https://oa.doria.fi/handle/10024/59475>.

Do we need to provide this somewhat embarrassing detail ;-)?
> Chapters 4.5. and 5. are the same. I believe it is the intention to 

Can we leave some vital things out from the namespace registration 
request, and rely on people finding the information from other parts of 
the RFC (or vice versa)? Replication in the current text is intentional, 
but can be eliminated if that's the majority view.

>                        ; to which the bracnh is delegated"

Alfred Hoenes is better qualified than myself to respond to this.
> "Dividing non-ISO 3166-based namespaces further with sub-namespace codes 
> MUST NOT be done."
> 
> Would you care to enlighten me why this MUST NOT exists in the first place?

Yes.

When an ISO 3166 namespace is subdivided, then according to the RFC 3188 
the national library in question must maintain the registry of these 
sub-namespaces.

For non-ISO 3166 namespaces RFC 3188 states that there will be only one 
list, maintained by the Library of Congress (to my knowledge no such 
namespaces have been assigned yet, and it is not clear if there will be 
a demand for them). We do not know what kind of organisations would 
register these namespaces for themselves, and whether they would be 
willing to take the responsibility of maintaining a registry of 
sub-divisions of their namespace. For the sake of simplicity I thought 
that it would be better to just ban sub-division of these namespaces.

Best regards,

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

-- 

  Juha Hakala
  Director of IT Development

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 20 Jun 2010 21:38:50 +0200 (MESZ)

> Thank you for comments. Please see the responses below.

Juha has said most, I think.
Please see the solicited response inline below.

>> ... [snip]
>> of Jyvðskylð (< http://www.jyu.fi/ <http://www.stat.fi/index_en.html> >)

We have a specific objective in the draft URNbis WG charter:
Discussion of the kind and style of examples in the documents to be
produced by the WG, whether these should be concrete or theoretical
examples, perhaps using dedicated example namespaces (which the IESG
strongly enforces for example domain names and IP addresses in RFCs).
Please revisit the posted draft charter for context.

> I wanted to show what a real NBN-based URN actually looks like when
> used as a hyperlink. But should we drop the example?
>
>> ---
>> ... [snip]
>
>>
>> ---
>>

Every RFC needs to have a distinguished "Security Considerations"
section.  The registration template can refer to that section
as it may for other required information.  That's standing practice.
So I agree 4.5 could be replaced by a short sentence pointing to 5.

> Alfred Hoenes is better qualified than myself to respond to this.

Yes, Tommi, you are right!
This is an oversight in the -00 draft that needs to be corrected,
to align the draft with RFC 3986 and the rfc2141bis draft.
(Another possibility would of course be to introduce ALPHANUM
as a 'local' ABNF rule in this draft.)

If the BoF in Maastricht leads to WG formation (which I hope!),
we would prefer to submit the next version directly as a WG draft
and avoid the intermediate step (and work for editors and readers)
of a second individual draft.  So most likely the next draft version
will be submitted shortly after the IETF meeting.

> that it would be better to just ban sub-division of these namespaces.

Simplicity is an important goal.  Unless there are convincing
arguments to the contrary, we should not spend cycles for rules
and procedures for very far-fetched and unlikely future scenarios.
In this case, the stability argument also counts very much.

Experience in protocol work has shown that in such cases, actual
need (if it arises at all), often does not precisely match what had
been envisioned long before, and that has lead to artificial solutions
neither matching the actual need nor being a good fit for what has
been provided tentatively in advance.  In this case, we would have
to introduce mechanisms to guarantee the required properties and
strong policies, and would not even have a single example of a
non-cc sub-namespace so far that could provide guidance and indicate
circumstances that might make further organizatorial subdivision
necessary.  This overhead (in specification and operations!) should
not be undertaken too lightly.

So it might actually be wise to stay with the previous restriction.
If actual strong demand arises in (say) five years for some such
delegations, a short update document introducing what actually is
needed might be a much better choice.  For now, in place of a single
registered NBN sub-namespace with a couple of sub-sub-namespace
registrations, a couple of NBN sub-namespace directly registered
with the Library of Congress would be functionally equivalent.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+