Using National Bibliography Numbers as Uniform Resource Names
draft-hakala-urn-nbn-rfc3188bis-02

[Ballot comment]
Thanks for resolving my DISCUSS point.

The current version still has some lower case instances of "must", "should" and "may", but does not use the RFC 8174 boilerplate. Please fix one or the other.

[Ballot discuss]
I think this document may benefit from an Internationalization
Considerations sections, but am not entirely sure how needed it is.
So let's discuss it...

In particular, the URN:NBN lexical equivalence rules include several
case-insensitive comparisons, for the prefix and for the case of the
hex digits in any percent-encoded values, but do not specify any
operation on the decoded percent-encoded values/characters.  In many
(perhaps even most?) cases, ignoring such encoded characters for
purposes of case-insensitive comparison is the wrong thing to do,
but if I understand correctly, it actually is the correct thing to
do in this case.  Namely, a NBN (or URN:NBN), once assigned, is
essentially static data and consumers of it should not attempt to
perform modification, Unicode normalization, etc. on it -- that
would potentially change what is being identified (or render the
identifier invalid).  On the other hand, a national library or
delegated institution that is assigning NBNs may wish to take into
account Unicode normalization rules and other similar considerations
while assigning NBNs (in particular, the nbn_string component), as
part of their allocation policy.  Because these can be subtle, it
may be worth explicitly pointing out the potential issues for
registration authorities.  That, plus the directive to consumers to
not normalize, seems like it would be appropriate content for an
Internationalization Considerations section.

Separately, in Section 4.2.1 where we cover 4-components, I noted
that RFC 8141 rather discourages actually using r-components until
their semantics are standardized.  The text here seems to be giving
free reign for national libraries to assign their own semantics
without any coordination with a broader community.  Do we really
want to advocate for this, as opposed to attempting to get broadly
unified semantics for r-components Internet-wide?  (Perhaps we
already have and I just missed it; if so, a reference here would be
appropriate.)

[Ballot comment]
I'm a little confused on some of the places in the text that talk
about URN:NBNs being "generated from" NBNs (and non-reuse
thereafter) or restrictions on URN:NBN assignment (e.g.,
uniqueness).  The procedure seems to be basically deterministic for
creating a URN:NBN once an NBN is assigned, and potentially
something that could be done by any party in possession of the NBN
(i.e., not necessarily the registration authority that created the
NBN).  So I'm not sure why the act of generating the URN:NBN has any
significance, if anyone could do it -- the restrictions would need
to apply at NBN assignment time in order to be useful.  (This kind
of gets into Ben's DISCUSS point, too, in the sense that we can only
say what prerequisites there are for national library NBN allocation
policies in order for them to be useful with URN:NBN, but they can
in principle do whatever they like and choose to not use URN:NBN.)


Section 3.2

  From the library community point of view it is important that the
  f-component is not a part of the NSS and therefore f-component
  attachment does not mean that the relevant component part is
  identified.  Moreover, the resolution process still retrieves the
  entire resource even if there is an f-component.  The fragment
  selection is applied by the resolution client (e.g., browser) to the
  media returned by the resolution process.  In other words, in this
  latter case the fragments are logical and physical components of the
  identified resource whereas in the former cases these "fragments" are
  actually complete, independently named entities.

I'm not sure I'm understanding this correctly -- is the "former
case" the thing that libraries should not do, namely, including the
f-component in the NSS?

  If an NBN identifies a work, descriptive metadata about the work
  SHOULD be supplied.  The metadata record MAY contain links to
  Internet-accessible digital manifestations of the work.

This left me confused.  Is it only intended to apply in the case
described in the previous paragraph, where the resource identified
by the NBN is not available in the Internet?  Or does it always
apply, forcing the metadata to take precedence over delivering the
actual work?  (Or maybe I'm just confused, and there's an easy way
to deliver both metadata and the actual work alongside each other
with no ambiguity.)

Section 4.1

  National Bibliography Number (NBN) is a generic term referring to a
  group of identifier systems administered by the national libraries
  and institutions authorized by them.

"the national libraries" implies a specific set -- which ones?  It
may be better to hedge with "some national libraries".

Section 4.2.2

