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

Peter Saint-Andre <stpeter@stpeter.im> Mon, 08 July 2019 23:58 UTC

Return-Path: <stpeter@stpeter.im>
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 09AB61203AD for <urn@ietfa.amsl.com>; Mon, 8 Jul 2019 16:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=r0yX/iVQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EdxK1DQa
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 OPf-MQ4A--js for <urn@ietfa.amsl.com>; Mon, 8 Jul 2019 16:58:19 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A251203FD for <urn@ietf.org>; Mon, 8 Jul 2019 16:58:19 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2B06322076; Mon, 8 Jul 2019 19:58:18 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 08 Jul 2019 19:58:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=I j0UGNL4w/UfSCPDzEXa8P15K0R1pdy+xQZcRKB1RYw=; b=r0yX/iVQXPei1nA4/ /p2ZTcIeK88EQ7KDSuVH/m2NFFTvcWrvurxKkLeKCEOop2akasJot2Ow4snKcnmO yKEIB/nszOHxUylGvsK+vjXjXze+5w832LCIlC49icQ3kJ26rftkwOUqSDV7iPwY 5MJqw9qh8cF8VrJbbl6u6SkwqtwLPaOqG2L/V64MECkhPZqndS5Ebc3H6Ka4xYbY sj3wZAT1WuVLAV4Ecndth3Zd6ZgBjUKOQX6UNCz7vX4m05xiL5CpaRK5HhbiU5fR edHZlwXNW1DXRyi3b6g7EkNn56+XHn6f4v16c1fNEydHOnhL9D1ghWNi3W/Qswfx sG04g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Ij0UGNL4w/UfSCPDzEXa8P15K0R1pdy+xQZcRKB1R Yw=; b=EdxK1DQao3pqAjfxsBb/wLDIxYRZT67QGa7JwXnF+bb8cRgLRStFgyk9o KpBGrOl/W9TaHTsJwVwpgac9cWqZLkpz3CG/rUZTlrXqLdZQXJ60aQKa5wmQrcvu 2R31ATIyCOegkAtlmaoAEydpMDvxJYyyPmW9JMbrHPqCtJbIXx9lX9IndCMsnC0g IETzr8NGyfoNUl32Uv5slCubjOrf8FsZZJm8P31QdP0jsU0+XMEGjL1YDttspkBK eSTkVmNNyd+RVdl4pD6rIYkN7mkCKa7ZCTVMKqtvvIO8OmyATCM0QCOfD5C3y5sg 8RuwJADLaY4uz099YkDazJC8ML+Wg==
X-ME-Sender: <xms:mdgjXWI4kIqJ82pXs3auJ5R04lsD4AjdQTxgvOL3KpU6uUMm4lfOkA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgedugddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefrvghtvghr ucfurghinhhtqdetnhgurhgvuceoshhtphgvthgvrhesshhtphgvthgvrhdrihhmqeenuc ffohhmrghinhepihgvthhfrdhorhhgpdhirghnrgdrohhrghenucfkphepjeeirddvhedr fedrudehvdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshhtphgvth gvrhdrihhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:mdgjXejBdlKEXdJkpO4p5V5SSFcSMxr4tkCAiyII5vGU00YQOZy8lw> <xmx:mdgjXX0NYT9kaDQilixFlId7I_j107OByE3Fb5dWkmQykw8Nz2PIPA> <xmx:mdgjXXa9fqEM5p-s1gTTeprW_JzzFXIXym5KOd0ivaQ9wyCCEF3B7w> <xmx:mtgjXZuxm6z1ldREc9fPGPZExgzq8V2nZBJdPT0iY34y0LRRM-O_2Q>
Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 2B28480062; Mon, 8 Jul 2019 19:58:17 -0400 (EDT)
To: Eld Zierau <elzi@kb.dk>, "urn@ietf.org" <urn@ietf.org>
References: <8b275ab6aa8d48359113497209261c63@kb.dk>
From: Peter Saint-Andre <stpeter@stpeter.im>
Openpgp: preference=signencrypt
Autocrypt: addr=stpeter@stpeter.im; prefer-encrypt=mutual; keydata= mQINBFETDzsBEAC0FOv1N3ZJzIIxN6cKD475KVS9CHDPeYpegcOIPnL5eY1DCHeh/IwS1S7R CePtmiybNoV9FsI4PKUknzXQxA6LVEdAR/LUlhgJKjq+gsgp8lqbEILhg13ecH66HwLS9rar bQkC47T7kL8miIPBFC6E3A4Lq1L+eueO6UcLhKgoYkMxOjdiWrMgKTnVpch5ydLkPm/z0Zo8 zRgqlPuTLeCrXXZYnjHXLVFN2xy04UzOs7P5u5KVfx5Z7uQisr8pXtyLd6SpTZo6SHgKBv15 uz0rqXhsJojiGtOXfWznAjaS5FUOORq9CklG5cMOUAT8TNftv0ktsxaWDL1ELDVQPy1m7mtz o+VREG+0xmU6AjMo/GHblW1UU7MI9yCiuMLsp/HLrFuiosqLVZ85wuLQ2junPe3tK8h15Ucx IXAcpQ1VqIaDQFbeuLOXJTF8YHpHdpHYt/ZM1ll7ZBKGAo8yd7uF7wJ9D3gUazwdz9fFjWV7 oIk7ATwOlFllzmWDn+M2ygbHOGUGMX5hSaa8eDSieiR2QoLdn27Fip7kMBTJ2+GISrfnJTN/ OQvmj0DXXAdxHmu2C4QgmZbkge35n129yzXn9NcqzrGLroV62lL3LgX6cSbiH5i7GgWY6CAP b1pMogV0K475n9FvOSDRiG4QSO5yqKiA3OP5aKrIRp2TNAk4IwARAQABtCZQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBzdHBldGVyLmltPokCOQQTAQIAIwUCURMPOwIbAwcLCQgHAwIB BhUIAgkKCwQWAgMBAh4BAheAAAoJEOoGpJErxa2p6bgQAKpxu07cMDOLc4+EG8H19NWXIVVy bOEvfGuHYZaLKkPrhrMZwJiOwBpyISNRt9qzX1eLCVaojaoEVX6kD8MGc5zKFfiJZy3j7lBW l+Ybr7FfXYy2BbAXKx49e1n6ci9LmBrmVfAEaxtDNPITZ9N9oUAb9vS0nrG036EwteEHAveQ vlDjO7lhz6+Cv7lZQgBj9rZ6khfcQ4S3nSCQaKLQ9Iav4fqxI7SfuPKnx6quHX3JNLGnVo3w l+j/foCK0iTrmtHxCI3kc/bx6g32pRjHEPX0ALMBhmzU2uca+TE0zCEC96mgYXAUCwdnCFWy beIEbt6pz65iML13kAVAq0H/GqncnMGN0MbOatnw1Tdz/vkLojIy7QbPcQ0plUFxv5491xPf IrHhOWdRXp6WUt88fcqhT6MHZpVRtusj2ornKVVn+Y0GLsMMCTcrXJRG7Ao1YV72t/pJpzfG WSaaxolxDIZ6B+76jrIhUhiWgo/4nf+DN6BIlCZQ6j6xxjjx462cu02kuhIILTk2pzaMOufT BWx0uJhZk/KP2Fay/41pX7pvVOwRC4uIlKsLnJKLPS7EDa4BUUxENfd/9LqOGwlII8BbSe98 PLMI8sXkcigc3UXMVda9ll0YhQa+lbP1NaszmnBhwuiCsgnPGbImsJuRzgEEgckwP/dNeyr6 MlFMyfaeuQINBFETDzsBEADBzOsEHpUmhkRUjH9Tek87dn5P/Yh/L/HptgCGk40TL/C+kYdk d3HyteMEf061PNmsS/Rq8k37Fu3VODYb9SPYKxtgksKSYUtIkPKvao09K9QNWPqyWuNf0F+i AjVMUudaEVFJ7bHF310RDwLY5IvLeCXxtvG+Vv/i+g77d2WdPDp+zLJ8306C4yBKjSJV8xW0 cn2fd7NviIEN6cNHTsZNDZVMlgYPrxnwSq8GTEPGC7HsLIwGcx3hIe9QjnPw9CpAmQENpDEy WcxgF5uwo2NJECoDswKz1Nb0gfawF3ZIbD+GcLujTu94iJuVg25jATWm9wTgcfZo4UPllRGX dIb8uWwUFQlLQgd4ROLZZtXNGmHIymJrV2crx53gxup+1j0XqhlzKg8xbImWhEfS9oHZkRK8 VHgmWSIt7TNwNir6N5j3lqwWVBhnu6GzF01sKGNySlqNRbd0fqhakCkK71b8ot8tYTcYG5Lg 10z6HTbgQx2UwLthUjqbblDQ+GLmrOhiWklLXRsnlnPMwnEyFePAnsT5tasy2Cn9qjpttNDa h7PB8iFUi9mtTF/XDVgpFaB5G3CDV7Q2NgbAI6g6QhLIAmXzSP635G83mda0TKXHQXHDyLJT Tn+WVFU7t4m4uLt+0DsWU8jXHQWyUTNG9WPUrXhusDUAPHxFCQ/n/lQVBwARAQABiQIfBBgB AgAJBQJREw87AhsMAAoJEOoGpJErxa2pqfgP/ApN+TRu2bBIgaw1dr3AznSSha84DIpXUDh3 udZvQrGbUtz8/mA+e3iZEN/cmmBw2LGlAuQoJNILTZQ318yTP+E5QU7fJH7FVsohUyvrMfyt 3IMA9jg0Z9MuloLezvIjjMfFeNa0ROgDb/ubOT7JQzi1kwN8Lu3lO80HwqBHXEeOLoislUSn ZajRKvITbKWkZ6PHRjlMw1Wk4oIi6VLHgGgj79zzL3uhML2663m7imShvz1QcHTwvyR5i8cZ bNOEkotZyERiA1p7YHuruS+QvTi3ZPoQbnMUB3a7py9d11bw1+w3LiAUGZE/z5hBWOFxYtw+ w/U/Vx0BwJGYlwU3M2W20uEXe+qxz7wnakygKjmLiD2z4njfKjcNCiV3FmXrpmWgADln1c4j fxDh0NrndrsM8FPDf1TMPtOZgFDkKripc9xkZ/25P6xn27oTOHWKcAC0QhxSH+HuVBBRk8Ag F+zAbDZe4/L6+kanSrycIXW+wCzwBq61aWsz2QhhuKjozVkhk4dRG+CfjzAFjnyxwYERn3uX VKQAwTwcdNcTI9RV98IsNrw9Y4lJEAg6CjNPmiD5+EASycqaOuToRSGukr8sOQLWLPyTnez/ aG8Xf7a+fntWzK2HuDYoSDhJJrylWw/lMklOBm4wtMeNA0zcQH6AQV/GzQVQkSGqrLuMVIV/
Message-ID: <21edd4d6-36bf-9a35-d1c0-ff0d64c7a9db@stpeter.im>
Date: Mon, 8 Jul 2019 17:58:15 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <8b275ab6aa8d48359113497209261c63@kb.dk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/-_rR4HzGGu9zndzAk4cqvHdGUZY>
Subject: Re: [urn] 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: Mon, 08 Jul 2019 23:58:33 -0000

