Re: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn PWID draft (7) with corrections)
"Henry S. Thompson" <ht@inf.ed.ac.uk> Wed, 04 December 2019 14:21 UTC
Return-Path: <ht@inf.ed.ac.uk>
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 25E7F120816 for <urn@ietfa.amsl.com>; Wed, 4 Dec 2019 06:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 Ct4HZvmT3ZSn for <urn@ietfa.amsl.com>; Wed, 4 Dec 2019 06:21:46 -0800 (PST)
Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) (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 5218B120813 for <urn@ietf.org>; Wed, 4 Dec 2019 06:21:45 -0800 (PST)
Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.202.41]) by loire.is.ed.ac.uk (8.14.7/8.14.7) with ESMTP id xB4ELYeC019387 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 4 Dec 2019 14:21:34 GMT
Received: from ecclerig.inf.ed.ac.uk (ecclerig.inf.ed.ac.uk [129.215.24.151]) by crunchie.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id xB4ELUjM027377; Wed, 4 Dec 2019 14:21:31 GMT
Received: from ecclerig.inf.ed.ac.uk (localhost [127.0.0.1]) by ecclerig.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id xB4ELVqM021791; Wed, 4 Dec 2019 14:21:31 GMT
Received: (from ht@localhost) by ecclerig.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id xB4ELRQp021787; Wed, 4 Dec 2019 14:21:27 GMT
X-Authentication-Warning: ecclerig.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: Eld Zierau <elzi@kb.dk>
Cc: "Hakala, Juha E" <juha.hakala@helsinki.fi>, Peter Saint-Andre <stpeter@stpeter.im>, urn@ietf.org
References: <2396dbcf66bb4c8689bcbabca2cc8492@kb.dk> <f5by2w3380y.fsf@ecclerig.inf.ed.ac.uk> <4499f99af7b84135ae88b14cc444d080@kb.dk>
From: "Henry S. Thompson" <ht@inf.ed.ac.uk>
Date: Wed, 04 Dec 2019 14:21:27 +0000
In-Reply-To: <4499f99af7b84135ae88b14cc444d080@kb.dk> (Eld Zierau's message of "Thu\, 28 Nov 2019 14\:50\:24 +0000")
Message-ID: <f5beexkrx20.fsf@ecclerig.inf.ed.ac.uk>
User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Edinburgh-Scanned: at loire.is.ed.ac.uk with MIMEDefang 2.84, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.84 on 129.215.16.10
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/vX6uyy5DOovNKBtRrnX93W1f4lE>
Subject: Re: [urn] new draft 10 - new form (RE: 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: Wed, 04 Dec 2019 14:21:50 -0000
Eld Zierau <elzi@kb.dk> writes: > Please see my comments below >> -----Original Message----- >> From: Henry S. Thompson <ht@inf.ed.ac.uk> >> The fourth constituent of a PWID, the *precision-spec*, now has only >> two possible values, 'part' and 'page', which appear to be attempting >> to distinguish between, respectively, >> >> 1) the representation that is/was retrievable for the archived-uri as >> at the archival-time; > Eld: I guess you mean 'part' here, which in the specification is > described as: > "* 'part' > ... Yes. > And I must admit that I do not see anything that can be interpreted > as representation in this description, so I cannot follow you point > here. The relevant RFCs (3986, 7231, 8141) all use "representation" for the actual result of a successful retrieval, that is, a message consisting of a media type and an encoded character sequence interpretable with respect to that media type. That's precisely what you are talking about in defining what you mean by 'part'. > Please also note that introduction say that > "The purpose of the PWID URN is also to express a web archive > reference as simple as possible and at the same time meet the > requirements for sustainability, usability and scope. Therefore, the > PWID URN is focused on having only the minimum required information > to make a precise identification of a resource in an arbitrary web > archive. Recent research have shown that this can be obtained by the > following information [ResawRef]: > > o Identification of web archive > > o Identification of source: > * Archived URI > * Archival timestamp > > o Intended precision (page, part/file)" > > I could of course make it sharper by saying that > * Archival timestamp (the archives timestamp for when the URI was archived) > But I must admit that I do not see it add value, and it is described several places throughout the specification > (and therefore not included in attached version). >> 2) a (Content-type conformant?) rendering of that representation >> (with all other digital objects implicated in that rendering >> ... > Eld: I guess you mean 'page' here, which in the specification is described as: > "* 'page' Yes. > ... > So it is up to browser software to tell whether it is something that > is interpreted as a page. > And yes a page is "with all other digital objects implicated in that > rendering (e.g. scripts, stylesheets, icons, graphics, fonts ...)", > where I have used terms that are less technical "parts (display > templates, images etc.)" Precisely. So it's a matter of rendering, or presentation, as implemented by a browser, or any application appropriate to interpreting the retrieved representation. But, and again according to the relevant specifications, what you _do_ with a representation of a resource is a matter for the recipient of that resource, which will be different for different users/uses at different times. The URI itself has nothing to say about that. So now I can express more succinctly what I was confused about: the *precision-spec* doesn't make sense, it's trying to pre-judge what someone may want to do with a URI. Insofar as one can state what a PWID identifies, it identifies the archival record maintained by the *archive-domain* for the representation retrieved at the *archival-time* of the state of the resource identified by the *archived-uri*. So, if we construct a PWID with *archive-domain* web.archive.org *archived-uri* https://link.springer.com/article/10.1007/JHEP12(2018)098 *archival-time* 2019-11-18T06:00:21 it identifies such an archival record at the Internet Archive, whose current representation can be retrieved via an HTTP GET request for https://web.archive.org/web/20191118060021/https://link.springer.com/article/10.1007/JHEP12(2018)098 If that GET request is performed using, say, the curl or wget command-line tools, you will get what you call the 'part' as a file on your local 'disk'. If that GET request is performed using, say, Chrome or Safari, you will see a presentation of what you call the 'page' on your screen. >> How does this distinction survive a change of media type? To >> image/png, or application/pdf, or audio/ogg? > Eld: The PWID is for referencing purposes, it is not concerned with > types. The PWID is a reference to something that has been harvested > from the internet and is supposed to be rendered by a browser, - so > this is a concern of the original publisher of the element and the > browser software. URIs are not just for browsers! Surely you don't want to restrict PWIDs to URIs "that are supposed to be rendered by browsers". All the talk in your drafts about browsers and "View Source" is at best misleading, and at worst suggests that PWIDs are only applicable to a very narrow view of what archives may contain. Consider PWIDs constructed from *archive-domain* web.archive.org *archived-uri* https://media.springernature.com/w306/springer-static/cover/journal/13130/2018/12.jpg *archival-time* 2019-11-18T05:35:49 and *archive-domain* web.archive.org *archived-uri* https://link.springer.com/content/pdf/10.1007%2FJHEP12%282018%29098.pdf *archival-time* 2019-11-18T06:00:05 which identify other archival records at the Internet Archive, whose current representations can be retrieved via an HTTP GET request for https://web.archive.org/web/20191118053549im_/https://media.springernature.com/w306/springer-static/cover/journal/13130/2018/12.jpg and https://web.archive.org/web/20191118060005/https://link.springer.com/content/pdf/10.1007%2FJHEP12%282018%29098.pdf Perfectly useful, but the 'page'/'part' distinction doesn't make any sense here, and 'View Source' is literally unusable. Your spec would be much shorter, simpler and easier to understand, and its potential utility much greater, if you removed the *precision-spec* altogether, and made more use of the descriptive terminology and its underlying semantics as found in the relevant RFCs mentioned above. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
- [urn] new draft 10 - new form (RE: new draft 9 - … Eld Zierau
- Re: [urn] new draft 10 - new form (RE: new draft … Dale R. Worley
- Re: [urn] new draft 10 - new form (RE: new draft … Eld Zierau
- Re: [urn] new draft 10 - new form (RE: new draft … Hakala, Juha E
- Re: [urn] new draft 10 - new form (RE: new draft … Eld Zierau
- Re: [urn] new draft 10 - new form (RE: new draft … Henry S. Thompson
- Re: [urn] new draft 10 - new form (RE: new draft … Eld Zierau
- Re: [urn] new draft 10 - new form (RE: new draft … Henry S. Thompson
- Re: [urn] new draft 10 - new form (RE: new draft … Henry S. Thompson
- [urn] FW: new draft 10 - new form (RE: new draft … Eld Zierau