Do we need to say anything about a URN-to-URI step before talking
about URI-to-resource services?

I'm also wondering about any relationship between "component
resource" NBNs and f-components of the containing work.  If there is
are NBNs assigned to both an image within a work and that containing
work, and an NBN with f-resource is used to refer to the image
within the containing work, is there any relationship between the
f-resource and the image-specific NBN?

Section 4.3

  Expressing NBNs as URNs is usually straightforward, as only ASCII
  characters are allowed in NBN strings.  If necessary, NBNs MUST be
  translated into canonical form as specified in RFC 8141.

When is it necessary?

  Being part of the prefix, sub-namespace identifier strings are case-
  insensitive.  They MUST NOT contain any hyphens.

This MUST seems to just duplicate a syntactic requirement from the
ABNF; is RFC 2119 language really necessary?

Section 8

  John Klensin provided significant editorial and advisory support for
  late versions of the draft.

Presumably that's "later versions"?

[Ballot comment]
I support Ben's DISCUSS. I appreciate that the authors want to tell national libraries what to do, but I don't think it's appropriate to do in the IETF stream.

[Ballot discuss]
This should be easy to resolve; if other ADs believe that this approach is appropriate, I will clear. But I want to make sure we've thought it through:

The draft states a number of normative requirements for how National Libraries manage the namespace. What standing does an IETF informational RFC have to tell the NLs what to do?  I think it would be better to state such things as assumptions, or even as non-normative guidance about why the NLs would want to follow these requirements.

Please note, however, that simply changing MUSTs to musts would not solve my concern; the normative vs non-normative question is only incidental to my concern.

[Ballot comment]
- I agree with the Gen-ART reviewer's comments about the use of 2119 keywords. (I am intentionally stating this as a non-blocking comment, separate from my DISCUSS points.)

§1. RFC 2119 boilerplate: There are lower case instances of 2119 keywords. If the final version continues to use 2119 keywords, please consider using the boilerplate from RFC 8174, instead.

§3.1: 
- First Paragraph: Please elaborate on the differences between identifying a manifestation vs identifying a work or expression. I can guess, but it would be better to state it explicitly.  (I assume by "work or expression", you mean all versions of a resource).

- 2nd and 3rd paragraph: The guidance that NBNs SHOULD only be used when standard identifiers are not available seems to conflict with the intent that NBNs be be used in addition to or in parallel to established systems.

§4.5:
- First paragraph: I'm not sure of the intent behind "resources that have been prioritized in the organization’s digital
  preservation plan." Does that mean resources that are expected to be long-lived?

- Last paragraph: s/ "resource has disappeared" / "resource disappears"

Review updated 2018-06-03 to cover -01.

(1) This document is of type Informational, which is
the same type as RFC 3188 and is appropriate for
this specification.

(2)

Technical Summary

  This specification updates the URN namespace
  registration for National Bibliography Numbers
  (NBNs), which are used intensively by a number of
  European national libraries. The primary change
  from RFC 3188 is the addition of support for URN
  q-components and f-components as specified in
  RFC 8141 (the updated definition of URNs).

Working Group Summary

  This specification was slated to be completed by
  the URNBIS Working Group but was decoupled from WG
  deliverables because of changes made to the URN
  namespace registration process between RFC 3406
  and RFC 8141 (i.e., IETF consensus is no longer
  required for registration of formal namespaces, only
  Expert Review). However, publication of this document
  as an RFC will ensure that the updated definition of
  NBN URNs is available in a stable specification that
  obsoletes RFC 3188.

Document Quality

  As noted, a number of national libraries in Europe have
  implemented systems that support the NBN namespace
  and have generated millions of URNs in the namespace.
  This specification accurately documents the syntax and
  management of the NBN namespace.

Personnel

  The Document Shepherd is Peter Saint-Andre (co-author
  of RFC 8141). The Responsible Area Director is Alexey
  Melnikov.

(3) The Document Shepherd has reviewed the specification
at several stages in its lifecycle as a WG and non-WG
document, and deems the document ready for publication.

(4) The Document Shepherd has no concerns about the depth
or breadth of reviews. John Klensin (the other co-author
of RFC 8141) in particular has provided in-depth feedback,
as have representatives of several national libraries in Europe.