Dear Eld,

Thank you for your continued attention to this discussion.

As the team leader for the expert reviewers [1] I feel it is incumbent
on me to provide additional feedback.

I looked again at the list discussion about this namespace registration
request. In particular, several list participants raised some difficult
issues about the viability of the proposed namespace (see [2][3][4] for
example). Summarizing the discussion, it seems we still have open issues
around (at least) the following topics:

- the specification contains a great deal of ambiguity (e.g., in the
definition of precision-spec types)

- it appears that the proposed generation algorithm cannot guarantee the
uniqueness of the resulting URNs, which violates core requirements
defined in RFC 8141

- PWID URNs might be intended to define a method for citation, but the
proposed syntax does not capture all the information that would be
needed to produce stable citations

- PWID URNs lack a conception of authorized archives, which means that a
third party could create archive-ids associated with some other Internet
domain or administrative domain over which it has no control or authority

- several aspects of the proposed semantics depend on knowing the media
type of the archived resource, but this information is not necessarily
available to a person or application that constructs or interprets a
PWID URN

- in order for PWID URNs to be usable, they might need to support f-,
r-, and q-components from RFC 8141, but this usage has not yet been
defined in the specification

All in all, there are many open issues with the proposed namespace and
it seems premature to approve the registration before these issues are
resolved. Unfortunately, some of these issues run so deep that it's
unclear whether they *can* be resolved without performing major surgery
on the specification.

