Re: [urn] URN namespace for NBNs
"Hakala, Juha E" <juha.hakala@helsinki.fi> Fri, 04 May 2018 08:30 UTC
Return-Path: <juha.hakala@helsinki.fi>
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 E4D7F1241FC for <urn@ietfa.amsl.com>; Fri, 4 May 2018 01:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVlBejUfY7DR for <urn@ietfa.amsl.com>; Fri, 4 May 2018 01:30:21 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0355126CB6 for <urn@ietf.org>; Fri, 4 May 2018 01:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tdDNYbG6Mw0/a1PTFGPKgYTb/fIqa1y902PnvGJ9cRs=; b=AdmC8vY99P6DjiwZBFPUMMlRiaijUndEDzO4GQlYYpVU3EnYDlMXNuyARZqzmfxQxfv12j4yaB5dEysybjtZfGQDr5HVA4kHd4udyBrJzHMWf0zVC9c3/Qs7kHDh3jPjl+apxkyopM2PRVEESNN7XG6kW6z4VejU+3yH2WIX0so=
Received: from HE1PR07MB3097.eurprd07.prod.outlook.com (10.170.244.159) by HE1PR07MB1595.eurprd07.prod.outlook.com (10.169.123.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.735.6; Fri, 4 May 2018 08:30:16 +0000
Received: from HE1PR07MB3097.eurprd07.prod.outlook.com ([fe80::fc60:af8e:7ebe:f6ef]) by HE1PR07MB3097.eurprd07.prod.outlook.com ([fe80::fc60:af8e:7ebe:f6ef%5]) with mapi id 15.20.0735.008; Fri, 4 May 2018 08:30:16 +0000
From: "Hakala, Juha E" <juha.hakala@helsinki.fi>
To: "Dale R. Worley" <worley@ariadne.com>
CC: John C Klensin <klensin@jck.com>, "L.Svensson@dnb.de" <L.Svensson@dnb.de>, "stpeter@stpeter.im" <stpeter@stpeter.im>, "alexey.melnikov@isode.com" <alexey.melnikov@isode.com>, "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] URN namespace for NBNs
Thread-Index: AQHT41DSmzY7klZuEkyzsOBieLt7RqQfM3Tw
Date: Fri, 04 May 2018 08:30:15 +0000
Message-ID: <HE1PR07MB3097E9C7F5811ABED0F1D7D0FA860@HE1PR07MB3097.eurprd07.prod.outlook.com>
References: <F7B5168013274F8F04FE8560@PSB> (klensin@jck.com) <871ses4055.fsf@hobgoblin.ariadne.com>
In-Reply-To: <871ses4055.fsf@hobgoblin.ariadne.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [128.214.147.95]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR07MB1595; 7:r4POoAibYxUEN3XH9A2aqP3+m+RqdaTuZHx9ddj4JMupsa/gGQjA5LD47ZpLahHdVG8Rb9NovCH9BsS26vfOpQ4FGUiNeTta+GbKNjnEluXGPU78mQsdSGJvMWfsWcmNX5RNIO+mtX49dyMpk15YqSFAKakkRpWknmYq7eu2pykl9r+Fs9fLq9hI/AKIo/Kfo8BU4LEW2FtLl2IyY9dXIGavJEsqNfpXPh6zWTXH1QKUtlDBXx3DOTsEU4hXDKSm
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:(104073047261496); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(2017052603328)(7153060)(49563074)(7193020); SRVR:HE1PR07MB1595;
x-ms-traffictypediagnostic: HE1PR07MB1595:
x-microsoft-antispam-prvs: <HE1PR07MB159545C57109F1A983843139FA860@HE1PR07MB1595.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(788757137089)(104073047261496)(157537322789937);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231254)(11241501184)(806099)(944501410)(52105095)(10201501046)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR07MB1595; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1595;
x-forefront-prvs: 06628F7CA4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(396003)(39380400002)(39860400002)(189003)(199004)(13464003)(486006)(2906002)(6506007)(478600001)(5890100001)(7696005)(5660300001)(25786009)(68736007)(99936001)(8936002)(11346002)(102836004)(6346003)(3280700002)(9686003)(26005)(305945005)(81156014)(105586002)(7736002)(2900100001)(6436002)(106356001)(3660700001)(186003)(476003)(97736004)(99286004)(446003)(33656002)(74316002)(74482002)(6116002)(3846002)(6246003)(6916009)(59450400001)(76176011)(53936002)(229853002)(55016002)(14454004)(316002)(4326008)(66066001)(54906003)(86362001)(786003)(8676002)(81166006)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1595; H:HE1PR07MB3097.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi;
x-microsoft-antispam-message-info: +rnaawJJirRp5BIso6NM8oMelaqDI9sQFdIaxOJ6CwfkwuRiSnCkf5pwE4nhlz8+zAk00f9MAGXwD3HdmzAmOfVPndpB7mCUyywbgXajFGB32g54fuWWqkVXx+g6l6Q8OY2I6Et1dt4KvIG7FW25fdb8MIzjqqlH1QjpkDPuqL5hAmWs1850M+EphFE68JYlA/iuxwlVSiOVTplpbcTWthPC/dOm2LFz9fdicpTHHXwualb93s2fIwdRaoB3aHNw
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed; boundary="_002_HE1PR07MB3097E9C7F5811ABED0F1D7D0FA860HE1PR07MB3097eurp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 5b20223d-1d9e-4705-364c-08d5b199434f
X-OriginatorOrg: helsinki.fi
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b20223d-1d9e-4705-364c-08d5b199434f
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2018 08:30:15.8619 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1595
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/nkw-64WNv99FsOA6Rfy2a707Nx0>
Subject: Re: [urn] URN namespace for NBNs
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 04 May 2018 08:30:34 -0000
Hello Dale; all, Thank you very much for reviewing the draft thoroughly! I have made almost all changes requested by you, Alexey and Peter. But I may have misunderstood something so it is necessary to check the attached result. And instead of fixing broken links I may have created a few more ;-). There were two competing suggestions on what to do with ABNF; I have used Peter's version. I do not have better terms with which to replace hand-held, immaterial or digital. They are commonly used and well understood within the library community. Work such as Hamlet is immaterial, but it becomes hand-held when it is published as a manifestation such as a printed book. PDF version of Hamlet is another manifestation of the work, not hand-held but digital / electronic. Under community concerns there were paragraphs which from your point of view dealt with the resolution process. I have modified the text in order to make it more clear why to me these things are (also and perhaps primarily) community concerns. The draft specified three different ways in which NBNs can be used to identify component parts of resources (assign separate NBN to each component part, use local NSS syntax to indicate component parts within a resource, all sharing the same base NBN belonging to the resource itself, and using URN f-component). I deleted the middle option because I am not aware of any national library using it and without giving a real example it is hard to understand how these URN:NBNs would actually work. I have added references to the new, RFC 8141 -compliant ISBN and ISSN namespace registrations and deleted the reference to I-D which was an early version of an updated ISBN namespace registration. Alfred Hoenes is still mentioned as a contributor but the text is shorter. There was no point to refer to any documents especially after I dropped the reference to the outdated URN namespace revision request I-D he worked on. All the best, Juha -----Original Message----- From: Dale R. Worley <worley@ariadne.com> Sent: perjantai 4. toukokuuta 2018 5.37 To: Hakala, Juha E <juha.hakala@helsinki.fi> Cc: John C Klensin <klensin@jck.com>; L.Svensson@dnb.de; stpeter@stpeter.im; alexey.melnikov@isode.com; urn@ietf.org Subject: Re: [urn] URN namespace for NBNs The draft looks fine to me. There are various nits, which I've listed below. Dale ---------------------------------------------------------------------- Various terminology like "hand-held", "immaterial", and "digital" is used. Do you have a clear terminology in mind? 2. Conventions used in this document "NBN" refers to any National Bibliography Number identifier system used by the national libraries and other institutions, which use these identifiers with the national library's support and permission. s/library's/libraries'/ since it is "support of libraries". (Check with the Editor!) 3.1. The URN:NBN Namespace For instance, even if a digitized book has an ISBN, JPEG image files of its pages get NBNs. You probably want to say "may get". 3.2. Community Considerations for NBNs Note that the f-component is not a part of the NSS and therefore the ... Resources identified by NBNs are not always available in the ... If an NBN identifies an immaterial work, descriptive metadata about ... These three paragraphs seem to be more about the resolution process than community considerations. Perhaps they can be separated in some way? 4.1. Overview uniqueness of the URN:NBNs at the global scale [Iso3166MA"/>. This reference is corrupted. 4.2. Encoding Considerations and Lexical Equivalence When an NBN is used as a URN, the namespace-specific string (NSS) MUST consist of three parts: o a prefix, structured as a primary prefix, which is a two-letter ISO 3166-1 country code, ... This doesn't specify *what* the country code must be. Instead, When an NBN within a national library's identifier system is used as a URN, the namespace-specific string (NSS) MUST consist of three parts: o a prefix, structured as a primary prefix, which is the two-letter ISO 3166-1 country code of the library's country, ... 5. URN Namespace ID (NID) Registration for the National Bibliography Number (NBN) Declaration of syntactic structure of NSS part: nbn_string = <specific per prefix> ; MUST adhere to RFC 3986 <path-rootless> syntax; ; parsers must regard nbn_strings as case-sensitive There is trouble with <...> here. Colon MAY be used as a delimiting character only within the prefix, between ISO 3166-1 country code and sub-namespace code(s), which split the national namespace into smaller parts. Comparing with the text in 4.2, I don't think this is phrased correctly, as it may imply that colon may not appear in the nbn_string. Reading it as: Colon MAY be used (as a delimiting character only within the prefix) ... Instead: Colon MAY be used within the prefix only as a delimiting character between the ISO 3166-1 country code and the sub-namespace code(s), which split the national namespace into smaller parts. -- See Section 4.2 of RFC XXXX for examples. There should be a note telling the RFC Editor to insert the RFC number here. Process for identifier resolution: See Section 4.3 of RFC XXXX. Ditto. Rules for lexical equivalence of NSS part: ... Formally, two URN:NBNs are lexically equivalent if they are octet- by-octet equal after the following (conceptional) preprocessing: 1. normalize the case of the leading "urn:" token; This should be 'the leading "urn:nbn:" token', as otherwise the "nbn" is not mentioned! 8. Acknowledgements Revision of RFC 3188 started during the project PersID [PERSID] Later Insert a full-stop after the reference. 9. Contributors Alfred Hoenes was the editor and co-author of two of the documents from which this one is, in part, derived. Is it possible to provide a description or reference to these documents? (One appears to be in the references already.) Appendix A. Significant Changes from RFC 3188 Updated URN:NBN Namespace Registration template for IANA; whole document adapted to new URN Syntax document, RFC 2141bis, and new URN Namespace Registration document, RFC 3406bis (now retired and merged into 2141bis. This paragraph is hard to read, and it has unbalanced parentheses. Use of query directives and fragment parts with this Namespace is now specified, in accordance with the aforementioned RFCs. The terminology in RFC 8141 is "query components" and "fragment components". [END]
- [urn] URN namespace for NBNs John C Klensin
- Re: [urn] URN namespace for NBNs Peter Saint-Andre
- Re: [urn] URN namespace for NBNs Dale R. Worley
- Re: [urn] URN namespace for NBNs Hakala, Juha E
- Re: [urn] URN namespace for NBNs Peter Saint-Andre
- Re: [urn] URN namespace for NBNs Dale R. Worley