(5) No special reviews are needed.

(6) Although from an editorial perspective several of the sections
could be condensed, the Document Shepherd has no concerns
with the substance of the specification.

(7) The author has confirmed that any and all appropriate
IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79 have already been filed.
However, he is not personally aware of any such IPR.

(8) No IPR disclosures have been filed with regard to this
document because as far as we know there is no IPR.

(9) This document is not currently the product of a WG, but
there was strong agreement to publish it when it was a
deliverable of the URNBIS WG.

(10) No appeals or expressions of significant discontent have
appeared.

(11) There is an unused reference to RFC 1321.

(12) The document meets the review criteria for registration
of formal URN namespaces as described in RFC 8141.

(13) All references within this document have been identified
as either normative or informative. None of the informative
references should be normative.

(14) There are no normative references to documents that are
not ready for advancement.

(15) There are no downward normative references.

(16) Publication of this document will obsolete RFC 3188, and
this change of status is noted in the title page header, listed
in the abstract, and discussed in the introduction.

(17) The IANA considerations section requests an update to the
existing registration for the NBN URN namespace (in line with
the process specified in RFC 8141), and is consistent with the
body of the document.

(18) No new IANA registries are requested.

(19) The ABNF definition in Section 4.2 has been checked, and
corrections were made in version -01 of the I-D.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-hakala-urn-nbn-rfc3188bis-00. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Formal URN Namespaces registry on the Uniform Resource Names (URN) Namespaces registry page located at:

https://www.iana.org/assignments/urn-namespaces/

the URN Namespace NBN appears with a reference of RFC3188. This registration will be changed to include the template found in Section 5 of [ RFC-to-be ].

IANA Question --> Should the reference for the URN Namespace NBN be changed from RFC3188 to [ RFC-to-be ]?

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

(1) This document is of type Informational, which is
the same type as RFC 3188.

(2)

Technical Summary

  This specification updates the URN namespace
  registration for National Bibliography Numbers
  (NBNs), which are used intensively by several
  European national libraries. The primary change
  from RFC 3188 is the addition of support for URN
  q-components and f-components as specified in
  RFC 8141, the updated definition of URNs.

Working Group Summary

  This specification was slated to be completed by
  the URNBIS Working Group but was decoupled from WG
  deliverables because of changes made to the URN
  namespace registration process between RFC 3406
  and RFC 8141 (i.e., IETF consensus is no longer
  required for registration of formal namespaces, only
  Expert Review). However, publication of this document
  as an RFC will ensure that the updated definition of
  NBN URNs is available in a stable specification that
  obsoletes RFC 3188.

Document Quality

  As noted, several national libraries in Europe have
  implemented systems that support the NBN namespace
  and have generated millions of URNs in the namespace.
  This specification accurately documents the syntax and
  management of the NBN namespace.

Personnel

  The Document Shepherd is Peter Saint-Andre (co-author
  of RFC 8141). The Responsible Area Director is Alexey
  Melnikov.

(3) The Document Shepherd has reviewed the specification
at several stages in its lifecycle as a WG and non-WG
document, and deems the document ready for publication.

(4) The Document Shepherd has no concerns about the depth
or breadth of reviews. John Klensin (the other co-author
of RFC 8141) in particular has provided in-depth feedback.

(5) No special reviews are needed.

(6) Although at an editorial level several of the sections
could be condensed, the Document Shepherd has no concerns
with the substance of the specification.

(7) The author has confirmed that any and all appropriate
IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79 have already been filed.
However, he is not personally aware of any such IPR.

(8) No IPR disclosures have been filed with regard to this
document because as far as we know there is no IPR.

(9) This document is not currently the product of a WG, but
there was strong agreement to publish it when it was a
deliverable of the URNBIS WG.

(10) No appeals or expressions of significant discontent have
appeared.

(11) Appendix A mentions 2141bis and 3406bis, but these should
simply reference RFC 8141.

(12) The document meets the review criteria for registration
of formal URN namespaces as described in RFC 8141.

(13) All references within this document have been identified
as either normative or informative. None of the informative
references should be normative.

(14) There are no normative references to documents that are
not ready for advancement.

(15) There are no downward normative references references.

(16) Publication of this document will obsolete RFC 3188, and
this change of status is noted in the title page header, listed
in the abstract, and discussed in the introduction.

(17) The IANA considerations section requests an update to the
existing registration for the NBN URN namespace (in line with
the process specified in RFC 8141), and is consistent with the
body of the document.

(18) No new IANA registries are requested.

(19) The specification includes no content subject to automated
checks.

(1) This document is of type Informational, which is
the same type as RFC 3188.

aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeefffff

(2)

Technical Summary

  This specification updates the URN namespace
  registration for National Bibliography Numbers
  (NBNs), which are used intensively by several
  European national libraries. The primary change
  from RFC 3188 is the addition of support for URN
  q-components and f-components as specified in
  RFC 8141, the updated definition of URNs.

Working Group Summary

  This specification was slated to be completed by
  the URNBIS Working Group but was decoupled from WG
  deliverables because of changes made to the URN
  namespace registration process between RFC 3406
  and RFC 8141 (i.e., IETF consensus is no longer
  required for registration of formal namespaces, only
  Expert Review). However, publication of this document
  as an RFC will ensure that the updated definition of
  NBN URNs is available in a stable specification that
  obsoletes RFC 3188.

Document Quality

  As noted, several national libraries in Europe have
  implemented systems that support the NBN namespace
  and have generated millions of URNs in the namespace.
  This specification accurately documents the syntax and
  management of the NBN namespace.

Personnel

  The Document Shepherd is Peter Saint-Andre (co-author
  of RFC 8141). The Responsible Area Director is Alexey
  Melnikov.

(3) The Document Shepherd has reviewed the specification
at several stages in its lifecycle as a WG and non-WG
document, and deems the document ready for publication.

(4) The Document Shepherd has no concerns about the depth
or breadth of reviews. John Klensin (the other co-author
of RFC 8141) in particular has provided in-depth feedback.

(5) No special reviews are needed.

(6) Although at an editorial level several of the sections
could be condensed, the Document Shepherd has no concerns
with the substance of the specification.

(7) The author has confirmed that any and all appropriate
IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79 have already been filed.
However, he is not personally aware of any such IPR.

(8) No IPR disclosures have been filed with regard to this
document because as far as we know there is no IPR.

(9) This document is not currently the product of a WG, but
there was strong agreement to publish it when it was a
deliverable of the URNBIS WG.

(10) No appeals or expressions of significant discontent have
appeared.

(11) Appendix A mentions 2141bis and 3406bis, but these should
simply reference RFC 8141.

(12) The document meets the review criteria for registration
of formal URN namespaces as described in RFC 8141.

(13) All references within this document have been identified
as either normative or informative. None of the informative
references should be normative.

(14) There are no normative references to documents that are
not ready for advancement.

(15) There are no downward normative references references.

(16) Publication of this document will obsolete RFC 3188, and
this change of status is noted in the title page header, listed
in the abstract, and discussed in the introduction.

(17) The IANA considerations section requests an update to the
existing registration for the NBN URN namespace (in line with
the process specified in RFC 8141), and is consistent with the
body of the document.

(18) No new IANA registries are requested.

(19) The specification includes no content subject to automated
checks.

The following Last Call announcement was sent out (ends 2018-05-21):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, stpeter@mozilla.com, draft-hakala-urn-nbn-rfc3188bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using National Bibliography Numbers as Uniform Resource Names) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'Using National Bibliography Numbers as Uniform
Resource Names'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-05-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  National Bibliography Numbers, NBNs, are used by the national
  libraries and other organizations in order to identify resources in
  their collections.  Generally, NBNs are applied to resources that are
  not catered for by established (standard) identifier systems such as
  ISBN.

  A URN (Uniform Resource Names) namespace for NBNs was established in
  2001 in RFC 3188.  Since then, several European national libraries
  have implemented URN:NBN-based systems.

  This document replaces RFC 3188 and defines how NBNs can be supported
  within the updated URN framework.  A revised namespace registration
  (version 4) compliant to RFC 8141 is included.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-hakala-urn-nbn-rfc3188bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-hakala-urn-nbn-rfc3188bis/ballot/


No IPR declarations have been submitted directly on this I-D.