From nobody Wed Dec 4 06:21:51 2019 Return-Path: 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 ; 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 ; 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 ; 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 Cc: "Hakala\, Juha E" , Peter Saint-Andre , urn@ietf.org References: <2396dbcf66bb4c8689bcbabca2cc8492@kb.dk> <4499f99af7b84135ae88b14cc444d080@kb.dk> From: "Henry S. Thompson" 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 14:21:50 -0000 Eld Zierau writes: > Please see my comments below >> -----Original Message----- >> From: Henry S. Thompson >> 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. From nobody Wed Dec 4 06:24:41 2019 Return-Path: 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 AEC16120817 for ; Wed, 4 Dec 2019 06:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.272 X-Spam-Level: X-Spam-Status: No, score=-4.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.073, 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 2SDtEo4nZEft for ; Wed, 4 Dec 2019 06:24:37 -0800 (PST) Received: from seine.is.ed.ac.uk (seine.is.ed.ac.uk [129.215.17.202]) (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 EC5D5120816 for ; Wed, 4 Dec 2019 06:24:36 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.202.41]) by seine.is.ed.ac.uk (8.14.7/8.14.7) with ESMTP id xB4EOS42005220 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 4 Dec 2019 14:24:28 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 xB4EOR2Z027443; Wed, 4 Dec 2019 14:24:27 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 xB4EOSro021929; Wed, 4 Dec 2019 14:24:28 GMT Received: (from ht@localhost) by ecclerig.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id xB4EOSnH021928; Wed, 4 Dec 2019 14:24:28 GMT X-Authentication-Warning: ecclerig.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Eld Zierau Cc: "Hakala\, Juha E" , Peter Saint-Andre , urn@ietf.org References: <2396dbcf66bb4c8689bcbabca2cc8492@kb.dk> <4499f99af7b84135ae88b14cc444d080@kb.dk> From: "Henry S. Thompson" In-Reply-To: <4499f99af7b84135ae88b14cc444d080@kb.dk> (Eld Zierau's message of "Thu\, 28 Nov 2019 14\:50\:24 +0000") User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) Date: Wed, 04 Dec 2019 14:24:28 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at seine.is.ed.ac.uk with MIMEDefang 2.84, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.84 on 129.215.17.202 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 14:24:40 -0000 [resending with a elision of more original text which I didn't directly respond to -- please ignore the preceding version] Eld Zierau writes: > Please see my comments below >> -----Original Message----- >> From: Henry S. Thompson >> 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'. > ... >> 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. From nobody Tue Dec 10 05:19:35 2019 Return-Path: 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 7DA35120098 for ; Tue, 10 Dec 2019 05:19:33 -0800 (PST) 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 L9CzeQX1smA8 for ; Tue, 10 Dec 2019 05:19:30 -0800 (PST) Received: from smtp-out12.electric.net (smtp-out12.electric.net [89.104.206.38]) (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 DEECE12008A for ; Tue, 10 Dec 2019 05:19:29 -0800 (PST) Received: from 1iefQE-0008Cn-Us by out12d.electric.net with emc1-ok (Exim 4.92.3) (envelope-from ) id 1iefQF-0008Hq-Tf; Tue, 10 Dec 2019 05:19:27 -0800 Received: by emcmailer; Tue, 10 Dec 2019 05:19:27 -0800 Received: from [92.43.124.147] (helo=deliveryscan.hostedsepo.dk) by out12d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iefQE-0008Cn-Us; Tue, 10 Dec 2019 05:19:26 -0800 Received: from localhost (unknown [10.72.17.201]) by deliveryscan.hostedsepo.dk (Postfix) with ESMTP id 70E0414C; Tue, 10 Dec 2019 14:19:26 +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 914; Tue, 10 Dec 2019 14:19:29 +0100 (CET) Received: from out12d.electric.net (smtp-out12.electric.net [89.104.206.42]) (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 1F9BE9F50B; Tue, 10 Dec 2019 14:19:26 +0100 (CET) Received: from 1iefQD-000852-UV by out12d.electric.net with hostsite:2468467 (Exim 4.92.3) (envelope-from ) id 1iefQE-0008Ad-T8; Tue, 10 Dec 2019 05:19:26 -0800 Received: by emcmailer; Tue, 10 Dec 2019 05:19:26 -0800 Received: from [92.43.124.46] (helo=pf2.outprescan-mta.hostedsepo.dk) by out12d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iefQD-000852-UV; Tue, 10 Dec 2019 05:19:25 -0800 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 pf2.outprescan-mta.hostedsepo.dk (Postfix) with ESMTPS id 2511DDC9; Tue, 10 Dec 2019 14:19:25 +0100 (CET) Received: from EXCH-02.kb.dk (exch-02.kb.dk [10.5.0.112]) by post.kb.dk (Postfix) with ESMTPS id F2F8291ED1; Tue, 10 Dec 2019 14:19:24 +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; Tue, 10 Dec 2019 14:19:24 +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.005; Tue, 10 Dec 2019 14:19:24 +0100 From: Eld Zierau To: "Hakala, Juha E" , Peter Saint-Andre , "urn@ietf.org" Thread-Topic: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn PWID draft (7) with corrections) Thread-Index: AQHVo9/A5kRRJ7EN1UCh4Vv2CVNmCaegmRHQgAl8VnqACTKRMIAAKNfQ Date: Tue, 10 Dec 2019 13:19:24 +0000 Message-ID: <1f6c17daf8b94dc4b858446486d1291b@kb.dk> References: <2396dbcf66bb4c8689bcbabca2cc8492@kb.dk> <4499f99af7b84135ae88b14cc444d080@kb.dk> 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: pf2.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: Subject: [urn] FW: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 13:19:33 -0000 Forgot to reply all - so therefore forwarded Best Regards, Eld -----Original Message----- From: Eld Zierau=20 Sent: Tuesday, December 10, 2019 11:55 AM To: 'Henry S. Thompson' Subject: RE: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn P= WID draft (7) with corrections) Hi The PWID has been developed in collaboration with digital humanity research= ers (literate and historian), who have requirements for precise and persist= ent references. The precision part is for specification of how precise a re= ference is, and what the purpose with the reference is. It is needed becaus= e of the nature of web material where a web page usually consist of many di= fferent parts that are harvested and archived individually. In the example = of https://www.dr.dk, the differences are: * 'Page': urn:pwid:archive.org:2016-01-22T10:08:23Z:page:https://www.dr.dk is a short hand of the archived version of the harvest of the file http= s://www.dr.dk on 2016-01-22T10:08:23Z=20 together with all the elements (existing in the web archive) needed in = order to render it as a web page in a browser,=20 where the version of the elements is the ones with archiving date close= st to 2016-01-22T10:08:23Z * 'Part': urn:pwid:archive.org:2016-01-22T10:08:23Z:part:https://www.dr.dk is the exact file harvested of the file https://www.dr.dk on 2016-01-22= T10:08:23Z Both references are highly relevant, - 'page' because this is what is neede= d for most referencing purposes today, and part because it can be the code = that is of interest or it can be part of a collection specification (see my= response to Juha 11th of October 2019 15:44). It is two very different things, and therefore it cannot be the same refere= nces. Furthermore, it provides the possibility for digital humanity researc= her to make the precision. Please note that what you say "it's trying to pr= e-judge what someone may want to do with a URI" is NOT the case, it is tell= ing you what the person making the reference want you to see if you use the= reference. If you want to view a web page consisting of different elements, the way to= do that today is by use of a browser and a web archive tool to calculate t= he elements. And yes, there will be differences between browsers, just like= Word documents looks very different depending on version fonts etc. That i= s nothing that a reference can or should solve.=20 Please note, that use of the words "browser" and "View page source" are onl= y used in explanation of how you can assign a PWID and resolve a PWID, and = explanation of what part means for a coded page. There is nothing that sugg= ests, that this is the only way to see it. The explanation/examples are nee= ded, since the PWID is for all, including non-technical persons without kno= wledge of coded web pages and that there are different parts from different= files. So I cannot see that the specification as it is now restrict PWIDs = to URIs "that are supposed to be rendered by browsers", but since we are ta= lking about web material it is likely that this is what the PWID will be us= ed for. Please also note, that both the examples that you give are files and theref= ore there will not be any "View page source" (I don't know whether that is = why you say that "'View Source' is literally unusable", - since its absence= is actually use for determination of the reference as a part) as explained= in the instruction of how to creation a PWID in section "Assignment": "precision-spec (part or page): The precision specification specifies how the referred item should be regarded. A typical PWID URN reference in a paper would be 'page', where a tool will be needed to render the web page. Alternatively, the precision-spec can be 'part', which is the most precise reference since it reference a specific file where no additional calculations are needed (e.g. as part of a collection, a specific html file with hidden links or to indicate that a single image is referenced). In order to see whether a viewed browser page is a computed web page or a single file, browsers have a function "View page source" which is not activated if for single files).=20 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 -----Original Message----- From: Henry S. Thompson Sent: Wednesday, December 4, 2019 3:24 PM To: Eld Zierau Cc: Hakala, Juha E ; Peter Saint-Andre ; urn@ietf.org Subject: Re: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn P= WID draft (7) with corrections) [resending with a elision of more original text which I didn't directly res= pond to -- please ignore the preceding version] Eld Zierau writes: > Please see my comments below >> -----Original Message----- >> From: Henry S. Thompson >> The fourth constituent of a PWID, the *precision-spec*, now has only=20 >> two possible values, 'part' and 'page', which appear to be attempting=20 >> 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=20 > described as: > "* 'part' > ... Yes. > And I must admit that I do not see anything that can be interpreted as=20 > representation in this description, so I cannot follow you point here. The relevant RFCs (3986, 7231, 8141) all use "representation" for the actua= l result of a successful retrieval, that is, a message consisting of a medi= a 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'. > ... >> 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 describe= d as: > "* 'page' Yes. > ... > So it is up to browser software to tell whether it is something that=20 > is interpreted as a page. > And yes a page is "with all other digital objects implicated in that=20 > rendering (e.g. scripts, stylesheets, icons, graphics, fonts ...)",=20 > where I have used terms that are less technical "parts (display=20 > 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 resou= rce, 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)0= 98 *archival-time* 2019-11-18T06:00:21 it identifies such an archival record at the Internet Archive, whose curren= t representation can be retrieved via an HTTP GET request for https://web.archive.org/web/20191118060021/https://link.springer.com/art= icle/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=20 >> image/png, or application/pdf, or audio/ogg? > Eld: The PWID is for referencing purposes, it is not concerned with=20 > types. The PWID is a reference to something that has been harvested=20 > from the internet and is supposed to be rendered by a browser, - so=20 > this is a concern of the original publisher of the element and the=20 > 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 wors= t suggests that PWIDs are only applicable to a very narrow view of what arc= hives may contain. Consider PWIDs constructed from *archive-domain* web.archive.org *archived-uri* https://media.springernature.com/w306/springer-static/c= over/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 curren= t representations can be retrieved via an HTTP GET request for https://web.archive.org/web/20191118053549im_/https://media.springernatu= re.com/w306/springer-static/cover/journal/13130/2018/12.jpg and https://web.archive.org/web/20191118060005/https://link.springer.com/con= tent/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* altoget= her, and made more use of the descriptive terminology and its underlying se= mantics as found in the relevant RFCs mentioned above. ht --=20 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 _al= ways_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, w= ith registration number SC005336. From nobody Tue Dec 10 14:22:51 2019 Return-Path: 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 A042A1200F1 for ; Tue, 10 Dec 2019 14:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=reso-org.20150623.gappssmtp.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 UgPFs8lHbAhL for ; Tue, 10 Dec 2019 14:22:48 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B9A1200D7 for ; Tue, 10 Dec 2019 14:22:48 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id b8so11399626oiy.5 for ; Tue, 10 Dec 2019 14:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reso-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ArlUUY2xsJD7K0cPrQ/aj7a32pP+njY4Qq6TrmoVK80=; b=JtVOnC1/KkktpTpdHx1LwMJ9eIC0RhWo1sjCuuj1jnMy2dgBDZb7TuPqst24jWB50k j+g+91hCVgbbUxjoonDhnoPvaarRK7wdtph01ilpWVDzINJHs2XLJgUsjaJxSHWUfD9p v/fnf4MPnra0knsrqTZ3ATQEtDib2p6gRA8k9rx6w/UmkLIwrf7VNSApTdDXzJdA+6N+ 8WKtjAb+KBvDTVWYclPzO7maBAILRhLX5x5sWvv5cWYIxveEhxBAs6TRPSQhNsPPjABq wugeF3iDlZlDo8WLfFLEWMOhVSBHOHsQcaWeQs4mf0LctWUWOjBPd1iZo+E4Igc4tHa8 fcWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ArlUUY2xsJD7K0cPrQ/aj7a32pP+njY4Qq6TrmoVK80=; b=mirdEGM6HQ4szkJw73fgy/oCoOqpkrMMT0smbuEDfD/dbyvEgxqqC9rU4uXDFBo2YK uGkyUuth3qS90eWbuDVTWf0xOW4kbwrSwUmqIoFMzF30OGH5S9lIt7NRqkuxA8htRyap 7eAJocB9yJQ9hjVMMJqLwqBtuSKzw7aUSned/csBReOhU5yKytyORZ2Fc9miVAvO4hUm J/KaScjwbHXh7gb4x301V6zpawSGWPHHmchkP6PUKB0c7aYexkJHZN9GvJlal8ldD0Dx ir9lvOvQ0ro4L8CXHPevV1RqaDixKfVfhuIfv4Z9/+S5znqeppmGpZkQJtmG54zAYmw/ d4Lg== X-Gm-Message-State: APjAAAUwLExsM8T3IozWBWz7xzUT/rvd/r4psFVwZqqt/iljY9LBdiX8 sDqbpcoS+R6Okoz7tPc78ZDU1XgMZi82RiF0Q54KAQ== X-Google-Smtp-Source: APXvYqxJcpUpk7bJ/Tz5EFJIOfDpvTBnaLeIAajCwH+JXnmMWwFxT0LmgrtLc1+L4itVT3KQ5/9Vj7dlLbkJyelBJ3E= X-Received: by 2002:aca:df07:: with SMTP id w7mr247302oig.145.1576016567227; Tue, 10 Dec 2019 14:22:47 -0800 (PST) MIME-Version: 1.0 References: <87k18h9hja.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Sam DeBord Date: Tue, 10 Dec 2019 14:22:34 -0800 Message-ID: To: "Hakala, Juha E" Cc: "Dale R. Worley" , "urn@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a66ec6059960f3ad" Archived-At: Subject: Re: [urn] Namespace application: reso X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 22:22:51 -0000 --000000000000a66ec6059960f3ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Juha, Thanks for reviewing the RESO website. To provide some more background about how RESO is intending to use URNs, here is a list of their proposed uses so far: - Representation of Unique Licensee IDs. These will have the form of: urn:reso:ulid:x, where x is a specific licensee identifier. Licensees can be people like Agents, photographers, appraisers, and others involve= d in the transaction. - As a "recorder ID" in the following event model proposal , in which case the URN will take a form similar to the following: urn:reso:recorder:org:x, where org is an organization id well-known to RESO and x is identifier of the recording entity in that organization. - Another important use RESO has planned for URNs is for them to act as references to RESO Data Dictionary items already established in our ecosystem. This link shows the "Property" resource , which consists of fields and enumerations. Each field has a RESO-generated RecordID associated with it (or LookupID in the case of enumerated value= s). For example, the PropertySubType field has a RecordID of 100222, and one of the allowed values for that field is Apartment , which is part of Lookup Field ID 302000 and has LookupID 302001. These would have URNs of the form: urn:reso:rid:100222, urn:reso:lfid:302000, and urn:reso:lid:302001, respectively. Let us know if you have any further questions about the above items or regarding our application for a URN. *Sam DeBord* CEO | Real Estate Standards Organization sam@reso.org | 206.658.3225 On Mon, Nov 4, 2019 at 3:01 AM Hakala, Juha E wrote: > Hello, > > I checked the RESO web site, and there is standardization (and other) > activity which would benefit from URN assignment, such as (IMO) IDX data > standard. However, the registration request should provide some backgroun= d > information so that it would not be necessary to retrieve it from somewhe= re > else. > > Also, some examples of URNs to be assigned would give us better idea of > the plans. > > All the best, > > Juha > > -----Alkuper=C3=A4inen viesti----- > L=C3=A4hett=C3=A4j=C3=A4: urn Puolesta Dale R. Wor= ley > L=C3=A4hetetty: sunnuntai 3. marraskuuta 2019 16.11 > Vastaanottaja: Sam DeBord > Kopio: urn@ietf.org > Aihe: Re: [urn] Namespace application: reso > > It may be that I read this document too quickly, but I got the impression > that it is completely *valid*, but it doesn't tell me anything, as far as= I > can tell, as to what these URNs will really be used for. > > Even to the point that I've never heard of the "Real Estate Standards > Organization" or what it does. Does it produce a series of standards tha= t > are used in the real world? Where in those standards would these URNs be > used? > > Simimlarly, the proposed syntax is just that the URNs have to be valid > URNs. It doesn't hint that you've got any detailed plan in mind. > > Dale > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > --000000000000a66ec6059960f3ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Juha,=C2=A0


T= hanks for reviewing the RESO website. To provide some more background about= how RESO is intending to use URNs, here is a list of their proposed uses s= o far:


  • =

    = Representation of Uniq= ue Licensee IDs. These will have the form of: urn:reso:ulid:x, where x is a specific licensee id= entifier. Licensees can be people like Agents, photographers, appraisers, a= nd others involved in the transaction.

  • As a "recorder ID" in the following even= t model proposal, in which case the URN will take a form similar to the following: urn:reso:recorder:org:x, where or= g is an organiz= ation id well-known to RESO and x is identifier of = the recording entity in that organization.

  • Another important use RESO has p= lanned for URNs is for them to act as references to RESO Data Dictionary it= ems already established in our ecosystem. This link shows the "Property" reso= urce, which= consists of fields and enumerations. Each field has a RESO-generated Recor= dID associated with it (or LookupID in the case of enumerated values). For = example, the PropertySubType field has a RecordID of 100222, and one of the allowed values for= that field is Apart= ment, which= is part of Lookup Field ID 302000 and has LookupID 302001. These would hav= e URNs of the form: urn:reso:rid:100222, urn:reso:lfid:302000, and urn:reso:lid:30= 2001, respectiv= ely.=C2=A0


Let us= know if you have any further questions about the above items or regarding = our application for a URN.

=
Sam DeBord
CEO |=C2=A0Real Estate Standards= Organization=C2=A0=C2=A0
= sam@reso.org | 206.658.3225
=


On Mon, Nov 4, 2019 at 3:01 AM Hakala, Juha E= <juha.hakala@helsinki.fi= > wrote:
Hell= o,

I checked the RESO web site, and there is standardization (and other) activ= ity which would benefit from URN assignment, such as (IMO) IDX data standar= d. However, the registration request should provide some background informa= tion so that it would not be necessary to retrieve it from somewhere else. =

Also, some examples of URNs to be assigned would give us better idea of the= plans.

All the best,

Juha

-----Alkuper=C3=A4inen viesti-----
L=C3=A4hett=C3=A4j=C3=A4: urn <urn-bounces@ietf.org> Puolesta Dale R. Worley
L=C3=A4hetetty: sunnuntai 3. marraskuuta 2019 16.11
Vastaanottaja: Sam DeBord <sam@reso.org>
Kopio: urn@ietf.org Aihe: Re: [urn] Namespace application: reso

It may be that I read this document too quickly, but I got the impression t= hat it is completely *valid*, but it doesn't tell me anything, as far a= s I can tell, as to what these URNs will really be used for.

Even to the point that I've never heard of the "Real Estate Standa= rds Organization" or what it does.=C2=A0 Does it produce a series of s= tandards that are used in the real world?=C2=A0 Where in those standards wo= uld these URNs be used?

Simimlarly, the proposed syntax is just that the URNs have to be valid URNs= .=C2=A0 It doesn't hint that you've got any detailed plan in mind.<= br>
Dale

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn
--000000000000a66ec6059960f3ad--