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

["Pierre GODEFROY" <[e-mail]>]

Alfred,

Thank you very much for your very careful review of draft-ietf-urnbis-rfc3044bis-issn-urn-00.

Your remarks and proposal seem logical to me, in particular the very first one concerning "backwards compatibility" with the previous version of the RFC, so as to avoid any ambiguity on this very important point.

I would only like to add, based on the private exchanges we had, that your suggestion concerning section 4.5.2 :

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

is not necessarily relevant : the issue of the "updating and management of URLs" is indeed an "additional consideration", in the sense that, however important it may be, it has no impact on the fundamental "philosophy" of the mechanism described in the RFC.

Kind regards,

Pierre

Pierre Godefroy
Project Manager
ISSN International Centre
45 rue de Turbigo
75003 PARIS
France
Tel : [phone]

-----Message d'origine-----
De : Alfred HÎnes [mailto:[e-mail]] 
Envoyé : mercredi 21 mars 2012 16:07
À : Pierre GODEFROY; [e-mail]
Objet : A review of draft-ietf-urnbis-rfc3044bis-issn-urn-00

[ 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: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+