I wish I could be more positive in my recommendation, but at this time I
am not in favor of registering this formal namespace.

Best Regards,

Peter

[1] https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

[2] https://mailarchive.ietf.org/arch/msg/urn/qZ4qcHHmPJyKEg-YaIHmr_ksG3I

[3] https://mailarchive.ietf.org/arch/msg/urn/pypKM9SY2jSOiyZ5g6icQqFlzfs

[4] https://mailarchive.ietf.org/arch/msg/urn/Jzd9INZxhpNFiQH1ZxUhZ_0wkNY


On 6/4/19 2:11 AM, Eld Zierau wrote:
> I just submitted a version with a minor correction in one of the references (had the wrong title due to a copy/paste error)
> Can it be accepted as it is now?
> Best regards, Eld
> 
> -----Original Message-----
> From: Eld Zierau 
> Sent: Thursday, May 2, 2019 2:56 PM
> To: 'Peter Saint-Andre' <stpeter@stpeter.im>im>; urn@ietf.org
> Subject: new urn PWID draft (7) with corrections
> 
> Thanks again for your comments
> I have uploaded a draft version 7 - and described how I have addressed the comments in the below mail from Peter Does this cover what is needed?
> 
> Best regards, Eld
> 
> -----Original Message-----
> From: Peter Saint-Andre <stpeter@stpeter.im>
> Sent: Tuesday, April 30, 2019 5:14 AM
> To: Eld Zierau <elzi@kb.dk>
> Cc: urn@ietf.org
> Subject: Re: [urn] Comments on PWID -05 - now PWID -06
> 
> Hello Eld,
> 
> Your proposed syntax (with "~") looks fine to me.
>> Eld: :)
> 
> The ABNF definition of your proposed syntax does not conform to RFC 5234. You can check the ABNF using this tool:
> 
> https://tools.ietf.org/tools/bap/abnf.cgi
> 
>> Eld: it conforms now - thank you so much for providing this the link 
>> to the syntax checker - that was very helpful
> 
> In particular, it's not clear to me what a rule like this is intended to
> mean:
> 
>    registered-archive-id = +( unreserved )
> 
> Do you mean that a registered-archive-id can include one or more instances of characters from the `unreserved` rule? If so, change "+" to "*".
> 
>> Eld: I meant with one or more characters - but I found out it should 
>> then be 1*unreserved and likewise for other occurrences
> 
> 
> To simplify the ABNF, you could use the datetime rules from RFC 3339.
> 
>> Eld: I used to in an earlier version, but Dale noticed that there was a difference (in mail on 28th of February 2019): "But comparing that to W3CDTF, I see no single nontermainal which corresponds to the set of formats allowed in W3CDTF.  I suggest you make a more rigid specification as to what is allwed for archival-time." - so I think I better stick to the rigid version in order to be sure.
> 
> Please don't use `URI` as the name of an ABNF rule because that's already defined in RFC 3986 and could cause confusion. Perhaps call it `uri-string`.
> 
>> Eld: Done
> 
> Personally I found the `precision-spec` categories difficult to understand and sometimes ambiguous. For instance:
> 
> * A precision level of "part" seems to be an HTML file only (at least in the case when "it refers to an html web element"), however a URI can point to many file types other than HTML files. Perhaps "single" (as in a single file) would be clearer; it would also be good to specify how this is handled in the case of file types other than HTML.
> 
> * Does a precision level of "page" apply only to HTML pages with all "referenced web parts"? (By the latter term I think you mean what the HTML 5.2 specification defines as "embedded content"; in general it would be good to align terminology.)
> 
>> Eld: I have rephrased to make it more clear - it was explained in two 
>> steps before, - I have therefore also restructured a bit to make it 
>> more clear (page 11-13)
> 
> As to the registration, instead of version 6 it should be version 1 because this is the initial registration (i.e., whenever we are finished with this process it will be the initial version, whereas if you update the entire registration in the future that would be version 2).
> 
>> Eld: got it - I change it and left details to change log comment Eld? I 
>> have also change the version in the top of the template - since I guess that is the same thing - is that correct?
> 
> The security considerations strike me as underspecified. An archived web page or part could be just as dangerous as a "live" page or part; for instance, it could include insecure scripts, malware, trackers, etc.
> Furthermore, an archived page could in fact be more dangerous, because it could include outdated scripts with known vulnerabilities that can never be patched because the script is archived for all time in a vulnerable state (an attack of this sort was recently discovered in the wild).
> 
>> Eld: You are quite right, - I have taken the liberty to rephrase you 
>> comment and add it to the section, - hope that is ok
> 
> Best Regards,
> 
> Peter
> 
> On 4/29/19 6:10 AM, Eld Zierau wrote:
>> Did any of you have comments to my previous mail?
>> Is there any action you want me to take in order to get it accepted?
>> Best Regards, Eld
>>
>> -----Original Message-----
>> From: Eld Zierau
>> Sent: Friday, March 1, 2019 1:29 PM
>> To: 'Martin J. Dürst' <duerst@it.aoyama.ac.jp>jp>; 'Dale R. Worley' 
>> <worley@ariadne.com>
>> Cc: 'urn@ietf.org' <urn@ietf.org>rg>; 'L.Svensson@dnb.de' 
>> <L.Svensson@dnb.de>
>> Subject: [urn] Comments on PWID -05 - now PWID -06
>>
>> I have now uploade a new version: draft-pwid-urn-specification-06
>>  - and thanks again for comments and suggestions
>>
>> Regarding the suggestion from Martin (included below), I can as a computer scientist certainly see the reasoning as quite obvious. However, my experience with presentation of the PWID is that syntax based on computational reasoning is something that users find illogically, e.g. that the archived-item-id (usually URI) is included in the end of the PWID. I believe that adding a "~" for identifiers that are registered separately is acceptable for such users, but I am also convinced that a "+" before a domain will be something that confuses (non-computer science) users a lot. 
>> Also, as said in my previous mail, it is highly unlikely that there will ever be a case where "~" is the first character in a domain for a web archive. Therefore, it seems that it should not be necessary. 
>> A minor extra thing is that all existing PWIDs (and tools providing and resolving PWIDs) would not comply, which they would otherwise (none of these use registered identifiers yet only domains and URIs).
>> In other words: I will be very sorry to add a "+" to domains, and I believe it is not necessary.
>>
>> The uploaded version  does not include a "+" to domains, - If 
>> required, I will of course add it (although sorry to do so)
>>
>> Please let me know if it acceptable, and I will act accordingly.
>>
>> Best regards, Eld
>>
>>
>> On 2019/03/01 11:31, Dale R. Worley wrote:
>>> Martin J. Duerst <duerst@it.aoyama.ac.jp> writes:
>>>>> [...]  E.g., one could require that any archive-id that is not 
>>>>> intended to be interpreted as a DNS name to start with one of "-", 
>>>>> ".", "_", "~".
>>>>
>>>> I haven't looked into the details, but in general, I think this is a 
>>>> bad idea. It is much better to have an explicit distinction than to 
>>>> rely on some syntax restrictions. Such syntax restrictions may or 
>>>> may not actually hold in practice. It's very easy to create a DNS 
>>>> name starting with '-' or '_', for example, even though officially, that's not allowed.
>>>
>>> I may agree with you ... But what do you mean by "an explicit 
>>> distinction"?  E.g., I would tend to consider "archive-ids starting 
>>> with '~' are registered archive names, and archive-ids that do not 
>>> are considered DNS names" to be an "explicit" distinction, but you 
>>> mean something else.
>>
>> Well, the explicit distinction would be "if it starts with '~', what follows is a registered archive name, and if it starts with '+', what follows is a DNS name" or some such. This would not exclude any leading characters in either archive names or DNS names.
>>
>> Regards,   Martin.
>>
>>> Or maybe the right question is, What do you propose as an alternative?
>> _______________________________________________
>> urn mailing list
>> urn@ietf.org
>> https://www.ietf.org/mailman/listinfo/urn
>>
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>