Re: [urn] PWID URN namespace registration version 10

Eld Zierau <elzi@kb.dk> Tue, 26 May 2020 08:01 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 E689B3A0C9F for <urn@ietfa.amsl.com>; Tue, 26 May 2020 01:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 2dkgKkS43zqo for <urn@ietfa.amsl.com>; Tue, 26 May 2020 01:01:13 -0700 (PDT)
Received: from smtp-out12.electric.net (smtp-out12.electric.net [89.104.206.40]) (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 E93423A0CA0 for <urn@ietf.org>; Tue, 26 May 2020 01:01:12 -0700 (PDT)
Received: from 1jdUWL-0002GV-V3 by out12b.electric.net with emc1-ok (Exim 4.92.3) (envelope-from <elzi@kb.dk>) id 1jdUWM-0002LN-TO; Tue, 26 May 2020 01:01:10 -0700
Received: by emcmailer; Tue, 26 May 2020 01:01:10 -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 1jdUWL-0002GV-V3; Tue, 26 May 2020 01:01:09 -0700
Received: from localhost (unknown [10.72.17.201]) by deliveryscan.hostedsepo.dk (Postfix) with ESMTP id 792E39FE14; Tue, 26 May 2020 10:01:09 +0200 (CEST)
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 1001; Tue, 26 May 2020 10:01:05 +0200 (CEST)
Received: from out12c.electric.net (smtp-out12.electric.net [89.104.206.44]) (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 outgoing-postscan.hostedsepo.dk (Postfix) with ESMTPS id 2F26D169E; Tue, 26 May 2020 10:01:09 +0200 (CEST)
Received: from 1jdUWK-0007yz-Uo by out12c.electric.net with hostsite:2468467 (Exim 4.92.3) (envelope-from <elzi@kb.dk>) id 1jdUWL-00085v-TI; Tue, 26 May 2020 01:01:09 -0700
Received: by emcmailer; Tue, 26 May 2020 01:01:09 -0700
Received: from [92.43.124.46] (helo=pf1.outprescan-mta.hostedsepo.dk) by out12c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <elzi@kb.dk>) id 1jdUWK-0007yz-Uo; Tue, 26 May 2020 01:01:08 -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 3E4EB9FE0B; Tue, 26 May 2020 10:01:08 +0200 (CEST)
Received: from EXCH-01.kb.dk (exch-01.kb.dk [10.5.0.111]) by post.kb.dk (Postfix) with ESMTPS id DCA2594602; Tue, 26 May 2020 10:01:07 +0200 (CEST)
Received: from EXCH-02.kb.dk (10.5.0.112) by EXCH-01.kb.dk (10.5.0.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 26 May 2020 10:01:07 +0200
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.1979.003; Tue, 26 May 2020 10:01:07 +0200
From: Eld Zierau <elzi@kb.dk>
To: "Dale R. Worley" <worley@ariadne.com>, "urn@ietf.org" <urn@ietf.org>
Thread-Topic: PWID URN namespace registration version 10
Thread-Index: AQHWMXoWAEBvgM/Fn0+VQfRgNeMph6i6ANXA
Date: Tue, 26 May 2020 08:01:07 +0000
Message-ID: <8e3a1f00956349a2b2cd5a225e6f77ff@kb.dk>
References: <87tv06kokg.fsf@hobgoblin.ariadne.com>
In-Reply-To: <87tv06kokg.fsf@hobgoblin.ariadne.com>
Accept-Language: da-DK, en-US
Content-Language: da-DK
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [130.226.229.95]
Content-Type: multipart/mixed; boundary="_002_8e3a1f00956349a2b2cd5a225e6f77ffkbdk_"
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-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (b)
X-PolicySMART: 10573177, 19718497
X-PolicySMART: 10573177, 19718497
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 (c)
X-Virus-Status: Scanned by VirusSMART (b)
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/FHlchrhSr1g_4tEkEbMPKwoeIXQ>
Subject: Re: [urn] PWID URN namespace registration version 10
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: Tue, 26 May 2020 08:01:19 -0000

Thank you Dale

My comments is given below, and updated version is attached with following corrections: 
- added draft information in filename/header
- description of archive-domain
- syntax for utc-time 
- date of document
Best regards, Eld

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

My apologies for not giving this attention sooner.

I've read version 10, and I think we should approve it.  I have the following observations, which include one editorial suggestion.


I assume that the attachment to message
https://mailarchive.ietf.org/arch/msg/urn/x_JVtfKpANKZz6Qr8iOqpsXJ8SU/
"PWID URN (shortened title)" is draft verson 10, despite that neither the attachment's name or contents states that.
> Eld: At some stage, I was told that it is version 1, maybe I misunderstood, 
> but I thought the document date then indicated the version. 
> It was actually draft version 11. In the attached draft version 12, I have put in the information 
> about it being draft version 12


I particularly support the PWID proposal for the reasons I described in "PWID as citation"
https://mailarchive.ietf.org/arch/msg/urn/s-CM7hcWtUeAz7ZVBF94rCHMtsQ/
-- namely that what a PWID references is transparent enough that one could algorithmically transform a PWID pointing to one archive into a query into another archive.  This is a genuinely new capability for URNs (as far as I know) and only by deploying it in practice can we see what benefits might be obtained.
> Eld: Agree

I still dislike that there's no well-defined way to catalog allowed values of archive-dimain.  But the number of values that are used will likely remain small and there are unlikely to be "ownership conflicts"
about them, so this is unlikely to be a problem in practice.
> Eld: I agree, and I will certainly work on other fronts to make it possible to make more 
> precise reference, but this is what exists at the moment.

A minor editorial point:
      *  'archive-domain' is defined as in (section 3.5) [RFC1034].
"archive-domain" is not defined in RFC 1034.  You need to say
      * 'archive-dimain' is <subdomain> as defined in (section 3.5) [RFC1034].
(Oddly, you do want to use <subdomain> rather than <domain> defined in that section.)
> Eld: You are right - it is subdomain because <domain> ::= <subdomain> | " " and we want to avoid the " " possibility.
> I have corrected in the attached  draft version 12 


I see that if utc-time is part of archival-time, then it must contain both utc-hour and utc-minute, whereas utc-second and secfrac can be added independently.  This is a bit of an inconsistency, but I assume you intend it.
> Eld: That is actually an error, - I have corrected it, so it is possible just to specify the hour without minutes

Given that precision-spec is currently limited to one of two values, later extensions can be indicated by additional values defined for this field.
> Eld: Agree

Dale

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

-----Original Message-----
From: Dale R. Worley <worley@ariadne.com> 
Sent: Sunday, May 24, 2020 5:19 AM
To: Eld Zierau <elzi@kb.dk>dk>; urn@ietf.org
Subject: Re: PWID URN namespace registration version 10

My apologies for not giving this attention sooner.

I've read version 10, and I think we should approve it.  I have the following observations, which include one editorial suggestion.

I assume that the attachment to message
https://mailarchive.ietf.org/arch/msg/urn/x_JVtfKpANKZz6Qr8iOqpsXJ8SU/
"PWID URN (shortened title)" is draft verson 10, despite that neither the attachment's name or contents states that.

I particularly support the PWID proposal for the reasons I described in "PWID as citation"
https://mailarchive.ietf.org/arch/msg/urn/s-CM7hcWtUeAz7ZVBF94rCHMtsQ/
-- namely that what a PWID references is transparent enough that one could algorithmically transform a PWID pointing to one archive into a query into another archive.  This is a genuinely new capability for URNs (as far as I know) and only by deploying it in practice can we see what benefits might be obtained.

I still dislike that there's no well-defined way to catalog allowed values of archive-dimain.  But the number of values that are used will likely remain small and there are unlikely to be "ownership conflicts"
about them, so this is unlikely to be a problem in practice.

A minor editorial point:
      *  'archive-domain' is defined as in (section 3.5) [RFC1034].
"archive-domain" is not defined in RFC 1034.  You need to say
      * 'archive-dimain' is <subdomain> as defined in (section 3.5) [RFC1034].
(Oddly, you do want to use <subdomain> rather than <domain> defined in that section.)

I see that if utc-time is part of archival-time, then it must contain both utc-hour and utc-minute, whereas utc-second and secfrac can be added independently.  This is a bit of an inconsistency, but I assume you intend it.

Given that precision-spec is currently limited to one of two values, later extensions can be indicated by additional values defined for this field.

Dale