IETF Logo Mail Archive

Re: [urn] new draft 9 - RE: new urn PWID draft (7) with corrections

Eld Zierau <elzi@kb.dk> Thu, 31 October 2019 13:29 UTC

Return-Path: <elzi@kb.dk>
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 000DF120164 for <urn@ietfa.amsl.com>; Thu, 31 Oct 2019 06:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 KatdZb0POSzF for <urn@ietfa.amsl.com>; Thu, 31 Oct 2019 06:29:27 -0700 (PDT)
Received: from smtp-out12.electric.net (smtp-out12.electric.net [89.104.206.44]) (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 9EB6012012D for <urn@ietf.org>; Thu, 31 Oct 2019 06:29:27 -0700 (PDT)
Received: from 1iQAVv-00032l-VX by out12b.electric.net with emc1-ok (Exim 4.92.3) (envelope-from <elzi@kb.dk>) id 1iQAVw-00034Z-TK; Thu, 31 Oct 2019 06:29:24 -0700
Received: by emcmailer; Thu, 31 Oct 2019 06:29:24 -0700
Received: from [92.43.124.147] (helo=deliveryscan.hostedsepo.dk) by out12b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <elzi@kb.dk>) id 1iQAVv-00032l-VX; Thu, 31 Oct 2019 06:29:23 -0700
Received: from localhost (unknown [10.72.17.201]) by deliveryscan.hostedsepo.dk (Postfix) with ESMTP id 9BC5E1168; Thu, 31 Oct 2019 14:29:23 +0100 (CET)
Received: from 10.72.17.201 ([10.72.17.201]) by dispatch-outgoing.hostedsepo.dk (JAMES SMTP Server 2.3.2-1) with SMTP ID 154; Thu, 31 Oct 2019 14:29:23 +0100 (CET)
Received: from out12b.electric.net (smtp-out12.electric.net [89.104.206.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "electric.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by pf1.outpostscan-mta.hostedsepo.dk (Postfix) with ESMTPS id 657E29F246; Thu, 31 Oct 2019 14:29:23 +0100 (CET)
Received: from 1iQAVv-0002zC-T4 by out12b.electric.net with hostsite:2468467 (Exim 4.92.3) (envelope-from <elzi@kb.dk>) id 1iQAVv-000318-U4; Thu, 31 Oct 2019 06:29:23 -0700
Received: by emcmailer; Thu, 31 Oct 2019 06:29:23 -0700
Received: from [92.43.124.46] (helo=pf1.outprescan-mta.hostedsepo.dk) by out12b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <elzi@kb.dk>) id 1iQAVv-0002zC-T4; Thu, 31 Oct 2019 06:29:23 -0700
Received: from post.kb.dk (post-03.kb.dk [130.226.226.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by pf1.outprescan-mta.hostedsepo.dk (Postfix) with ESMTPS id D25B19F4BD; Thu, 31 Oct 2019 14:29:22 +0100 (CET)
Received: from EXCH-02.kb.dk (exch-02.kb.dk [10.5.0.112]) by post.kb.dk (Postfix) with ESMTPS id 7D59E95A36; Thu, 31 Oct 2019 14:29:22 +0100 (CET)
Received: from EXCH-02.kb.dk (10.5.0.112) by EXCH-02.kb.dk (10.5.0.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Thu, 31 Oct 2019 14:29:22 +0100
Received: from EXCH-02.kb.dk ([fe80::b595:1a1f:5666:b29]) by EXCH-02.kb.dk ([fe80::b595:1a1f:5666:b29%7]) with mapi id 15.01.1847.003; Thu, 31 Oct 2019 14:29:22 +0100
From: Eld Zierau <elzi@kb.dk>
To: 'S Moonesamy' <sm+ietf@elandsys.com>, "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] new draft 9 - RE: new urn PWID draft (7) with corrections
Thread-Index: AQHVZLLw4Q5OQaUs2kOof2VHSNgO56d1FGRA
Date: Thu, 31 Oct 2019 13:29:22 +0000
Message-ID: <987081dd682145a3a5791d012886024d@kb.dk>
References: <5dc7b935b3664b618108067a187ec855@kb.dk> <6.2.5.6.2.20190906054230.1366a8b8@elandnews.com>
In-Reply-To: <6.2.5.6.2.20190906054230.1366a8b8@elandnews.com>
Accept-Language: da-DK, en-US
Content-Language: da-DK
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.226.229.95]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-IP: 92.43.124.46
X-Env-From: elzi@kb.dk
X-Proto: esmtps
X-Revdns: outprescan-mta.hostedsepo.dk
X-HELO: pf1.outprescan-mta.hostedsepo.dk
X-TLS: TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
X-Authenticated_ID:
X-PolicySMART: 10573177, 19718497
X-Virus-Status: Scanned by VirusSMART (b)
X-Virus-Status: Scanned by VirusSMART (c)
X-Outbound-IP: 92.43.124.147
X-Env-From: elzi@kb.dk
X-Proto: esmtps
X-Revdns: deliveryscan.hostedsepo.dk
X-HELO: deliveryscan.hostedsepo.dk
X-TLS: TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
X-Authenticated_ID:
X-Virus-Status: Scanned by VirusSMART (b)
X-Virus-Status: Scanned by VirusSMART (c)
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/0zuVupQoxhld6k9T9Vk3PdTvs3s>
Subject: Re: [urn] new draft 9 - RE: new urn PWID draft (7) with corrections
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: Thu, 31 Oct 2019 13:29:31 -0000

Dear S. Moonesamy

Please see my comments below

Best regards, Eld
-----
Eld Zierau
Digital Preservation Specialist PhD
The Royal Danish Library
Digital Cultural Heritage
P.O. Box 2149, 1016 Copenhagen K
Ph. +45 9132 4690 
Email: elzi@kb.dk

>Dear Eld,
>At 12:43 AM 06-09-2019, Eld Zierau wrote:
>>Let me stress that I really think it is important that this is a 
>>standard obtained within IETF as it is very much related to the 
>>internet. The PWID can cover a very
>
>There was a request for a URN registration in December 2017.  That is not the same as a standard >obtained within the IETF.

Eld: Sorry if I did not express myself clear, - I know it is not the same, - my point is more that a standard is best placed under IETF rather than being an ISO standard or some organization that are not attached to a standard organization.

>
>One of the comments from Mr Thompson was about the following: "The PWID URNs do not have to be >assigned by an authority, as they are based on the information created at the time of archiving".  There is >usually an entity managing a namespace on behalf of its community.  It is not clear who will ensure >uniqueness of identifiers if there isn't any authority to makes the decisions.

Eld: The uniqueness is ensured by the required archiving information: the archive, the archiving time (with as much granularity as possible) and the archived URL. Since no archive will archive the same harvested URL at exactly the same time, this information will uniquely identify the resource. Another way to see it is that archives are responsible for preserving the fundamental archiving metadata with the data: the time of archiving and what is archived. No archive would omit any of these informations, and if they did, it would be one of the cases where you cannot use PWIDs for the data.  You could say that the archive is issuing PWIDs when they archive a URL.  

>
>Regards,
>S. Moonesamy


-----Original Message-----
From: S Moonesamy <sm+ietf@elandsys.com> 
Sent: Friday, September 6, 2019 2:58 PM
To: Eld Zierau <elzi@kb.dk>; urn@ietf.org
Subject: Re: [urn] new draft 9 - RE: new urn PWID draft (7) with corrections

Dear Eld,
At 12:43 AM 06-09-2019, Eld Zierau wrote:
>Let me stress that I really think it is important that this is a 
>standard obtained within IETF as it is very much related to the 
>internet. The PWID can cover a very

There was a request for a URN registration in December 2017.  That is not the same as a standard obtained within the IETF.

One of the comments from Mr Thompson was about the following: "The PWID URNs do not have to be assigned by an authority, as they are based on the information created at the time of archiving".  There is usually an entity managing a namespace on behalf of its community.  It is not clear who will ensure uniqueness of identifiers if there isn't any authority to makes the decisions.

Regards,
S. Moonesamy

v2.23.0 | Report a Bug | By Email