[urn] A review of draft-ietf-urnbis-rfc3044bis-issn-urn-00

Alfred Hönes <ah@TR-Sys.de> Wed, 21 March 2012 15:08 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3617B21F8646 for <urn@ietfa.amsl.com>; Wed, 21 Mar 2012 08:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.305
X-Spam-Level:
X-Spam-Status: No, score=-98.305 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbsdDeVTUQd6 for <urn@ietfa.amsl.com>; Wed, 21 Mar 2012 08:08:14 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 18F4B21F863F for <urn@ietf.org>; Wed, 21 Mar 2012 08:08:12 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA230362425; Wed, 21 Mar 2012 16:07:05 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA23963; Wed, 21 Mar 2012 16:07:04 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201203211507.QAA23963@TR-Sys.de>
To: godefroy@issn.org, urn@ietf.org
Date: Wed, 21 Mar 2012 16:07:03 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
Subject: [urn] A review of draft-ietf-urnbis-rfc3044bis-issn-urn-00
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2012 15:08:15 -0000

[ speaking as an individual ]


I have reviewed draft-ietf-urnbis-rfc3044bis-issn-urn-00
and would like to offer some comments (see below).

A much larger bunch of editorial nits is being reported off-list
to the author, to avoid too much on-list "noise", and for
efficiency.
(Speaking as a co-chair as well: Accordingly, I would appreciate
 other reviewers to send nits off-list and/or wait until the next
 draft version had a chance to act upon the current batch.)


Overall, the draft seems to be in a very good shape already for
an -00 draft version.
Given the internal, informal approval by the ISSN International
Centre already obtained for the technical content of the draft,
I hope that enough qualified reviews will soon support progressing
this document.

Here are my suggestions for further improvements of the draft:


(1)  Emphasis on backwards compatibility

(1.1)
In the Abstract, I suggest to add some emphasis on the goal of
backwards compatibility achieved by this document -- in line
with the URNbis charter and theintended clarity for readers
(and reviewers).   For instance:

OLD:
                                              [...].  This document
   redefines how the revised ISSN standard can be supported within the
   URN framework, taking into account in particular the latest revision
   of the ISSN standard in the ISO framework (ISO 3297:2007).  [...]

NEW:
                                              [...].  This document
|  redefines -- in a backwards compatible manner -- how the revised ISSN
   standard can be supported within the URN framework, taking into
   account in particular the latest revision of the ISSN standard in the
   ISO framework (ISO 3297:2007).  [...]

(1.2)
Similarly, I suggest to add at the very end of Section 1 the
following clause:

|  This version of the URN:ISSN registration is fully backwards
|  compatible with the original one, in the sense that all ISSN URNs
|  assigned under RFC 3044 remain valid and semantically unchanged.


(2)  Discussion of Fragment Usage

The 2nd para of Section 3.2 says:

OLD:
   Continuing resources, including serials, most often consist of
   component parts such as volumes, issues, articles.  The ISSN standard
   does not allow augmentation of the ISSN of the resource with (URI)
   fragments for identification of component parts.  If a fragment
   identifier is added to an ISSN, the resulting namespace specific
   string will not be an ISSN.

This elaboration seems to be a bit twisted in detail.
>From a syntax perspective, a URI <fragment> is not a part of the
Namespace Specific String (NSS) of a URN (cf. the RFC 2141bis draft).
Further, embedding an existing namespace into a URN Namespace does not
necessarily mean that the NSS needs to be (modulo encoding, perhaps)
exactly the pre-existing (externally assigned) identifier from the
originating namespace.  There can be some additions, as long as these
can be syntactically recognized and separated out, if needed (e.g.,
for resolution systems); one example is the URN Namespace for NBNs,
which incorporates a disambiguating prefix into the NSS, in addition
to the primary (nationally assigned) NBN string.

So most likely the above quoted paragraph can be simplified.
For instance:

NEW:
   Continuing resources, including serials, most often consist of
   component parts such as volumes, issues, articles.  The ISSN standard
|  does not allow the identifiaction of component parts of the serial
|  designated by the ISSN, and the URN:ISSN Namespace equally does not
|  support such augmentation -- neither by an added NSS component nor by
|  use of URI fragment identifiers.


(3)  Section structure (1)

Section 4.1 contains an apparent sub-heading reading

  "Allocation of blocks of ISSN"

I suggest to turn this line into a sub-section headline, and as such
turning this and the rest of s4.1 into a new subsection 4.1.1.


(4)  Section structure (2)

Section 4.5.2 does not seem to be logically subordinate to Section 4.5.

I suggest to 'elevate' Section 4.5.2 to become Section 4.6.


(5)  Section 5.1 (Updated Namespace registration)

It might be worth aligning the presentation of this section with the
style used in the Appendix of the rfc3406bis draft for the formatting
of the registration template -- uniformity should further uniform use
of URN Namespace definitions.
(This tuning update can be deferred until the rfc3406bis draft has
finally stabilized with regard to this template.)


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:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+