Re: [urn] URN:DOI namespace registration request

"Hakala, Juha E" <juha.hakala@helsinki.fi> Wed, 20 January 2021 06:14 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 E7CF53A03F8 for <urn@ietfa.amsl.com>; Tue, 19 Jan 2021 22:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 cnABnirkbvjy for <urn@ietfa.amsl.com>; Tue, 19 Jan 2021 22:14:31 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50123.outbound.protection.outlook.com [40.107.5.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9480F3A03F3 for <urn@ietf.org>; Tue, 19 Jan 2021 22:14:31 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cW/yjzQgoiPbLaTwHeRkJKfIZRFXa4oiJ+T4KgJkVFV1Dms+z+VLKSI1jN9PFcqdYClwzEfi5p2JnokKeeYKTatyvL/r0uWVTLtjlpUYR2p3iWnhWuq5bnDjo/5lfqSdMqZTJ6xN07xqlRp2W3YN+WicfL3O0eTiPO9sfng/1ofswMKFZrwemYWw611XGyoQSdLud5Pqwn4h1t/MLwnmLHuyWhe4NGzK9V1O/+vZc+PiGCgDage6teumULuTn2F4hgfCTQXmOXMD5ehA0A9/Ix4bSpt18azB1xdFgpLPh6oc7sThgKur5oHWZsUnYAvqJyZj7CW+7DkaY6caObT3RQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CAcXq97W96ZpWLUBiC2hqzgV7x3qfNyzgHaAo3kEJqE=; b=hxZa8HEySUyU3pkvGvjydgahKbQJ6RvujFRZnbhCIJE8otA3XTdQEEEjnQiZ6QHnbFDd6/uWbfwBwqsVlS2QQ1qJ1Dk8C9eHEs/1JHpYKBkom6ETXZ1z3TFmJAp0CIOhUyr+QQutWPmqmUpeiWr3yChxpFbMwe9i7nAS6wzOLK99e6K4obn9ysMpXbl2uYCYvXC/kuv6shvZibCPTT0kuNKCtncHcrBIZmBZM7wOsYJBn7ZJdo/8nELyrjjVLUzR7Gq9uC+SOFxzmD95ZuzRlFvFCYLvlJChnoBNkIDr9UBhmSAkLTS1hVjEVNLCibTqVbIYBHh/zjiWQBVVanXriA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=helsinki.fi; dmarc=pass action=none header.from=helsinki.fi; dkim=pass header.d=helsinki.fi; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-HelsinkiFI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CAcXq97W96ZpWLUBiC2hqzgV7x3qfNyzgHaAo3kEJqE=; b=RGAQqMXR9PTSIJFknCDtV0iPl1e5ao0dv5kTzQ7prW0y58ZrXYW96at5XEyPwmYzutiTY2cjy5pgqCPcD+U3Yjdkwo9mftegkeSVz5mEeGv80lndRhhFd/uTUskxVlCQVd9+IM2U3iTWx+dXBjj++hApcz56hq02NrxsfYAvLak=
Received: from (2603:10a6:7:2e::17) by HE1PR0702MB3657.eurprd07.prod.outlook.com (2603:10a6:7:7e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.10; Wed, 20 Jan 2021 06:14:27 +0000
Received: from HE1PR07MB3196.eurprd07.prod.outlook.com ([fe80::e41b:bf6a:bada:8a3a]) by HE1PR07MB3196.eurprd07.prod.outlook.com ([fe80::e41b:bf6a:bada:8a3a%5]) with mapi id 15.20.3784.010; Wed, 20 Jan 2021 06:14:27 +0000
From: "Hakala, Juha E" <juha.hakala@helsinki.fi>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Paul Jessop <paul@countyanalytics.com>, "Dale R. Worley" <worley@ariadne.com>
CC: "llannom@cnri.reston.va.us" <llannom@cnri.reston.va.us>, "urn@ietf.org" <urn@ietf.org>, "john@jck.com" <john@jck.com>, "jonathanmtclark@gmail.com" <jonathanmtclark@gmail.com>
Thread-Topic: [urn] URN:DOI namespace registration request
Thread-Index: AQHW7b0SNOtlsy6in0ieB6QJrpE0jaotqEEAgABcQgCAAfdLUA==
Date: Wed, 20 Jan 2021 06:14:27 +0000
Message-ID: <HE1PR07MB319672725FE63DEBA5AA0B64FAA20@HE1PR07MB3196.eurprd07.prod.outlook.com>
References: <HE1PR07MB3196DBADE6019EF3794C90ADFA310@HE1PR07MB3196.eurprd07.prod.outlook.com> <87ft2ygofe.fsf@hobgoblin.ariadne.com> <A4354843-F680-44A6-AE49-11FFA28C3462@countyanalytics.com> <eee21c2c-94a9-5aaf-a20d-4528b383c6e5@it.aoyama.ac.jp>
In-Reply-To: <eee21c2c-94a9-5aaf-a20d-4528b383c6e5@it.aoyama.ac.jp>
Accept-Language: en-GB, en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: it.aoyama.ac.jp; dkim=none (message not signed) header.d=none;it.aoyama.ac.jp; dmarc=none action=none header.from=helsinki.fi;
x-originating-ip: [86.115.25.71]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 66b705d4-eda0-4812-1147-08d8bd0aa46f
x-ms-traffictypediagnostic: HE1PR0702MB3657:
x-microsoft-antispam-prvs: <HE1PR0702MB365753736441891CF4E77878FAA20@HE1PR0702MB3657.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LjQbI1s9wHsfZNMw8SD44rqrY17eNf8CCQ2mKUVJqQDZCFPTDLIqX03lhtC0YrDjh7Qch0AWi2Xs2k3pLt0/10B3CyC/GsIaBVt1ezII5DtIBBmXrPZQtV9VG1T1GUU4MzyrQWRKlVruo0bVVbmt/S+N1mGvt8XJqaQ0PU0Ex77YvSpBQZ9cf9ukex/MdPPV2+5nN9lG+sqzPisp1fE5Hra59ZgY9aCDdt1DhSxBRrqhAF2PxUGEjUQok4Ajpe1Jv/kWcSMA45s704JcWKEepU/jDXsvlZe8G9Coo5t2lyTlYVYYbr/PmOgiWktMcDFucyDSyuBMnDQtvP5UiphuPdPC+vj6UJ7TRdHWw3NgjsJ0DBFScy1NzE08YhPOqPUFoq9jw4jFwzTIZej/5sreD+OLOmqHjr2YpVcA8pLEc+ttm0d2Aj8k7cNPSYXgH/Vhn9p/IAW+h92KnCGa/qxOMw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3196.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(39850400004)(346002)(136003)(396003)(2906002)(7696005)(71200400001)(53546011)(966005)(478600001)(110136005)(316002)(786003)(33656002)(6506007)(4326008)(54906003)(26005)(66476007)(76116006)(8936002)(55016002)(64756008)(9686003)(66446008)(66574015)(66946007)(5660300002)(186003)(83380400001)(8676002)(86362001)(52536014)(66556008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 00aD25R8StU0FBhcQSrOznu5qcIBDrKmbb58gE13Pf8JJaUB7oH4Vh4UZ6DgVYkInGOkG7oY7sLOS+YMZwuEhUKkNIlWi6A+dKjedd2OgS9UH/Ruw8RLN165qJ290ynB/uRTlFvyBxmYah+wwWw0/BiHBP/VCa/MMtnrPlfsLpKi5wJs92uBPqlvMIt8i17jl/hUkHfEtwTtMGfbYoiCwfjxI4JYgwrn4TSV3hXshUvsoCyj63j0T0Vg7WMnj0eULiZBkAoQXcWv9uhH/e3TmGyUy1hJqKrdBhBcXEfK8WEI/xc3IssFpQiL1qbx3djighxO22uquj4t1Vplf4it5n2e33lpwSE81G0tA8rXEtpBBIHLtc0A6beqWU5kJhzW3KRXpLlcRCAJgCqSq7fRqszvYzuR52DVJ/D1lx2A88hiNe/67f25aGlUzwZj5MKa0lsQ3fyWOfONNeMqTHRUuaSJzW3bhIz933iKFEFBxhGNW+62XPp2gOX8Un0xwIJJTJzki5v0+7Yk+geTe0wKKc/dktSt25oBYo9RkVNobfiBd2jq5X84H1CXcUfjotwNI2s84/etbhPgOWIBZbEt+oYDUl+K/aJU/36nt0MO3QUFPrwYBMGW5oayNyg8H1uubLoet/DoqX47OQjfORJ6ScVYDNpxKixtbQpbht5QlYlImgUAmrmEY5qv0jwcYOodpD4R7gHHC7DjCYoqwjQURkBbeKtRqaJJWIKTUgtUMdKPjSxQjndx8Ssfm2iEGszPn45n5qnnrlv/8r5/IqjO5mWjNyqfLZs8x+jy7cYL7StJ2zHwmNuzJyMNPsCbbDqBOJJb1Vb9ABZT2bcgvmG24STdDZgeWxfcd/oQVOasXjAAhnsV7kBJ+/msckP56JDQ9pTkAx/X5ZM5rToFD3kV3jUh5b0lEk2lJsJZLoyjVHLQy/uFnsByIBDrUhWg8vvEXWwh8aH0dms4Us5rki4u02Mjglzjy0BOEVmmLiWuC48=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: helsinki.fi
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3196.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 66b705d4-eda0-4812-1147-08d8bd0aa46f
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2021 06:14:27.7690 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KGr5+6FGOSdWTTnRSwdj3RCITiMPqHxq/ZqzuBQYmT0nvECO4Kc6HAwjIJ6ufL1XarR3cQMyxCBZ2eCLkjjNkA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3657
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/1Q45WUJFqZYr8w_K2B3Hk0icZ1k>
Subject: Re: [urn] URN:DOI namespace registration request
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 20 Jan 2021 06:14:36 -0000

Hello, 

DOI standard (ISO 26324:2012) says that: 

"When displayed on screen or in print, a DOI name shall be preceded by a lowercase “doi:” unless the context clearly indicates that a DOI name is implied. The "doi:” label is not part of the DOI name value.

When displayed in web browsers, the DOI name can be attached to the address for an appropriate proxy server, to enable resolution of the DOI name via a standard web hyperlink. To resolve a DOI via a standard web hyperlink, the DOI name itself should be appended to the address for the proxy server.

EXAMPLE
The DOI name 10.1006/jmbi.1998.2354 would be made an actionable link as http://dx.doi.org/10.1006/jmbi.1998.2354.

NOTE: Certain client or server software might be able to process DOIs using native resolution technology (i.e. doi:10.1006/jmbi.1998.2354 would be interpreted by the browser and automatically resolved without the addition of the proxy server address)."

-----------------------

Martin's examples below (from IETF RFCs and ACM Digital Library) are not compliant with ISO 26324, and therefore IMO not that relevant in the context of registering a URN namespace for DOI. It will be easy to find additional non-standard ways of presenting DOIs in the wild, but adding even more incorrect examples of DOI usage out there would just make it more difficult to make any sensible recommendations on how to proceed.   

Since ISO 26324 was published 9 years ago, it has become clear that there is no widespread client software to support resolution of DOIs presented with doi: prefix. Therefore the current recommendation of the DOI handbook and the DOI user community is to express DOIs as HTTP URIs with the (new) resolver proxy address. For instance: 

https://doi.org/10.1006/jmbi.1998.2354  

or 

https://doi.org/10.17487/RFC3986

As an aside, DOI-based HTTP URIs should be used as links to RFCs instead of their URLs. If DOI is expressed as a hyperlink there is no need to provide also a URL. Moreover, each RFC has more than one URL but just one DOI. 

HTTP URI -based DOI presentation will replace the old doi: presentation in next editions of ISO 26324 and ISO 690 (ISO standard for bibliographic citations; new edition to be published 2021). DOI community may also use URN syntax, since every DOI can already be presented also as a URN. URNs https://doi.org/urn:doi:10.1006/jmbi.1998.2354 and https://doi.org/urn:doi:10.17487/RFC3986 are actional and resolve just like the DOIs above.  

Presenting DOI as URN does bring some technical benefits. ISO 26324 does not allow usage of URI fragment or query. But if DOIs are presented as URNs (and only then), it is possible to add F-, Q- and R-components to DOI namespace specific strings (pending support for URN Q- and R-components in Handle.Net resolver, used by both DOI and Handle systems). 

Best regards, 

Juha

-----Alkuperäinen viesti-----
Lähettäjä: Martin J. Dürst <duerst@it.aoyama.ac.jp> 
Lähetetty: tiistai 19. tammikuuta 2021 1.17
Vastaanottaja: Paul Jessop <paul@countyanalytics.com>; Dale R. Worley <worley@ariadne.com>; Hakala, Juha E <juha.hakala@helsinki.fi>
Kopio: llannom@cnri.reston.va.us; urn@ietf.org; john@jck.com; jonathanmtclark@gmail.com
Aihe: Re: [urn] URN:DOI namespace registration request

Hello Paul, Dale, others,

On 19/01/2021 02:46, Paul Jessop wrote:
> Hi Dale,
> 
> It is frustrating that someone else's provisional URI registration continues to create confusion. This registration was made without the knowledge of the DOI Foundation and our first reaction was that it was a form of "identifier piracy" - leading to an initial robust request to cease their actions. It seems from what I can see that the players behind it are acting in good faith but with ambitious (over-ambitious?) expectations that they will achieve in-browser resolution of a large range of URI schemes.

The provisional registration was done because identifiers of the form doi:... were found in the wild and in order to avoid these three letters from being used for something else (as mentioned below).

What I think is important is to do some research on how DOIs are currently used in the wild. In a very quick search, I found the following two at least:
   IETF RFCs: DOI 10.17487/RFC3986
   ACM Digital Library: DOI:https://doi.org/10.1145/2594291.2594299

I'm very sure I have seen DOIs in URI form (i.e. doi:...), too.

> I haven’t pressed them to withdraw their registration because the status quo (where they at least had the courtesy put our name on the registration) serves to prevent someone with less scruples from "grabbing" the scheme name and causing even more confusion.

The provisional registration should definitely not be withdrawn. If/when there is a better alternative *that works widely*, then it may be a good idea to update the registration with a pointer to that alternative.


> To be clear, the intent of The DOI Foundation is to address the technical issues that have been raised here (which are confident we can do) and continue the URN namespace request. We do not intend to turn the URI reservation into an application. If necessary we can be "robust" again with the parties who made the reservation but I didn’t see a clean way to turn it into "please regard the URI scheme name 'doi' as exceptionally reserved (to use a country code term) although there is no intent to register it as a scheme for ISO 26324 DOIs". If there are experts here who can advise on language for that, we would be very glad to receive guidance.
> 
> The preference in our strategy for securing the URN namespace registration comes from some of our user communities who are extremely comfortable with URN - because of experience with NBN and EIDR URN codes.

I think such experience is valuable, but you should also consider wider experience and what's out there in the wild in terms of identifiers already.

> I hope that addresses your concerns - and trust you can have another look at this. If there is any other information or background I can provide, please let me know.

I definitely think that it is a bad idea to reject an URN namespace request just because there is a provisional registration for an URI. 
It's not clear which one of these approaches will work better technically. And 'technically' here actually means in terms of deployment, because the are no fundamental technical issues. It would be a bad idea for the IETF and the registries to try and make a decision to favor one or the other, in particular if such a decision is based on a provisional registration done by a third party out of good faith just to avoid potential collisions.

Regards,   Martin.


> With best regards,
> 
> Paul Jessop
> Technology Adviser, The DOI Foundation
> 
> 
> 
> Paul Jessop              county analytics ltd
> ---------------------------------------------
> rights - technology - markets - music - media
> ---------------------------------------------
> paul@countyanalytics.com      +44 7850 685378
>   
>   
>   
> 
> On 18/01/2021, 17:12, "Dale R. Worley" <worley@ariadne.com> wrote:
> 
>      My apologies for not attending to this sooner.
> 
>      I'm afraid I object to this registration as a matter of principle,
>      rather than a matter of details.  The inclusion of the DOI space as part
>      of the URI space should be done through the implementation of the doi
>      URI scheme -- as has already been proposed -- and the details of that
>      should be fixed by the DOI Handbook.
> 
>      Looking at the benefits listed in the proposed registration, they are as
>      easily obtained by use of doi URIs as they are by doi URNs.
> 
>      Given the provisional registration of the doi scheme, it appears that
>      the DOI Foundation intends to establish the details of the scheme.  It
>      would be unwise for us to establish an entirely parallel defintion as a
>      namespace, where for sanity's sake, the two definitions would have to be
>      maintained in exact alignment.
> 
>      Dale
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
> 

--
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan