From nobody Sun Jun 1 14:49:11 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5181A00B8 for ; Sun, 1 Jun 2014 14:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 B_nuJpmk4_AE for ; Sun, 1 Jun 2014 14:49:07 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1251A00AF for ; Sun, 1 Jun 2014 14:49:07 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s51LmkIs014117; Sun, 1 Jun 2014 22:48:51 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s51LmjQp016860; Sun, 1 Jun 2014 22:48:45 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s51LmjSx020525; Sun, 1 Jun 2014 22:48:45 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s51LmjrA020521; Sun, 1 Jun 2014 22:48:45 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "John Levine" References: <20140531180107.24859.qmail@joyce.lan> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Sun, 01 Jun 2014 22:48:45 +0100 In-Reply-To: <20140531180107.24859.qmail@joyce.lan> (John Levine's message of "31 May 2014 18\:01\:07 -0000") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/JLObrmaibXROPZM1pAmoSl0EkTU Cc: urn@ietf.org Subject: Re: [urn] DOIs as an example of name/locator confusion, was URNs are not URIs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 21:49:10 -0000 John Levine writes: >> Let's take the e-book example (I'm using a DOI, because >> I happen to remember where to find the resolver for them, but the >> point would be the same for any URN->http:URI resolver today): The >> following _both_ identify the main body of an editorial in the journal >> _Nature_ of 28 May 2014: > >> doi:10.1038/509534a#article >> http://dx.doi.org/10.1038/509534a#article Sorry, the both _identify_ the same thing because the > Actually, they don't. The DOI maps to a bunch of bibliographic info > which you get if you fetch that URL and ask for JSON or bibtex. (See > JSON below.) Fetch? You're right, of course, that I should have tried the official resolution mechanism to see what I got, which I didn't. How should I have done so? > As a hack, albeit the one that people use 99% of the time, if the > publisher provides a URL, the DOI web server responds with a redirect > to the publisher's URL if you ask for html I didn't ask for anything -- I did a bare-naked GET http://dx.doi.org/10.1038/509534a HTTP/1.1 Host: dx.doi.org and followed the redirects. > thereby in practice turning DOIs which are supposed to be names into > locators. In your example, the #article is a fragment in the > redirected page at www.nature.com, nothing to do with the DOI. Hmm. The name/locator duality is something I'll come back to in another post, but I see one interesting thing now which I had missed before -- the first redirect (from dx.doi.org) is a 303 ("See Other"), which, as you say, confirms that the result is _not_, in the meaning of the Act, a representation of what is identified by the URI. More later. 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] From nobody Sun Jun 1 16:32:40 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEED01A00DF for ; Sun, 1 Jun 2014 16:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 3h-A-dDzyOS7 for ; Sun, 1 Jun 2014 16:32:36 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B37B1A00DA for ; Sun, 1 Jun 2014 16:32:36 -0700 (PDT) Received: (qmail 46452 invoked from network); 1 Jun 2014 23:32:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=b573.538bb80d.k1406; bh=0/xFXlST3KCGlD7AGNWyloc5mfeSr6+g95uBFfPSqIA=; b=kWAUZrBZsluR9MUePmasfnCyWStpJxqSVDX2hqpVfIp9+3/a06t8AdEpV2z8dPed5UsRPoJFBvvmjLmfOflj1FqmCkZyDyDUbMgQ0w5EZaidE7k209DuiQgmYV3nNbcd7kEM2fpkIZr1yi/YxSNWNEdOzQa7GAnbujvAdBvju91prENRstvn/ZXE+RD8vYiugzBgXaEIBpW0hN+kJB+G5y+x2HK9cLk8LyaF2fprDYDGJQ7QSS9K6i7JRNXxA+IO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=b573.538bb80d.k1406; bh=0/xFXlST3KCGlD7AGNWyloc5mfeSr6+g95uBFfPSqIA=; b=UdMF6vzpdm1ZrDQV/6GFub9e2cd7nvhQIhoqYAnXiDl9vxjI5DInmRDjiSSZWaRi7IyHk/pqBPShZ/d9Wel5y1vUMBnyimF5YSI/cUtAE6bBSB4QPia/777xZoLQj2npNYei5GAPD8IdPkePsLHi2rNhqRDk28CEO4AFBdGIpRs5yTDSb5IHLyigZJ1LgSTB759SQUS+2AgXIEZ7+K3tAUK4jemSznClsBIA3ZPWII7VGYSIu+CLIwLViEV+pXHj Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 01 Jun 2014 23:32:29 -0000 Date: 1 Jun 2014 19:32:28 -0400 Message-ID: From: "John R Levine" To: "Henry S. Thompson" In-Reply-To: References: <20140531180107.24859.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tTASwLy4JODjR3SaWaPfnJrmV3E Cc: urn@ietf.org Subject: Re: [urn] DOIs as an example of name/locator confusion, was URNs are not URIs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 23:32:38 -0000 >> Actually, they don't. The DOI maps to a bunch of bibliographic info >> which you get if you fetch that URL and ask for JSON or bibtex. (See >> JSON below.) ... > Fetch? You're right, of course, that I should have tried the official > resolution mechanism to see what I got, which I didn't. How should I > have done so? As far as I can tell you can't, since nobody implements the protocol defined by the handle system on which DOIs are based. >> As a hack, albeit the one that people use 99% of the time, if the >> publisher provides a URL, the DOI web server responds with a redirect >> to the publisher's URL if you ask for html > > I didn't ask for anything -- I did a bare-naked > > GET http://dx.doi.org/10.1038/509534a HTTP/1.1 > Host: dx.doi.org > > and followed the redirects. Yes, that's the hack. If your GET asks for HTML, which is of course the default, it returns the redirect, and any fragment name is applied to whatever the publisher returns as the redirected page. If you ask for JSON, you get the bibliographic stuff: $ GET -H 'Accept: application/json' http://dx.doi.org/10.1038/509534a {"subtitle":[],"subject":["General"],"issued":{"date-parts":[[2014,5,28]]},"score":1.0,"prefix":"http:\/\/id.crossref.org\/prefix\/10.1038","container-title":"Nature","reference-count":0,"page":"534-534","deposited":{"date-parts":[[2014,5,28]],"timestamp":1401235200000},"issue":"7502","title":"Welcome, Scientific Data!","type":"journal-article","DOI":"10.1038\/509534a","ISSN":["0028-0836","1476-4687"],"URL":"http:\/\/dx.doi.org\/10.1038\/509534a","source":"CrossRef","publisher":"Nature Publishing Group","indexed":{"date-parts":[[2014,5,31]],"timestamp":1401579700372},"volume":"509"} It's not surprising if you find this confusing -- I had to poke around for a long time before I could figure out what was actually going on. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Jun 2 00:38:29 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076AF1A02A7 for ; Mon, 2 Jun 2014 00:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 WX1GWh_CyYKW for ; Mon, 2 Jun 2014 00:38:24 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7363D1A01A6 for ; Mon, 2 Jun 2014 00:38:23 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s527c57G026708; Mon, 2 Jun 2014 08:38:10 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s527c4a0010594; Mon, 2 Jun 2014 08:38:04 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s527c4ib030406; Mon, 2 Jun 2014 08:38:04 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s527c4aZ030402; Mon, 2 Jun 2014 08:38:04 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "John Levine" References: <20140531180107.24859.qmail@joyce.lan> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 02 Jun 2014 08:38:04 +0100 In-Reply-To: (Henry S. Thompson's message of "Sun\, 01 Jun 2014 22\:48\:45 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/f_xqPCFp4flNdGnxMvE4WO-d1CU Cc: urn@ietf.org Subject: Re: [urn] DOIs as an example of name/locator confusion, was URNs are not URIs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 07:38:27 -0000 ht writes: > John Levine writes: > ... Oops, sent with an unfinished line included, please ignore, see corrected version in next email! 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] From nobody Mon Jun 2 00:41:50 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3BE1A02BB for ; Mon, 2 Jun 2014 00:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 yH1RNbfCwSpj for ; Mon, 2 Jun 2014 00:41:45 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1CE1A01A6 for ; Mon, 2 Jun 2014 00:41:45 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s527fd5l028331; Mon, 2 Jun 2014 08:41:39 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s527fcM2010718; Mon, 2 Jun 2014 08:41:38 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s527fdS8030486; Mon, 2 Jun 2014 08:41:39 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s527fdGD030482; Mon, 2 Jun 2014 08:41:39 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "John Levine" References: <20140531180107.24859.qmail@joyce.lan> From: ht@inf.ed.ac.uk (Henry S. Thompson) In-Reply-To: <20140531180107.24859.qmail@joyce.lan> (John Levine's message of "31 May 2014 18\:01\:07 -0000") User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) Date: Mon, 02 Jun 2014 08:41:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UKpfNM7hYhGkNTjkb601tkwf2Fo Cc: urn@ietf.org Subject: Re: [urn] DOIs as an example of name/locator confusion, was URNs are not URIs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 07:41:48 -0000 John Levine writes: >> Let's take the e-book example (I'm using a DOI, because >> I happen to remember where to find the resolver for them, but the >> point would be the same for any URN->http:URI resolver today): The >> following _both_ identify the main body of an editorial in the journal >> _Nature_ of 28 May 2014: > >> doi:10.1038/509534a#article >> http://dx.doi.org/10.1038/509534a#article I shouldn't have said that they identify _anything:_ an ordinary user can't tell wrt to either of them, as we can't get any evidence on that point because the doi: has no resolver, and although the http: does, its response disclaims its utility for this purpose -- see below. > Actually, they don't. The DOI maps to a bunch of bibliographic info > which you get if you fetch that URL and ask for JSON or bibtex. (See > JSON below.) Fetch? You're right, of course, that I should have tried the official resolution mechanism to see what I got, which I didn't. How should I have done so? > As a hack, albeit the one that people use 99% of the time, if the > publisher provides a URL, the DOI web server responds with a redirect > to the publisher's URL if you ask for html I didn't ask for anything -- I did a bare-naked GET http://dx.doi.org/10.1038/509534a HTTP/1.1 Host: dx.doi.org and followed the redirects. > thereby in practice turning DOIs which are supposed to be names into > locators. In your example, the #article is a fragment in the > redirected page at www.nature.com, nothing to do with the DOI. Hmm. The name/locator duality is something I'll come back to in another post, but I see one interesting thing now which I had missed before -- the first redirect (from dx.doi.org) is a 303 ("See Other"), which, as you say, confirms that the result is _not_, in the meaning of the Act, a representation of what is identified by the URI. More later. 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] From nobody Tue Jun 3 03:38:31 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2081A0198 for ; Tue, 3 Jun 2014 03:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 z5gsqa76-IC9 for ; Tue, 3 Jun 2014 03:38:25 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCBB1A01A0 for ; Tue, 3 Jun 2014 03:38:22 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 49C747F3D6; Tue, 3 Jun 2014 12:38:16 +0200 (CEST) From: "Svensson, Lars" To: "Dale R. Worley" , John C Klensin Thread-Topic: [urn] urn:ietf:rfc Thread-Index: AQHPeqUAmLZMT4fy/UC0iEGFAxV6eZtfNAPg Date: Tue, 3 Jun 2014 10:38:15 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> References: <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <2461.1400713811@sandelman.ca> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> In-Reply-To: <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.203] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UFMHTE1PztW1fYqhkhlZjeKNn1Q Cc: "urn@ietf.org" Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:38:28 -0000 All, (working my way through those threads...) > > > But once we get to ISBN and ISSN, the meaning is much detached > > > from resolution. In particular, there are assumed to be many > > > different ways of resolving the identifier (for various > > > purposes), and no one of them is expected to yield "the" > > > meaning. > > > > And here is where I get confused about where you are going > > because, e.g., an ISBN, once assigned, very much identifies an > > object. >=20 > Aye, but let's look at it in a couple of different ways. >=20 > One way to look at it is from the network engineering point of view. > An ISBN identifies "a book", but that isn't a network-accessible > resource, and so it's pretty much irrelevant. Depends on: eBooks can and do have ISBNs, too, and they are very much netwo= rk accessible, e. g. [1]. > If you're trying to get > any information via the internet about the book, what you're really > getting is various network-accessible resources that are only > sociologically connected to "the book". Many of these are considered > "metadata" (cataloging information, current price on the used book > market, etc.) but some might be seen as semantically overlapping "the > book", such as a recording of the book's text or page images from the > book. If it is a book at all and not e. g. a puzzle [2]. >=20 > Our concept that the ISBN identifies "a book" diverges from the > reality that anything you can do with the ISBN on the internet is at > best a small subset of the information connected to "the book". In > this regard, an ISBN URI is much more abstracted than an HTTP URI. No, not really. [3] is an identifier for TimBL, and on the internet you can= not really *do* very much with him by just using that identifier. It is alw= ays a matter of which services you want to offer. > To add a layer of complexity, the "book" object that an ISBN > identifies is an abstraction. I mean, there is a *book* on my desk at > this moment, but the ISBN printed on that book doesn't really identify > that object -- the ISBN identifies the entire set of existing and > potential books that are "from the same edition" (or whatever the > proper technical term is). And this concept of an object is even > farther from the network engineering, because it isn't even a > physically describable thing. (Of course, the library/publisher > people understand this, but it's an example that are hierarchies of > concepts that we often blithely lump together as "objects", and then > expect them to behave in generally similar ways.) Yes, this is seen as one of the problems of rfc 3986, too: it tries to lump= things together that had evolved in totally different directions. Nonethel= ess, I think there are other concepts in network engineering that are not p= hysically describable either, so that should not be a major obstacle. [1] cf. http://d-nb.info/1031739254 which is an identifier for the eBook "D= er Weg zur optimalen K=FChlung des PCs" with ISBN 978-394-30185-7-8 and urn= urn:nbn:de:101:1-2013022715846 immediately accessible through http://nbn-r= esolving.de/urn:nbn:de:101:1-2013022715846 [2] https://www.qbd.com.au/product/9781743529805 [3] http://d-nb.info/gnd/121649091 Lars=20 From nobody Tue Jun 3 04:14:28 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE911A01B4 for ; Tue, 3 Jun 2014 04:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 iDdqE8BOJr0Q for ; Tue, 3 Jun 2014 04:14:23 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 068321A019B for ; Tue, 3 Jun 2014 04:14:23 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 088F77F393; Tue, 3 Jun 2014 13:14:17 +0200 (CEST) From: "Svensson, Lars" To: "Henry S. Thompson" , John C Klensin Thread-Topic: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC3986) Thread-Index: Ac9/HOq9y64uFoo1TS+MdcsppWfLbA== Date: Tue, 3 Jun 2014 11:14:16 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA444A682@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.203] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/k9S_vRP9gHHEAANI-CjGqjOlLf8 Cc: "urn@ietf.org" Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC3986) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 11:14:25 -0000 Continuing my way through the thread... > 3986 says some things which seem very much in sympathy with URNBIS: >=20 > 1.2.2. Separating Identification from Interaction [2] >=20 > . . . >=20 > A common misunderstanding of URIs is that they are only used to > refer to accessible resources. The URI itself only provides > identification; access to the resource is neither guaranteed nor > implied by the presence of a URI. Instead, any operation > associated with a URI reference is defined by the protocol element, > data format attribute, or natural language text in which it > appears. >=20 > Given a URI, a system may attempt to perform a variety of > operations on the resource, as might be characterized by words such > as "access", "update", "replace", or "find attributes". Such > operations are defined by the protocols that make use of URIs, not > by this specification. If I understand correctly, in the URN world, this is the distinction betwee= n on the one hand URN syntax (2414bis) and the namespace specific constrain= ts laid down in the NID registrations (Identification) and on the other han= d URN resolution (2483bis: Resolution). One might argue that wording like "= such operations are defined by the *protocols* that make use of URIs" [emph= asis added] is unfortunate since URN resolution services might or might not= be tied to any specific protocol. [...] =20 > 3.5 Fragment >=20 > . . . >=20 > As with any URI, use of a fragment identifier component does not > imply that a retrieval action will take place. A URI with a > fragment identifier may be used to refer to the secondary resource > without any implication that the primary resource is accessible or > will ever be accessed. >=20 > Nonetheless fragment( and query) seem to be at the heart of the > perceived problems of URIs expressed in URNBIS [1]: >=20 > 8. The role URI fragment and query could or should have in > identification is unclear and the statements in RFC 3986 are > definitely problematic from the points of view of existing > identifier systems and management of naming. >=20 > Does fragment identify a location or a certain section of a resource? > In the evolving set of URN Internet standards, fragment will not be a > part of the Namespace Specific String. Then fragment only indicates > a place / segment within the identified resource, but does not > identify it. If fragment had a role in identification, fragments > would extend the scope of existing standard identifiers to component > parts of resources. For instance, anyone could use URN based on ISBN > + fragment to identify chapters of electronic books. >=20 > There is certainly a fundamental tension with pretty fundamental IETF > principles (beyond just what we find in 3986) implied here, if I > understand it correctly. Media types play a central role in the IETF > architectural vision: given a character string and a media type, I > know how to find out what I can do with the characters. It doesn't > matter how I got them and their type: from my local disk, via HTTP, in > an email, or by carrier pigeon. And it doesn't matter what name or > names may have been involved in helping me get access to them. One of > the things I can do is use whatever fragment identifier syntax and > semantics is provided by the definition of the media type in question > to . . . identify 'fragments'. And, crucially, those 'fragments' > _need not_ be any locations or sections of the character string or its > interpretation per the media type: >=20 > The identified secondary resource may be some portion or subset of > the primary resource, some view on representations of the primary > resource, or _some other resource defined or described by those > representations_. [emphasis added] [3] >=20 > To make this absolute concrete, given a text/html representation and a > fragment identifier "foo", the secondary resource in question is > e.g. a paragraph in the document resource represented by that html, in > particular the paragraph corresponding to the markup including " name=3D'foo'>" in the representation. Or, given a text/turtle > representation and a fragment "tbl", the secondary resource in > question is e.g. the resource _described_ by the RDF node > corresponding to a line consisting of "<#tbl>" in the representation. > All of that follows straightforwardly from 3986 and the two respective > media type registrations. One big question is, what happens when you retrieve a resource where the me= dia type registration does not specify what the meaning of a fragment ident= ifier is (e. g. application/json [5]). More on that below. > 3986 is clear that those secondary resources are _identified_ by those > fragment identifiers. You appear to be proposing that per URNBIS and > 2141bis e.g. urn:example:w3cstaff#tbl would _identify_ the same > resource as urn:example:w3cstaff (although it might be defined to > 'indicate' something different. . .). This is indeed something I fail to grasp, too. > It seems pretty clear to me that this is a divisive and confusing > thing to do. Let's take the e-book example (I'm using a DOI, because > I happen to remember where to find the resolver for them, but the > point would be the same for any URN->http:URI resolver today): The > following _both_ identify the main body of an editorial in the journal > _Nature_ of 28 May 2014: >=20 > doi:10.1038/509534a#article > http://dx.doi.org/10.1038/509534a#article >=20 > Am I right that your proposal would change this (assuming a URN > instead of a DOI)? I.e., that those two things would no longer > identify the same secondary resource, despite both, minus the > '#article', being usable to retrieve the same text/html representation > of the same resource? This question is of course something John will have to answer, and I can on= ly say that I find this counter-intuitive, too. That, together with the med= ia type problems connected with fragment identifiers, makes me propose that= we should not allow fragment identifiers in URNs. [adding discussion about DOIs] > >> Actually, they don't. The DOI maps to a bunch of bibliographic info > >> which you get if you fetch that URL and ask for JSON or bibtex. (See > >> JSON below.) ... >=20 > > Fetch? You're right, of course, that I should have tried the official > > resolution mechanism to see what I got, which I didn't. How should I > > have done so? >=20 > As far as I can tell you can't, since nobody implements the protocol > defined by the handle system on which DOIs are based. >=20 > >> As a hack, albeit the one that people use 99% of the time, if the > >> publisher provides a URL, the DOI web server responds with a redirect > >> to the publisher's URL if you ask for html > > > > I didn't ask for anything -- I did a bare-naked > > > > GET http://dx.doi.org/10.1038/509534a HTTP/1.1 > > Host: dx.doi.org > > > > and followed the redirects. >=20 > Yes, that's the hack. If your GET asks for HTML, which is of course the > default, it returns the redirect, and any fragment name is applied to > whatever the publisher returns as the redirected page. If you ask for > JSON, you get the bibliographic stuff: >=20 [...] >=20 > It's not surprising if you find this confusing -- I had to poke around fo= r > a long time before I could figure out what was actually going on. The problem I'm having with this is that if we take the original URI json' = http://dx.doi.org/10.1038/509534a#article, ask for 'application/json' and f= ollow the redirects, we end up with the following: svensson@F-NBW7-04660 ~ $ curl -i -H 'Accept: application/json' http://dx.doi.org/10.1038/509534a#a= rticle HTTP/1.1 303 See Other Server: Apache-Coyote/1.1 Vary: Accept Location: http://data.crossref.org/10.1038%2F509534a Expires: Tue, 03 Jun 2014 12:28:34 GMT Content-Type: text/html;charset=3Dutf-8 Content-Length: 170 Date: Tue, 03 Jun 2014 09:40:28 GMT Handle Redirect http://data.cr= ossref.org/10.1038%2F509534a=20 svensson@F-NBW7-04660 ~ $ curl -i -H 'Accept: application/json' http://data.crossref.org/10.1038%2F= 509534a#article HTTP/1.1 200 OK Access-Control-Allow-Headers: X-Requested-With Access-Control-Allow-Origin: * Content-Type: application/json Content-Length: 589 Server: http-kit Date: Tue, 03 Jun 2014 09:42:31 GMT Connection: close {"subtitle":[],"subject":["General"],"issued":{"date-parts":[[2014,5,28]]},= "score":1.0,"prefix":"http:\/\/id.crossref.org\/prefix\/10.1038","container= -title":"Nature","reference-count":0,"page":"534-534","deposited":{"date-pa= rts":[[2014,5,28]],"timestamp":1401235200000},"issue":"7502","title":"Welco= me, Scientific Data!","type":"journal-article","DOI":"10.1038\/509534a","IS= SN":["0028-0836","1476-4687"],"URL":"http:\/\/dx.doi.org\/10.1038\/509534a"= ,"source":"CrossRef","publisher":"Nature Publishing Group","indexed":{"date= -parts":[[2014,5,31]],"timestamp":1401579700372},"volume":"509"} The JSON above has no reference to the fragment 'article' and since the reg= istration of 'application/json' [5] does not mention fragment identifiers, = my question is if the fragment has any meaning at all (apart from identifyi= ng a secondary resource, whichever that might be). > [1] http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00 > [2] http://tools.ietf.org/html/rfc3986#section-1.2.2 > [3] http://tools.ietf.org/html/rfc3986#section-3.5 > [4] http://www.ietf.org/mail-archive/web/urn/current/msg02249.html [5] http://tools.ietf.org/html/rfc4627 Best, Lars *** Lesen. H=F6ren. Wissen. Deutsche Nationalbibliothek ***=20 --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek Informationstechnologie Telefon: +49-69-1525-1752 mailto:l.svensson@dnb.de=20 http://www.dnb.de From nobody Thu Jun 5 05:48:40 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5691A1A00D7 for ; Thu, 5 Jun 2014 05:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 pAUKR6_W97oT for ; Thu, 5 Jun 2014 05:48:35 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id D3D4D1A00D4 for ; Thu, 5 Jun 2014 05:48:34 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s55Cm6WD011959; Thu, 5 Jun 2014 13:48:12 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s55Cm4xT027609; Thu, 5 Jun 2014 13:48:04 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s55Cm4IQ013404; Thu, 5 Jun 2014 13:48:04 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s55Cm4jL013400; Thu, 5 Jun 2014 13:48:04 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 05 Jun 2014 13:48:04 +0100 In-Reply-To: (Henry S. Thompson's message of "Thu\, 29 May 2014 18\:59\:54 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/3eQEn3-dlP3AgNq1iGvzE8pFoLQ Cc: urn@ietf.org Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 12:48:38 -0000 I wrote: > Let's take the e-book example (I'm using a DOI, because > I happen to remember where to find the resolver for them, but the > point would be the same for any URN->http:URI resolver today): The > following _both_ identify the main body of an editorial in the journal > _Nature_ of 28 May 2014: > > doi:10.1038/509534a#article > http://dx.doi.org/10.1038/509534a#article So I was wrong to use the key term of art 'identify' above. Somewhat to my surprise, it turns out that in _neither_ case do we know what the URI identifies, for different but related reasons in the two cases. Wrt the first case, as far as I can tell there _are_ no resolvers available other than ones which translate at source into the second case. Furthermore, I can't find anywhere in DOI documentation any discussion of an intended semantics for fragments. Wrt this, and the second case, 3986 tells us that the ('secondary') resource identified by a URI including a hash is "defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced." http://tools.ietf.org/html/rfc3986#section-3.5 All attempts at retrieval wrt "http://dx.doi.org/10.1038/509534a", however, result in a 303 response code, which means, _inter alia_, that the representation retrievable from the supplied redirection is _not_ a representation of the primary resource. The relevance of this to the original question ("Does 3986 unacceptably constrain URN use?") remains to be explained. I think, at least wrt fragments, the answer is "no", but I'll hold off on trying to explain that until I hear more about what the _requirements_ on fragments are that are behind the stated belief in the current discussion that the answer is "yes". 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] From nobody Thu Jun 5 13:15:47 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A72E1A007B for ; Thu, 5 Jun 2014 13:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 CYyfUGyMsluh for ; Thu, 5 Jun 2014 13:15:42 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id CD5D81A0025 for ; Thu, 5 Jun 2014 13:15:40 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s55KFHJq022480; Thu, 5 Jun 2014 21:15:19 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s55KFFn5013914; Thu, 5 Jun 2014 21:15:16 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s55KFGXj023476; Thu, 5 Jun 2014 21:15:16 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s55KFGiB023472; Thu, 5 Jun 2014 21:15:16 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John Levine References: <20140531180107.24859.qmail@joyce.lan> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 05 Jun 2014 21:15:15 +0100 In-Reply-To: <20140531180107.24859.qmail@joyce.lan> (John Levine's message of "31 May 2014 18\:01\:07 -0000") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/KNtbn99Yb4yQKJulkFl3mJi2huY Cc: urn@ietf.org Subject: Re: [urn] DOIs as an example of name/locator confusion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:15:46 -0000 [Responding only to the change of subject, not the substance :-] 3986 [0] distinguishes between a resource (what a URI *identifies*) and representations ( what you can *retrieve* ). In most cases, although not absolutely necessarily, these are distinct. I think it's useful to distinguish at least four possible empirical properties of (what we currently call) a URI and its scheme (and sub-scheme in the case of a URN): 1) No public generic action is defined for instances of its scheme and/or sub-scheme, either in principle (i.e. by the scheme/sub-scheme definition/registration) or in practice (e.g. by a widely available app or browser plugin). We say that such a URI (scheme/sub-scheme) is *not actionable*; 2) Such an action _is_ defined for at least some instances of its scheme and/or sub-scheme, and it is one such instance. We say it is *actionable*; 3) Not only is it actionable, but one available action ('retrieval', see above), if successful, is defined to yield a representation of the resource it identifies. We say that such a URI is *retrieval-enabled*; 4) Its scheme/sub-scheme is actionable, but at least some of the in-principle available actions fail (for non-contingent reasons). We say that it *does not support* those actions. Examples: 1) 'tel:' -- No actions defined [1] 2) 'mailto:' -- 'construct' and 'send' actions defined, at least implicitly, but no notion of retrieval [2] 3) 'ftp:' -- Retrieval is spelled out in the spec [3] 4) PUTting to 'http://www.w3.org/' -- the PUT action is not supported (4) implies that (2) and (3) are applicable in slightly different ways to URI schemes/URN sub-schemes and to individual URIs (not (1), because if a URI's scheme/sub-scheme is not actionable, it can't be either): 2) Even if a URI's scheme/sub-scheme _is_ actionable, a particular URI may not support any of the actions defined therein; 3) Even if a URI's scheme/sub-scheme _is_ retrieval-enabled, a particular URI may not support the defined retrieval action; for that URI In many cases, the available actions for an actionable URI are defined in the definition/registration of its scheme/sub-scheme by reference to a particular protocol. For 'mailto:' this is SMTP [1], for 'ftp:' it's FTP, for http: it's HTTP (although, interestingly, HTTP is not restricted to actions on 'http:' (and 'https:') URIs). So where in this space does a name/locator distinction emerge? Nowhere, as far as I can tell: "In practice, the line between 'locator' and 'name' has been difficult to draw: locators can be used as names, and names can be used as locators." [4] All URIs are by definition names, not just because they are called identifiers, but because the nature of what can be identified, and of identification, is carefully spelled out [5]. Some URIs (retrieval-enabled ones) are _also_ more-or-less useful as locators. Examples: tel: URIs name "the canonical address-of-record or identifier for a termination point within a specific network" [1], but isn't actionable; mailto: URIs name mailable entities, is an actionable scheme, but is not retrieval-enabled, and doesn't obviously 'locate' anything; ftp: URIs name network resources by locating them. It's retrieval-enabled. It is probably the closest we still have to something that deserves to be called a locator in the ordinary-language sense of the word, i.e. an address. http: URIs name both network and non-network resources. In its early days, most http: URIs were (intended to be) retrieval-enabled. This is no longer true. XML namespace names [6] are explicitly _not_ required to be retrieval-enabled, and many of them are not. For principled reasons, many http: URIs used in Semantic Web documents are not retrieval-enabled (although they _are_ actionable_). doi: URIs likewise name both network and non-networked resources. The original intention as stated [7] was for them to "[identify] entities of significance to the content industry" and to "reference a set of service descriptions". At the very least they were intended to be actionable, and in practice they now are, perhaps not quite as originally intended. Whether they are retrieval-enabled is less clear to me. urn:ietf:rfc URIs name IETF RFCs, and services exist which act as retrieval proxies, see for example http://wm-urn.org/urn:ietf:rfc:2119 A plugin could be constructed to reproduce the simple transformation from urn:ietf:rfc:nnnn to http://tools.ietf.org/html/rfc2119 but I don't _think_ the IETF has any published commitment to that mapping, or nor is it obvious what the status of this statement [8] is: The canonical URI is of the form: http://www.rfc-editor.org/rfc/rfcXXXX.txt. The point, now perhaps overly belaboured, is that in practice there is a _huge_ range of variation within a complex multi-dimensional space as regards actionability, retrievability and comprehensiblity (that is, can you find out what a URI identifies if all you have is the URI, and if so, how). Suggesting that there is a straightforward "name/locator" distinction ignores the richness of the actual phenomenena. So, back to my core question: what are the requirements? Saying "we need names, not locators" is not a requirement until you tell me what the operational distinction is that you are covertly appealing to. If you find the above terminology/taxonomy helpful in answering my question, so much the better. ht [1] http://tools.ietf.org/html/rfc3966 ]2] http://tools.ietf.org/html/rfc6068 [3] http://tools.ietf.org/html/rfc1738 [4] http://tools.ietf.org/html/bcp35 [5] http://tools.ietf.org/html/rfc3986#section-1.1 [6] http://www.w3.org/TR/REC-xml-names/ [7] http://tools.ietf.org/html/draft-paskin-doi-uri-04 [8] http://www.rfc-editor.org/pubprocess.html -- 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] From nobody Sat Jun 14 01:26:00 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783591B2BDE for ; Sat, 14 Jun 2014 01:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 n5grA0MiA8im for ; Sat, 14 Jun 2014 01:25:48 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6899E1B2BDB for ; Sat, 14 Jun 2014 01:25:48 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WvjFc-000H6x-KO for urn@ietf.org; Sat, 14 Jun 2014 04:23:48 -0400 Date: Sat, 14 Jun 2014 04:25:42 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <964DC8688FC7E02C49E21E2D@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/--L2LoRa2UfCPSu8SaQBj8x2bXQ Subject: [urn] Tuning the "URNs are not URIs" spec X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 08:25:54 -0000 Hi. After several discussions in the last two weeks, including two very significant (to me at least) offline and face to face ones, it seems to me that the explanation in draft-ietf-urnbis-urns-are-not-uris-00 may be missing the point or be irrelevant to some people. Consequently, I propose to add the following text to the I-D. It was written on the assumption that it would be an appendix but that is not a firm decision or anything we need to decide now. If we do want to keep it for the long term (as distinct from helping with discussion in the interim), perhaps we should think about creating two subsections of Section 2, one more or less the present Section 2 and the other a variation on the text below. In any event, comments welcome on the text below. Unless the general sense of the WG is that it sets us backwards, I'd generate and post a new draft that incorporates it (and any agreeable modifications) sometime next week. Again, having the text at this point is not a commitment for it to be in the final document. The question, IMO, is whether it will help to move the discussions forward and thereby contribute to getting the WG's work unstuck. john ----- Proposed text ----------- Appendix A. A More Pragmatic Perspective Section 2 provides an explanation of the reasons for this change. That explanation is not without controversy, especially from those who make different assumptions about the future, or even interpretations of the present, than many members of the community (and especially members of the communities describe in that section). Some of those who do not accept the explanation above simply do not recognize the distinctions on which it, and URNs more generally, are based, including the name-locator distinction. In some cases, opposition to that explanation is quite pronounced, involving fundamental differences in philosophy that move beyond mere differences of opinion. Like most controversies in which one group does not accept the definitions, facts, or logic of another, the differences are unlikely to be resolved by further discussion, no matter how sensible and patient. The material in this appendix is provided for the benefit of those who cannot accept Section 2 or consider the discussion there to be meaningless. Independent of the details of the discussion above, in the case of URNs, the IETF is faced with a pair of problems that are ultimately faced sooner or later by all voluntary standards bodies: nothing except quality and broad community consensus prevents a standard from being ignored in the marketplace and nothing prevents another body from creating a competing standard. The effort required to create a competing standard can be increased and its potential for confusion can be reduced somewhat by various measures -- measures the IETF has rarely tried to actually use -- but those measures are rarely effective when the other body is convinced that they have legitimate and significant needs that differ from the original atandard. Because of those problems, the key question for the URN effort is ultimately not whether a clear enough distinction exists between names and locator or location-based information, nor whether "persistent" can be defined clearly enough, nor even whether the communities and requirements described in Section 2 are valid or will be judged valid in retrospect in a few decades or centuries. Instead, the question is whether the IETF is willing to evolve and adapt the URN definition to accommodate those perceived needs or whether if prefers to have that work done elsewhere, either by adoption in the broader community and marketplace of a different approach or, potentially, even a competing URN standard. If, in the long run, those other communities and perspectives turn out to be wrong, the additional features will atrophy. But that would be true whether they are specified and standardized in the IETF or elsewhere. --- end proposed text ----------- From nobody Sat Jun 14 01:39:33 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BE11B2BE0 for ; Sat, 14 Jun 2014 01:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 ZG7yZ9yd-CHB for ; Sat, 14 Jun 2014 01:39:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B5E1B2BD4 for ; Sat, 14 Jun 2014 01:39:29 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WvjSq-000H7k-Ih; Sat, 14 Jun 2014 04:37:28 -0400 Date: Sat, 14 Jun 2014 04:39:22 -0400 From: John C Klensin To: "Svensson, Lars" , "Dale R. Worley" Message-ID: <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> References: <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <2461.1400713811@sandelman.ca> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/iH2ea9JdfRt0aiuLW1pxnjAGH-g Cc: urn@ietf.org Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 08:39:31 -0000 --On Tuesday, June 03, 2014 10:38 +0000 "Svensson, Lars" wrote: >... >> Our concept that the ISBN identifies "a book" diverges from >> the reality that anything you can do with the ISBN on the >> internet is at best a small subset of the information >> connected to "the book". In this regard, an ISBN URI is much >> more abstracted than an HTTP URI. > > No, not really. [3] is an identifier for TimBL, and on the > internet you cannot really *do* very much with him by just > using that identifier. It is always a matter of which services > you want to offer. >... The one thing I would add to the above is that parts of the URN discussion could be seen as about adding mechanisms for service requests to the overall URN string. If "what services you want to offer" is the right vocabulary (I, at least, found it very helpful), then "service request" may be much closer to what is needed then such apparently-specific types of service requests as "queries" or "fragments". That may then take us back to discussions of many months ago as to whether one can or should use the query notion and syntax to hide or encapsulate what we can now call service requests with very different characteristics. The answer appears to be "yes, but only if one is willing to resort to syntax tricks or other mechanisms to deal with services that don't fit in the same 'who does what to whom (or which objects or date' frameworks". See the note I just posted titled 'Tuning the "URNs are not URIs" spec'. best, john From nobody Mon Jun 16 01:18:37 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C73D1B28B8 for ; Mon, 16 Jun 2014 01:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 a79fUIyUl9vB for ; Mon, 16 Jun 2014 01:18:33 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id BBA141B27EE for ; Mon, 16 Jun 2014 01:18:32 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 20E377F247; Mon, 16 Jun 2014 10:18:31 +0200 (CEST) From: "Svensson, Lars" To: John C Klensin , "Dale R. Worley" Thread-Topic: [urn] urn:ietf:rfc Thread-Index: AQHPh6wwCPVD3KNJFUCeOEHSMji5WptzZm3A Date: Mon, 16 Jun 2014 08:18:30 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA445BC22@dnbf-ex1.AD.DDB.DE> References: <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <2461.1400713811@sandelman.ca> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> In-Reply-To: <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.182] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/oQOJZIGysTORfqGgn_I3Hgzzvhs Cc: "urn@ietf.org" Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 08:18:35 -0000 John, > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: Saturday, June 14, 2014 10:39 AM > To: Svensson, Lars; Dale R. Worley > Cc: urn@ietf.org > Subject: RE: [urn] urn:ietf:rfc >=20 >=20 >=20 > --On Tuesday, June 03, 2014 10:38 +0000 "Svensson, Lars" > wrote: >=20 > >... > >> Our concept that the ISBN identifies "a book" diverges from > >> the reality that anything you can do with the ISBN on the > >> internet is at best a small subset of the information > >> connected to "the book". In this regard, an ISBN URI is much > >> more abstracted than an HTTP URI. > > > > No, not really. [3] is an identifier for TimBL, and on the > > internet you cannot really *do* very much with him by just > > using that identifier. It is always a matter of which services > > you want to offer. > >... >=20 > The one thing I would add to the above is that parts of the URN > discussion could be seen as about adding mechanisms for service > requests to the overall URN string. If "what services you want > to offer" is the right vocabulary (I, at least, found it very > helpful), then "service request" may be much closer to what is > needed then such apparently-specific types of service requests > as "queries" or "fragments". Yes, "service request" sounds good to me. > That may then take us back to discussions of many months ago as > to whether one can or should use the query notion and syntax to > hide or encapsulate what we can now call service requests with > very different characteristics. The answer appears to be "yes, > but only if one is willing to resort to syntax tricks or other > mechanisms to deal with services that don't fit in the same 'who > does what to whom (or which objects or date' frameworks". Perhaps this is where the tension lies: Who performs the service? In the UR= N scenario we differ between the identifier (including the identified resou= rce) and the resolution service. My gut feeling is that we need to be more = explicit about if the service is performed by the identified resource or by= the resolution service. Is there consensus on that? > See the note I just posted titled 'Tuning the "URNs are not > URIs" spec'. I need to think a bit about that and shall come back later. Best, Lars=20 From nobody Mon Jun 16 05:41:53 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4881A000F for ; Mon, 16 Jun 2014 05:41:52 -0700 (PDT) X-Quarantine-ID: <4wnA6DzpZTmO> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...Xdn28yaA@mail.gmail.com>\n \n ; Mon, 16 Jun 2014 05:41:50 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC61C1A0009 for ; Mon, 16 Jun 2014 05:41:50 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WwWCK-000MMd-2e; Mon, 16 Jun 2014 08:39:40 -0400 Date: Mon, 16 Jun 2014 08:41:41 -0400 From: John C Klensin To: "Svensson, Lars" , "Dale R. Worley" Message-ID: In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA445BC22@dnbf-ex1.AD.DDB.DE> References: <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <2461.1400713811@sandelman.ca> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EFA445BC22@dnbf-ex1.AD.DDB.DE> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tRN9l_L9JUNZmHcmXDAwigyb4mo Cc: urn@ietf.org Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 12:41:52 -0000 --On Monday, June 16, 2014 08:18 +0000 "Svensson, Lars" wrote: >... >> That may then take us back to discussions of many months ago >> as to whether one can or should use the query notion and >> syntax to hide or encapsulate what we can now call service >> requests with very different characteristics. The answer >> appears to be "yes, but only if one is willing to resort to >> syntax tricks or other mechanisms to deal with services that >> don't fit in the same 'who does what to whom (or which >> objects or date' frameworks". > > Perhaps this is where the tension lies: Who performs the > service? In the URN scenario we differ between the identifier > (including the identified resource) and the resolution > service. My gut feeling is that we need to be more explicit > about if the service is performed by the identified resource > or by the resolution service. Is there consensus on that? Certainly it is at least part of the tension, but, to make things a little more complicated, I'm not sure about the dichotomy between "performed by the identified resource" and "performed by the resolution service", perhaps partially because we may be hand waving a bit when we say "resolution service". I think that earlier comments on the list suggest that the resolution service (if any) associated with a particular URN is bound to the NID in its definition, not to URNs generally (people should check 2141bis to be sure it is clear enough about that). But, if "resolution service" is NID-dependent, and given the number of different flavors of data, metadate, and representations of objects, I don't see any reason to prohibit registering an NID whose definition says "for information or answers of type X, go here; for type Y, go there; and for type Z, go to this third place" and where "go" would include some combination of method, location, and information for applying them to each other. Put differently, there is nothing intrinsically special (or per-NID-unique) about a "resolution service" -- it is just a direct or indirect mechanism for obtaining data, metadata, objects, or other information. If that is the case, then it should be possible for the URN-string to be explicit about the ways in which, and target to which, service requests are to be addressed. >> See the note I just posted titled 'Tuning the "URNs are not >> URIs" spec'. > > I need to think a bit about that and shall come back later. I look forward to your comments. thanks, john From nobody Mon Jun 16 22:47:42 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9F21A0273 for ; Mon, 16 Jun 2014 22:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 BjelGuCxBGaz for ; Mon, 16 Jun 2014 22:47:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7C81A0271 for ; Mon, 16 Jun 2014 22:47:36 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 17 Jun 2014 05:47:34 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0954.000; Tue, 17 Jun 2014 05:47:34 +0000 From: Larry Masinter To: Peter Saint-Andre , John C Klensin , Barry Leiba , SM Thread-Topic: [urn] URNs, permanence, resolution, and indirection/abstraction Thread-Index: AQHPehUholQHu8BXREq+DSd2DEeJ4Jt05maA Date: Tue, 17 Jun 2014 05:47:34 +0000 Message-ID: References: <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <2461.1400713811@sandelman.ca> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net> <537E7E86.4040400@stpeter.im> <3E8CB876A388DD8352A04912@JCK-EEE10> <53853D3B.1070204@stpeter.im> In-Reply-To: <53853D3B.1070204@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(51704005)(21056001)(74502001)(66066001)(76176999)(99396002)(2656002)(85852003)(50986999)(101416001)(54356999)(95666004)(99286002)(93886003)(105586001)(87936001)(80022001)(46102001)(81542001)(64706001)(76482001)(81342001)(76576001)(79102001)(83072002)(77982001)(86362001)(20776003)(19580395003)(85306003)(15975445006)(19580405001)(4396001)(74316001)(83322001)(33646001)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/SSelDadQiDaXkN5Y9LxB_VFqEbU Cc: "julian.reschke@gmx.de" , Michael Richardson , Carsten Bormann , "urn@ietf.org" Subject: Re: [urn] URNs, permanence, resolution, and indirection/abstraction X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 05:47:39 -0000 > There are three ways to get from a URN to one of more resolution > services There are as many ways as you want but none are context-independently autho= ritative. The only authority for urn:dodo:47 is to look up 'dodo' in the IANA registr= y of URN names, and to ask the authority listed "what does urn:dodo:47 mean= ". All of the other resolution means are temporary expedients, whose behavior = and success or failure do not change the meaning. If the dodo authority moves or changes then the IANA registry will need to = be updated. Obtaining an authoritative result cannot be generically automated, because = URN namespaces aren't constrained to offer resolution at all. A level of indirection doesn't help. I'm not sure why anyone is bothering with trying to build a standard resolu= tion service when many namespaces don't offer explicit lookup services. Larry > Now that raises all of the issues a few of us have been > discussing. The URN itself provides information: Dodo 32 is > presumably a different dodo than Dodo 47. But one can want to > locate or obtain Dodo 32, one can want information about it, > such as its weight or state of health (probably pretty > consistent for dodos), and so on and a way is needed to talk > about that different stuff. More important, if the Dodo > Registry were, say, at Oxford University, one might want some > level of indirection in case Oxford decided to transfer the > registry elsewhere or to close its institutional doors (this is > one place where the difference between tens of years and tens of > centuries becomes important). Our typical way to way to deal > with that would be to build the constructed URL template as > Method://international-dodo-registry.org/?dodo-number=3D32> but > suppose one's concerns about permanence _for the particular NID_ > was such that you wouldn't want to trust in the continued > existence of the DNS or that of the ORG TLD? That is the job > URN.ARPA was intended to serve, so that dodo.urn.arpa would > provide a pointer to where the template information was at any > given time and/or appropriate DDDS material. That would work > well for concerns about ORG, but not for concerns about the ARPA > TLD or the DNS. For the latter, one would want to abstract > URN.ARPA too, such that there was a single, URN-specific (not > NID-specific) definition of where to look for the information > that is now (optionally) stored at .urn.arpa. If the DNS > imploded, that document could be updated with the new "how to > find the tree" information and appropriate chronology retained. > > This is obviously turtles all the way down and getting the right > stopping rules requires fairly serious thought. But, if one > wants to think about "permanence", one has to do that work... I admit that I'm happy to merely help define the URN syntax, not the=20 resolution rules. > and then the definers of each NID decide how permanent it needs > to be in terms of levels of abstraction and indirection such at > those outlined above. Yes, that does seem to be a helpful exercise for those who are defining=20 NIDs. Do we perhaps need some text along these lines in 3406bis? Peter _______________________________________________ urn mailing list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn From nobody Tue Jun 17 02:16:59 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FD11A0332 for ; Tue, 17 Jun 2014 02:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=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 c7UG9ej0Jm-b for ; Tue, 17 Jun 2014 02:16:55 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5581A0331 for ; Tue, 17 Jun 2014 02:16:54 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 5454A32E55A; Tue, 17 Jun 2014 18:16:53 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 2d13_1aab_7a09b10e_3f7a_4781_9de9_da06e8c1aba2; Tue, 17 Jun 2014 18:16:52 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 77DDABF537; Tue, 17 Jun 2014 18:16:52 +0900 (JST) Message-ID: <53A00774.7020708@it.aoyama.ac.jp> Date: Tue, 17 Jun 2014 18:16:36 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <964DC8688FC7E02C49E21E2D@JcK-HP8200.jck.com> In-Reply-To: <964DC8688FC7E02C49E21E2D@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/t9FPTbkWmadDoN-4uZseywMdkfM Subject: Re: [urn] Tuning the "URNs are not URIs" spec X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 09:16:57 -0000 Hello John, others, Your text proposal below is helpful because it shows how you frame the current discussion in terms of standard politics and procedures. First, you mention "several discussions". These discussions may have lead you to certain conclusions, but it doesn't mean that WG members can make the same (or maybe other) conclusions without getting more information on these discussions, either from you or from the other people involved (or preferably from both). I have no idea about the content of these discussions, but just for devil's advocate, there would be a huge difference between e.g. some of these discussions including very clear indications (even threats) of "having that work done elsewhere" and e.g. discussants showing little or no understanding for the (real or perceived) needs of (some parts of) the library community. Maybe there was both, or there was something else althogether. So I would strongly urge you and others who have been involved in these discussions to inform the WG and therefore the public via this list. Second, and more important, is that your document starts at the wrong end. Section 2 may be a good start for a requirements document. And based on that, it may be possible to work out how to address the various issues brought up. After discussion of each of the requirements and possible solutions addressing these, we would end up with a spec that may or may not have some discrepancies with RFC 3986. It is at this point, and only at this point, that we can with good faith decide to put something like the current Section 3 into the spec, and to label the document as "updates 3986". Cutting ties before we know we need to cut them is hopelessly premature. I don't currently have the time to go through all nine items in Section 2 (*). But in order to show that what I said in the previous paragraph is important, I'm going to pick out one item and explain my concerns in more detail: 7. Persistent identification must be available for resources which are available only in databases and other environments that are often identified today as "deep web". URIs for these resources tend to be very complicated and it will be difficult to keep them alive even with the help of DNS redirection when e.g. the underlying database management system changes. Reading this, I don't see any point I would have to disagree with. But there is also nothing I can see or even guess that would suggest that persistent identification (meaning URNs, yes?) and URIs need to be separated. It is already possible with current syntax to define URNs for resources in the "deep web". Keeping the correspondence between such URNs and their referent will be difficult when the underlying database management system changes. As far as I can see, that's not URI's fault and not URN's fault, and isn't affected, positively or negatively, by separating URNs from URIs. Similar for length issues. It's possible to define short URNs or short URIs if that's what is needed. Both for URNs and for URIs, there are ample examples. Again, length issues are not affected, positively or negatively, by separating URNs from URIs. So at the minimum, items such as item 7 need a lot more work to make the connection to Section 3 way clearer. Or they should just be removed as non-sequiturs, leaving only those items (if any) that actually support a conclusion such as that in Section 3. So in summary, I'd strongly suggest to invest *way more* work into the technical aspects of this document. The IETF has a very strong and healthy tradition of putting technical arguments first. It is my strong belief that if the technical arguments are actually there and are presented well enough, then political/procedural text such as the appendix below won't be necessary. On the other hand, if the technical arguments can't be found, then again the appendix below (and the whole document) will become irrelevant. Regards, Martin. (*) I note in passing that the paragraphs between item 8 and 9, and those after item nine, should be formatted to be part of the preceding item). On 2014/06/14 17:25, John C Klensin wrote: > Hi. > > After several discussions in the last two weeks, including two > very significant (to me at least) offline and face to face ones, > it seems to me that the explanation in > draft-ietf-urnbis-urns-are-not-uris-00 may be missing the point > or be irrelevant to some people. Consequently, I propose to add > the following text to the I-D. It was written on the assumption > that it would be an appendix but that is not a firm decision or > anything we need to decide now. If we do want to keep it for > the long term (as distinct from helping with discussion in the > interim), perhaps we should think about creating two subsections > of Section 2, one more or less the present Section 2 and the > other a variation on the text below. > > In any event, comments welcome on the text below. Unless the > general sense of the WG is that it sets us backwards, I'd > generate and post a new draft that incorporates it (and any > agreeable modifications) sometime next week. Again, having the > text at this point is not a commitment for it to be in the final > document. The question, IMO, is whether it will help to move > the discussions forward and thereby contribute to getting the > WG's work unstuck. > > john > > ----- Proposed text ----------- > > Appendix A. A More Pragmatic Perspective > > Section 2 provides an explanation of the reasons for this > change. That explanation is not without controversy, > especially from those who make different assumptions about > the future, or even interpretations of the present, than > many members of the community (and especially members of > the communities describe in that section). Some of those > who do not accept the explanation above simply do not > recognize the distinctions on which it, and URNs more > generally, are based, including the name-locator > distinction. In some cases, opposition to that explanation > is quite pronounced, involving fundamental differences in > philosophy that move beyond mere differences of opinion. > > Like most controversies in which one group does not accept > the definitions, facts, or logic of another, the > differences are unlikely to be resolved by further > discussion, no matter how sensible and patient. The > material in this appendix is provided for the benefit of > those who cannot accept Section 2 or consider the > discussion there to be meaningless. > > Independent of the details of the discussion above, in the > case of URNs, the IETF is faced with a pair of problems > that are ultimately faced sooner or later by all voluntary > standards bodies: nothing except quality and broad > community consensus prevents a standard from being ignored > in the marketplace and nothing prevents another body from > creating a competing standard. The effort required to > create a competing standard can be increased and its > potential for confusion can be reduced somewhat by various > measures -- measures the IETF has rarely tried to actually > use -- but those measures are rarely effective when the > other body is convinced that they have legitimate and > significant needs that differ from the original atandard. > Because of those problems, the key question for the URN > effort is ultimately not whether a clear enough distinction > exists between names and locator or location-based > information, nor whether "persistent" can be defined > clearly enough, nor even whether the communities and > requirements described in Section 2 are valid or will be > judged valid in retrospect in a few decades or centuries. > Instead, the question is whether the IETF is willing to > evolve and adapt the URN definition to accommodate those > perceived needs or whether if prefers to have that work > done elsewhere, either by adoption in the broader > community and marketplace of a different approach or, > potentially, even a competing URN standard. If, in the > long run, those other communities and perspectives turn > out to be wrong, the additional features will atrophy. But > that would be true whether they are specified and > standardized in the IETF or elsewhere. > > --- end proposed text ----------- > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Tue Jun 17 07:08:04 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D441A010A for ; Tue, 17 Jun 2014 07:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 ycJyBlFh-O53 for ; Tue, 17 Jun 2014 07:07:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF76C1A0037 for ; Tue, 17 Jun 2014 07:07:56 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 17 Jun 2014 14:07:55 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0954.000; Tue, 17 Jun 2014 14:07:55 +0000 From: Larry Masinter To: "Svensson, Lars" , "Dale R. Worley" , John C Klensin Thread-Topic: IETF does protocol design, not philosophy Thread-Index: Ac+KMRfZkiYSsFoRTxWsnSg8DJ8OfA== Date: Tue, 17 Jun 2014 14:07:54 +0000 Message-ID: <02612d1be78948ed8735770116a558e1@BL2PR02MB307.namprd02.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(105586001)(74502001)(85852003)(21056001)(81542001)(87936001)(83322001)(19580395003)(4396001)(77982001)(15975445006)(76482001)(46102001)(92566001)(95666004)(2656002)(54356999)(99286002)(74316001)(99396002)(101416001)(86362001)(20776003)(80022001)(2171001)(81342001)(31966008)(33646001)(76576001)(64706001)(15202345003)(66066001)(79102001)(83072002)(50986999)(85306003)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/mC8RIeJCXrlh8OGha9XWqYD7TsY Cc: "urn@ietf.org" Subject: [urn] IETF does protocol design, not philosophy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 14:08:02 -0000 We're protocol designers, not philosophers. We should be talking about the = URI/URN/URL protocols. In this protocol, two parties Alice (A) and B (B), are communicating. Embe= dded in their communication A ------- UR* ---> B Alice, speaking with Bob, utters a URI/URL/URN. Bob, receiving this UR* fro= m Alice, interprets it. The UR* is an element of an overall communication protocol, and we are desi= gning the UR* protocol element so that it's useful in lots of contexts, whether they're H= TML, HTTP, XMPP, DNS or whatever. We've had a design where URNs of the form urn:: fit int= o the overall space of URI things of the form : by using "urn" as t= he scheme. While it's true that if Alice tells Bob "urn:ietf:rfc:2517" in some context= rather than "http://tools.ietf.org/html/rfc2517" that Bob will not be able to process t= hat URI in the same way, and whether that's as useful to Bob depends on the protoco= l context; if it's in a hyperlink in a HTML document, probably not, unless so= meone=20 set up some system for turning the former into the latter and informed Bob = about that out of band (e.g., changing the registration of the urn:ietf URN names= pace to make that system authoritative). In many contexts, the intention of a communication of a UR* is through seve= ral layers of indirection. UR*s are just strings composed by encoding parts and concatenating them with punctuation.=20 "urn:isbn:978-394-30185-7-8" at its shallowest means "whatever the authorit= y for the isbn URN namespace is 978-394-30185-7-8", with the hope that the isbn authority will tell Bob the same thing it told Alice when Alice looked it up, while "http://nbn-resolving.de/urn:nbn:de:101:1-2013022715846" at its shallowest could be "use HTTP to the host nbn-resolving.de with path /urn:nbn:De:101:1-2013022715846". Everything else -- whether Alice meant to tell Bob about a book or a person= or an edition of a book or the book's metadata and not the book itself -- is not specified. If you need to be more specific in the protocol you're desig= ning -- if you need more information than is present in a URI/URN/URL -- then=20 you need to supply it some other way. Links can have link types, other metadata supplied in protocol parts, fields, attributes or whatever other than the UR*.=20 Sorry, you can't fix your protocol by packing more info into the UR* than is already there.=20 Larry -- http://larry.masinter.net From nobody Tue Jun 17 13:15:08 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6171A0170 for ; Tue, 17 Jun 2014 13:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2] autolearn=ham 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 Ylui32K22pe9 for ; Tue, 17 Jun 2014 13:15:04 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id C28C11A011C for ; Tue, 17 Jun 2014 13:15:03 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id FW6n1o0050cZkys53YF3Gc; Tue, 17 Jun 2014 20:15:03 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta10.westchester.pa.mail.comcast.net with comcast id FYF21o00E1KKtkw3WYF2uW; Tue, 17 Jun 2014 20:15:03 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s5HKF2OZ012087; Tue, 17 Jun 2014 16:15:02 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s5HKF0Xx012074; Tue, 17 Jun 2014 16:15:00 -0400 Date: Tue, 17 Jun 2014 16:15:00 -0400 Message-Id: <201406172015.s5HKF0Xx012074@hobgoblin.ariadne.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: John C Klensin In-reply-to: <964DC8688FC7E02C49E21E2D@JcK-HP8200.jck.com> (john-ietf@jck.com) References: <964DC8688FC7E02C49E21E2D@JcK-HP8200.jck.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403036103; bh=pWLGidUeJElFNx6t7HIpQkW4aXmpBTyvMdsDqs75Xc8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=anCsdUByKzGhhNWndNhYIU6tFeLpi4DFLQnk1oOYkTAOQUOn8MepWUabVgLNTXHfw KR/ROIhebzbxnYEUEsF87HhfHEHPQSoatrozRGUYoKSfPiA/umN8O0uUvWq6vsD+IA C8v1k3ad4vXur7n2XOQQEK3YOuxZemICO/ufhSlfqfuMRgHIAXrESvKU+BYWLKfsN5 1E1musYJx+YSPYihiEz+xAoENsUhQjSpYFuU9kkq++Uny4sHgkweRCYZjAiqLE2BL0 EBR4EhgaLGHu7/X99CgEMztVD8FGrTAOrQZqB5F4ixWyhMG/5gvsx05XTEcesJRtfV T0PrWMhNWCEmA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/VxSzGyEModB9nYx-_hsPXuzJRNQ Cc: urn@ietf.org Subject: Re: [urn] Tuning the "URNs are not URIs" spec X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:15:05 -0000 > From: John C Klensin > Like most controversies in which one group does not accept > the definitions, facts, or logic of another, the > differences are unlikely to be resolved by further > discussion, no matter how sensible and patient. I'd phrase it "... in which EACH group does not accept ... of THE OTHER". > Instead, the question is whether the IETF is willing to > evolve and adapt the URN definition to accommodate those > perceived needs or whether if prefers to have that work > done elsewhere, either by adoption in the broader > community and marketplace of a different approach or, > potentially, even a competing URN standard. As far as I can tell, the key question is "Is the syntax of RFC 2141 ("URN syntax") inadequate for the needs of important groups of users?" If the syntax is adequate, then various groups of users can define namespaces that have the properties that they desire without causing any upset in running code; at most, revisions would be needed to RFC 3406 ("URN namespace definition mechanisms"). (Unlike IPv4 addresses, we aren't in danger of running out of namespace identifiers.) (And for example, this flexibility allows multiple sets of identifiers which handle name/locator differences in distinctly different ways.) What seems to be constantly hinted at in this discussion -- but never explicitly stated -- is that important groups of users have needs that CANNOT be satisfied within the syntax of RFC 2141. Not just that the particular definitions of "fragment" and "query" in RFC 3986 are inadequate for their needs, but that those needs cannot be satisfied by *any alternative means* that can be represented within the syntax of RFC 2141. If that actually is so, it is a fairly concrete fact, it shouldn't be very difficult to make the case in a convincing way. And once the case is made, it would be a sound reason to move ahead with significant changes to the status quo. One objection I can see to RFC 2141 is how restrictive it is: The namespace-specific string can contain only letters (two cases), digits, and 15 of the 32 ASCII special characters. (That's not counting %, since it has a special purpose.) I can see how a group may want to have much more syntactic flexibility in designing an identifier, and they wouldn't enjoy %-encoding a large fraction of the characters in their identifiers. OTOH, there's no reason that a user group would have to *see* what their URNs look like very often. Most user interfaces that would refer to sophisticated identifiers don't have to reveal the URNs that are used one the wire, any more than that we have to see the bits that encode the characters of our e-mails. For instance, there's no reason that DOIs can't be encoded much the same way that EIDRs are encoded (draft-pal-eidr-urn-03): The DOI "10.1051/0004-6361:20054201" becomes the URN "urn:doi:10.1051:0004-6361%3a20054201". (Any sequence of Unicode characters can be represented as a sequence of %-escapes per RFC 2141 section 2.2.) The great benefit of this approach is that generic operations on these URNs can be done by the great bulk of currently running code. Dale From nobody Tue Jun 17 13:36:41 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768871A0174 for ; Tue, 17 Jun 2014 13:36:40 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...Xdn28yaA@mail.gmail.com>\n \n ; Tue, 17 Jun 2014 13:36:34 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4848B1A016F for ; Tue, 17 Jun 2014 13:36:34 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta01.westchester.pa.mail.comcast.net with comcast id FY2R1o0060SCNGk51YcZ4x; Tue, 17 Jun 2014 20:36:33 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta09.westchester.pa.mail.comcast.net with comcast id FYcZ1o00q1KKtkw3VYcZmK; Tue, 17 Jun 2014 20:36:33 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s5HKaXOl014407; Tue, 17 Jun 2014 16:36:33 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s5HKaWrG014406; Tue, 17 Jun 2014 16:36:32 -0400 Date: Tue, 17 Jun 2014 16:36:32 -0400 Message-Id: <201406172036.s5HKaWrG014406@hobgoblin.ariadne.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: John C Klensin In-reply-to: (john-ietf@jck.com) References: <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <2461.1400713811@sandelman.ca> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EFA445BC22@dnbf-ex1.AD.DDB.DE> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403037393; bh=pJNTR3JE6NWgDp0+pwW3TZdkbjxLAg7wQuMQR6cvx4s=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=TQlONFCCIMSisrS6FXG1IgCGRT68WXQ/EGaIRGI/8g20cMFbxBQwDCnnVrtIBPmon AR9zvQDcqiZw/WmlXENCCayUu+RThgpz20xolax/bR7Cg+3TqYKD3wKwWMZweXPWdv Zk9c16l6u045xy2WBV7hkypZdhCT0qVQromqnJlQcGKL6HSpeckXO1fYj7Pacf1sA+ KQ3RvZejX38mSp6SgtKWZsjYfeej9bh7nx0Srko0daSea2V0x4STnGgS58Op5EMeM9 fuSf/rZUzzEUv0CJUmeiVuvOy2ue2hTfo0r0UY1hDgzCbj2vKD4t6CMi7VfHLAH/Wn hEf3aSqbDwo/g== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/eZOvc-E9CsS9pjJZZyqdHMzMF4Q Cc: urn@ietf.org Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:36:40 -0000 > From: John C Klensin > I think that earlier comments on the list suggest that the > resolution service (if any) associated with a particular URN is > bound to the NID in its definition, not to URNs generally > (people should check 2141bis to be sure it is clear enough about > that). It's clear enough in practice that the resolution service(s) that can be used in regard to a URN -- or at least, the "well-known" resolution service(s) -- are determined only by the NID defintion; there is no generic resolution service that applies uniformly to all URNs. I think that I've detected traces of an earlier conception that there will be a well-known resolution service that applies consistently to all URNs, but that concept seems to be so obsolete now that nobody has ever confirmed my suspicions. > But, if "resolution service" is NID-dependent, and given > the number of different flavors of data, metadate, and > representations of objects, I don't see any reason to prohibit > registering an NID whose definition says "for information or > answers of type X, go here; for type Y, go there; and for type > Z, go to this third place" and where "go" would include some > combination of method, location, and information for applying > them to each other. Put differently, there is nothing > intrinsically special (or per-NID-unique) about a "resolution > service" -- it is just a direct or indirect mechanism for > obtaining data, metadata, objects, or other information. > > If that is the case, then it should be possible for the > URN-string to be explicit about the ways in which, and target to > which, service requests are to be addressed. All this makes sense to me. Dale From nobody Tue Jun 17 15:15:51 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE7E1A019B for ; Tue, 17 Jun 2014 15:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.704 X-Spam-Level: X-Spam-Status: No, score=0.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=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 Tp1hnu8TgEKy for ; Tue, 17 Jun 2014 15:15:47 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8323E1A0188 for ; Tue, 17 Jun 2014 15:15:47 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wx1d3-00003l-E2; Tue, 17 Jun 2014 18:13:21 -0400 Date: Tue, 17 Jun 2014 18:15:28 -0400 From: John C Klensin To: Larry Masinter , "Svensson, Lars" , "Dale R. Worley" , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Message-ID: In-Reply-To: <02612d1be78948ed8735770116a558e1@BL2PR02MB307.namprd02.prod.outlook.com> References: <02612d1be78948ed8735770116a558e1@BL2PR02MB307.namprd02.prod.outlook.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/TN_vSyBzd_jcM2ej1e3HmQD4_QI Cc: urn@ietf.org Subject: Re: [urn] IETF does protocol design, not philosophy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 22:15:49 -0000 Larry, Perhaps your note illustrates another part of the disconnect we are having in the URN space. Some of the intended/desired uses are precisely not in an [Internet] protocol context. Even of those that are, many do not follow your "A ------- UR* ---> B" model because the URNs are used as indicators, not retrieval indicators of some sort (most, but not all, uses with "HTML, HTTP, XMPP, DNS or whatever" are for retrieval elements, but some, including ones that Peter has identified for XMPP and several recent I-Ds, are not). In particular, Alice may want to inquire whether a URN with a particular NID and NSS exists in some data structure or transaction and then take an action on that basis that is indicated by the URN but that has nothing to do with communicating the URN to Bob or otherwise executing or resolving it. In retrospect, perhaps we would have been better off had we avoided the generic URI idea entirely, preferring a wide variety of URLs -- all intended for use in contexts that fit your model -- and then invented a Universal Digital Indicator or Universal Digital Flag that would have entirely different properties. But we didn't go in that direction and it looks to me, right now, as if there is no practical way to get back there without even more damage. One of Martin's recent notes in another thread seems to me to be another aspect of the same problem. For URLs, the "HTTP GET" and "HTTP HEAD" requests -- same object with different verbs -- is a useful distinction and no further distinctions are needed among the URL that locates (or describes) the object. From a variation on that perspective, the URN issue is that, at a slightly higher level of abstraction ("name" versus "location"), there is a desire to be able to incorporate that distinction into the identifying string itself, not somehow know that anything that can be the target of a URL can be fully retrieved with GET or have some specific metadata retrieved with HEAD. >From my point of view, we haven't been completely consistent about that distinction even with URLs: we say GET in HTTP to fetch the whole object HEAD to fetch a certain type of metadata, but, if we want only a section or material after a starting point, we say GET and then apply a fragment identifier to the result. That operation could have been defined differently, e.g., by saying GET frag= or, for improved backwards compatibility and error messages, GETPARTIAL frag= to push the extraction job onto the server/ resolution mechanism. As with URLs versus a hypothetical UDI or UDF, one can argue endlessly about whether a model in which pure indicators (or information that designates different types of action loci and instructions for them are necessary). I imagine we will never agree about that. But that, and part of Dale's recent note (to while I'll respond separately), ultimately comes down to the issue I was trying to get at in my recent proposed text. There is a significant community who believe that the distinctions are relevant and that additional syntax and flexibility are needed. It is, IMO, largely irrelevant whether they are, in some abstract philosophical sense, or even from a protocol design sense based on a particular perspective, "correct". The main thing that is relevant is that if we decline to accommodate their perceived needs, they will either fork the standard or head off in a different way entirely. Our trying to say "no, you are wrong", even if we had consensus on that (and I don't believe we do) would be extremely unlikely to change anyone's mind. IMO, given that entirely pragmatic situation, the right things for us to do are: (1) Stop this debate, suck it up as needed, try to elicit (real or perceived) requirements, and design/modify the URN specs accordingly. (2) To the degree to which some people think this is the wrong way to proceed (or that the communities who think they have other requirements are wrong-headed), I would hope that they would start on an I-D that would explain the One True Path as clearly and lucidly as possible, with the intent of publishing that discussion as an informational that reflects their view of the present and future RFC. Whether such a document should be a WG product or an individual or independent submission is probably less important than it be written... at least if this debate about philosophy or perspective is actually important rather than a delaying or obstructionist action. best, john --On Tuesday, June 17, 2014 14:07 +0000 Larry Masinter wrote: > We're protocol designers, not philosophers. We should be > talking about the URI/URN/URL protocols. > > In this protocol, two parties Alice (A) and B (B), are > communicating. Embedded in their communication > > > A ------- UR* ---> B > > Alice, speaking with Bob, utters a URI/URL/URN. Bob, receiving > this UR* from Alice, interprets it. The UR* is an element of > an overall communication protocol, and we are designing the UR* > protocol element so that it's useful in lots of contexts, > whether they're HTML, HTTP, XMPP, DNS or whatever. > > We've had a design where URNs of the form > urn:: fit into the overall space of URI > things of the form : by using "urn" as > the scheme. > > While it's true that if Alice tells Bob "urn:ietf:rfc:2517" in > some context rather than "http://tools.ietf.org/html/rfc2517" > that Bob will not be able to process that URI in the same way, > and whether that's as useful to Bob depends on the protocol > context; if it's in a hyperlink in a HTML document, probably > not, unless someone set up some system for turning the former > into the latter and informed Bob about that out of band (e.g., > changing the registration of the urn:ietf URN namespace to > make that system authoritative). > > In many contexts, the intention of a communication of a UR* is > through several layers of indirection. > > UR*s are just strings composed by encoding parts and > concatenating them with punctuation. > > "urn:isbn:978-394-30185-7-8" at its shallowest means "whatever > the authority for the isbn URN namespace is > 978-394-30185-7-8", with the hope that the isbn authority > will tell Bob the same thing it told Alice when Alice looked > it up, while > "http://nbn-resolving.de/urn:nbn:de:101:1-2013022715846" at > its shallowest could be "use HTTP to the host nbn-resolving.de > with path /urn:nbn:De:101:1-2013022715846". > > Everything else -- whether Alice meant to tell Bob about a > book or a person or an edition of a book or the book's > metadata and not the book itself -- is not specified. If you > need to be more specific in the protocol you're designing -- > if you need more information than is present in a URI/URN/URL > -- then you need to supply it some other way. Links can have > link types, other metadata supplied in protocol parts, fields, > attributes or whatever other than the UR*. > > Sorry, you can't fix your protocol by packing more info into > the UR* than is already there. > > Larry > -- > http://larry.masinter.net > From nobody Wed Jun 18 00:34:45 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0C71A005D for ; Wed, 18 Jun 2014 00:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 rAcnOTfzuY0X for ; Wed, 18 Jun 2014 00:34:36 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (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 375791A002A for ; Wed, 18 Jun 2014 00:34:35 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s5I7YXdH030238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2014 10:34:34 +0300 Message-ID: <53A14107.5020300@helsinki.fi> Date: Wed, 18 Jun 2014 10:34:31 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: urn@ietf.org, John C Klensin References: <964DC8688FC7E02C49E21E2D@JcK-HP8200.jck.com> <201406172015.s5HKF0Xx012074@hobgoblin.ariadne.com> In-Reply-To: <201406172015.s5HKF0Xx012074@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/wOGECW1XpwVrDMrLeABEUPZSD8Q Subject: Re: [urn] Tuning the "URNs are not URIs" spec X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 07:34:40 -0000 Hello, On 17.6.2014 23:15, Dale R. Worley wrote: >> From: John C Klensin >> Instead, the question is whether the IETF is willing to >> evolve and adapt the URN definition to accommodate those >> perceived needs or whether if prefers to have that work >> done elsewhere, either by adoption in the broader >> community and marketplace of a different approach or, >> potentially, even a competing URN standard. > As far as I can tell, the key question is "Is the syntax of RFC 2141 > ("URN syntax") inadequate for the needs of important groups of users?" Urnbis charter requires (among other things) the WG to make > an update of the formal syntax specification in the light of the > URI Standard (STD 66, RFC 3986) using the ABNF from STD 68 > (RFC 5234) In practice, two major changes are needed: revised URN syntax should allow the use of fragment and query. The use of URI fragment to indicate locations within identified resources enables creation of URN-based citations instead of URL-based ones. But in order to avoid breaking the assignment rules of traditional standard identifiers, RFC2141bis must make it clear that the fragment is not part of the namespace specific string (that is, from URN point of view, it does not identify anything). There is definitely also a need to use URI query for passing resolution related parameters to URN resolvers. URN resolvers currently in use are dumb; of all the resolution services specified in RFC 2483 they usually support by default only URN - URL mapping (to a single URL only). This is insufficient, since users may not want the document itself. Instead they may be interested in descriptive metadata about the resource, or other versions of the resource (work), etc. DDDS (Dynamic Delegation Discovery System) has been available since 2002 as a means for passing service related information to resolvers, but it has not become popular. URI query provides a more lightweight and technically sufficient means for making URN resolvers smarter. > If the syntax is adequate, then various groups of users can define > namespaces that have the properties that they desire without causing > any upset in running code; at most, revisions would be needed to RFC > 3406 ("URN namespace definition mechanisms"). (Unlike IPv4 addresses, > we aren't in danger of running out of namespace identifiers.) Services available in namespaces depend to large extent on applications used to manage the identified resources. That is, resolution services supported by a namespace will change over time. For instance, with their current systems (such as integrated library systems and open repositories) libraries could in principle support all the URN resolution services specified in RFC 2483. In fact, there is already a problem since metadata about resource can be supplied in many metadata formats, and RFC 2483 does not allow the libraries to specify the format (it is supposed to be URC or Uniform Resource Characteristics, which does not exist). In the future, when e.g. national libraries will establish digital preservation systems, a lot of new services will be available. For instance, a user can check if there are earlier / later versions of the identified resource in the digital archive. He will be able to compare the intellectual content of successive versions of the work, which may differ due to migrations needed to maintain the usability, and check which applications will be needed to render the preferred version readable. > > (And for example, this flexibility allows multiple sets of identifiers > which handle name/locator differences in distinctly different ways.) > > What seems to be constantly hinted at in this discussion -- but never > explicitly stated -- is that important groups of users have needs that > CANNOT be satisfied within the syntax of RFC 2141. I have tried to make it clear that for instance library community needs additional functionality which can be provided by query and fragment. > Not just that the > particular definitions of "fragment" and "query" in RFC 3986 are > inadequate for their needs, but that those needs cannot be satisfied > by *any alternative means* that can be represented within the syntax > of RFC 2141. I can't see an acceptable alternative for the usage of fragments. Everyone must be able to make citations and references, but identifier assignment - when done properly - is a managed process. DDDS could be used instead of query, but slow / non-existent adoption of the former during the last decade makes it clear to at least me that an alternative method is needed. > > If that actually is so, it is a fairly concrete fact, it shouldn't be > very difficult to make the case in a convincing way. And once the > case is made, it would be a sound reason to move ahead with > significant changes to the status quo. The problem is that what looks convincing to e.g. library community - and we are not the only significant group out here which is using persistent identifiers - may not convince other groups which have different requirements and applications. If there is no need to preserve millions of documents for hundreds of years, even cool URIs may look like a sufficient solution. > > One objection I can see to RFC 2141 is how restrictive it is: The > namespace-specific string can contain only letters (two cases), > digits, and 15 of the 32 ASCII special characters. (That's not > counting %, since it has a special purpose.) I can see how a group > may want to have much more syntactic flexibility in designing an > identifier, and they wouldn't enjoy %-encoding a large fraction of the > characters in their identifiers. In practice, many communities which use URNs do not see this as a significant limitation. Standard identifiers often allow only a very limited set of characters. And even if UNICODE is allowed in principle (as in Handle system), it is not used in practice. The problem some traditional identifier systems such as ISBN and ISSN are facing when they are applied to digital documents has to do with the syntax. For instance, ISBN has been extended once (from ISBN-10 to ISBN-13) to extend the scope of the system. And the next revision is already under way. > > OTOH, there's no reason that a user group would have to *see* what > their URNs look like very often. Most user interfaces that would > refer to sophisticated identifiers don't have to reveal the URNs that > are used one the wire, any more than that we have to see the bits that > encode the characters of our e-mails. Correct. If resolution service / services exist, then making an ISBN actionable by turning it into URN can be an automated process. And this actionability is all the ISBN users want from URNs. URN implementation should not change the scope of the ISBN system in any way. > > For instance, there's no reason that DOIs can't be encoded much the > same way that EIDRs are encoded (draft-pal-eidr-urn-03): > > The DOI "10.1051/0004-6361:20054201" > becomes the URN "urn:doi:10.1051:0004-6361%3a20054201". > > (Any sequence of Unicode characters can be represented as a sequence > of %-escapes per RFC 2141 section 2.2.) > > The great benefit of this approach is that generic operations on these > URNs can be done by the great bulk of currently running code. Technically, DOIs (or Handles or ARKs) can be expressed as URNs, and vice versa. But there is no added value whatsoever if the URN is resolved in the same way as the DOI. There is often just one traditional identifier (such as ISBN), but it has to be made actionable in different ways. Let's assume that we have a doctoral dissertation published in PDF format with an ISBN. DOI using this ISBN as suffix may resolve to the publisher's repository, which is behind a pay wall. Same ISBN as Handle may provide a link to the DSpace-based open repository maintained by the author's alma mater where the thesis is available for free. And finally the national library may have a legal deposit copy of the book with URN:ISBN, available for free but only on dedicated workstations in legal deposit libraries (so a user not using one of these workstations will only get metadata about the book). In theory, all this functionality could be provided by the publisher's DOI resolver. In practice, this is not likely to happen, for financial reasons that should be quite obvious. As an aside, PID communities are currently considering creation of multi-PID resolvers (via e.g. adding URN resolution functionality to the Handle software). This is necessary since there are (open) repositories which contain documents with different PIDs. Juha > > Dale > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Wed Jun 18 01:18:00 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F871A007C for ; Wed, 18 Jun 2014 01:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 ZxXRJXP92aJH for ; Wed, 18 Jun 2014 01:17:54 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (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 D346F1A005D for ; Wed, 18 Jun 2014 01:17:52 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s5I8HqVF005472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2014 11:17:52 +0300 Message-ID: <53A14B2E.4090100@helsinki.fi> Date: Wed, 18 Jun 2014 11:17:50 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: urn@ietf.org, John C Klensin References: <2461.1400713811@sandelman.ca> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EFA445BC22@dnbf-ex1.AD.DDB.DE> <201406172036.s5HKaWrG014406@hobgoblin.ariadne.com> In-Reply-To: <201406172036.s5HKaWrG014406@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/4d1If1kd3mnPICdIM-oYJjxTcAw Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 08:17:58 -0000 Hello, On 17.6.2014 23:36, Dale R. Worley wrote: >> From: John C Klensin >> I think that earlier comments on the list suggest that the >> resolution service (if any) associated with a particular URN is >> bound to the NID in its definition, not to URNs generally >> (people should check 2141bis to be sure it is clear enough about >> that). > It's clear enough in practice that the resolution service(s) that can > be used in regard to a URN -- or at least, the "well-known" resolution > service(s) -- are determined only by the NID defintion; there is no > generic resolution service that applies uniformly to all URNs. If the identifier is "dumb", then by definition there can only be one URN resolver / resolution service for this namespace (of course, the resolver may be mirrored so that there are several physical instances of it). The resolver may provide 1-n resolution services, which may change over time. ISSN is an example of "dumb" identifier; it is not possible to tell where and when the periodical was published just by looking at the ISSN string. If the identifier provided "hints" which help at locating the resolver, there may be 1-n resolvers. NBN may have, in theory, unlimited number of resolvers. Each country using URN:NBNs typically has at least one, and there may be more. On the other hand, it is possible to create a cascade of URN:NBN resolvers by copying the URN - URL mapping tables from local to national and further to international URN:NBN resolvers. The URN resolver the National Library of Finland built is "optimized" for NBNs. The program that deals with URN "local things" is very short and compact, but the program which deals with resolver decentralization is more complex. > I > think that I've detected traces of an earlier conception that there > will be a well-known resolution service that applies consistently to > all URNs, but that concept seems to be so obsolete now that nobody has > ever confirmed my suspicions. Given the number of URN namespaces registered, URNs assigned and URN resolvers built, it is not practical to try create a global URN resolver which harvests all URN - URL mappings from all resolvers out there. But there are definitely a lot of opportunities for namespace specific or geographical cooperation. > >> But, if "resolution service" is NID-dependent, and given >> the number of different flavors of data, metadate, and >> representations of objects, I don't see any reason to prohibit >> registering an NID whose definition says "for information or >> answers of type X, go here; for type Y, go there; and for type >> Z, go to this third place" and where "go" would include some >> combination of method, location, and information for applying >> them to each other. Put differently, there is nothing >> intrinsically special (or per-NID-unique) about a "resolution >> service" -- it is just a direct or indirect mechanism for >> obtaining data, metadata, objects, or other information. This kind of rich functionality is exactly what the library community intends to achieve with query. But instead of specifying all the required functionality in NID registration request, it is better to have RFC 2483bis which specifies a mechanism for registering URN resolution services and parameters related to them. For instance, there is already URI to URC service to retrieve metadata about resource, but it must also be possible to specify the format in which the metadata is to be retrieved. Since new metadata formats (and revised versions of existing ones) appear frequently, trying to list all these formats in an RFC is too slow a method; an IANA registry is needed. NID registrations could then refer to the registry when describing the intended services. So, when a user wants Dublin Core metadata about the resource, the resolver should know that a) appropriate protocol is SRU and b) since the ISBN is for a Finnish book, the correct place to pass the SRU search request to is the SRU server of the national union catalogue. Converting the URN:ISBN with query requiring metadata about the identified resource into SRU ISBN search request is not complicated, but the resolver must "know" how to do it. At present the URN - URL mapping tables maintained in resolvers are simple, but when more resolution services become available, resolvers must become more "intelligent". In order to keep things manageable, resolution services supported by resolvers must be standard-based, which will (usually) be the case. >> >> If that is the case, then it should be possible for the >> URN-string to be explicit about the ways in which, and target to >> which, service requests are to be addressed. > All this makes sense to me. And to me too (I think). Juha > > Dale > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Wed Jun 18 11:15:29 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3E31A01CC for ; Wed, 18 Jun 2014 11:15:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 xWnQQkCUS2jQ for ; Wed, 18 Jun 2014 11:15:14 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 3423F1A0261 for ; Wed, 18 Jun 2014 11:15:14 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta08.westchester.pa.mail.comcast.net with comcast id FriL1o0050mv7h058uFDbA; Wed, 18 Jun 2014 18:15:13 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta11.westchester.pa.mail.comcast.net with comcast id FuFB1o00T1KKtkw3XuFCJ2; Wed, 18 Jun 2014 18:15:13 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s5IIF8iV006166; Wed, 18 Jun 2014 14:15:08 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s5IIF6di006163; Wed, 18 Jun 2014 14:15:06 -0400 Date: Wed, 18 Jun 2014 14:15:06 -0400 Message-Id: <201406181815.s5IIF6di006163@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Juha Hakala In-reply-to: <53A14B2E.4090100@helsinki.fi> (juha.hakala@helsinki.fi) References: <2461.1400713811@sandelman.ca> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EFA445BC22@dnbf-ex1.AD.DDB.DE> <201406172036.s5HKaWrG014406@hobgoblin.ariadne.com> <53A14B2E.4090100@helsinki.fi> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403115313; bh=ADWyrpqaeA0uDmNBesKFgSx6rpmHJQdxPlOwrZ7Z2z0=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=SeMzt9RALgQ4Ztcp2Ziz1yw2ZqhVJb9yjMPBIsvRgmea/BMPQkpY7oVxmEO+wuuhl Avz04YzwVXgBp9UNBgr2UdO3lU+1rpHZWHesiNSNecrv70pdboBOYm5ss2R+DyJS57 n0iEvTckObLF5DhlvWdWaDZXwI3zKYLWGSjNhNDwxI5VfwrNxAmunMjBOXcogYB/Hj FngyL50BFbFEJdFs+d0r480R9lWexq1yhvEM+b+l3kuoWyL+GbJPBWw+OZMjEvlQ+y 05P+TF1mjSzd5yxIWTInfNhXAnRETfvOokWJlCfiXqSknup0BksuaAhoH8mItocXh6 05ximfgFRGYZQ== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/12MHZefyPDhB8dsor2GnCrQBd_E Cc: urn@ietf.org Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 18:15:20 -0000 I agree with the bulk of these messages, but there are a few points which I think need modification. > From: Juha Hakala > If the identifier is "dumb", then by definition there can only be one > URN resolver / resolution service for this namespace There can only be one resolution service that is designed as "authoritative" by the NID registration, but clearly various administrators can create multiple resolution services which map the same identifiers. It would probably be difficult to ensure that any un-authoritative resolution service contained information that was complete. But if an authoritative resolution service had incentives to not include information that its users want, I can see that users might support the creation of an alternative resolution service that would include additional information. > From: Juha Hakala > In practice, two major changes are needed: revised URN syntax should > allow the use of fragment and query. I agree that these would be desirable. I expect that very little running code would fail if URN with fragments and queries were used. > The use of URI fragment to indicate locations within identified > resources enables creation of URN-based citations instead of URL-based > ones. But in order to avoid breaking the assignment rules of traditional > standard identifiers, RFC2141bis must make it clear that the fragment is > not part of the namespace specific string (that is, from URN point of > view, it does not identify anything). The limitation on the semantics of in RFC 3986 is that its significance is defined only by the media type of the retrieved resource, independently of the URI that it is attached to. I don't know if that is a problem for URN-based citations; naively it seems to me to not be a problem. But of course, if it is a problem, it may be worth updating RFC 3986 to eliminate that rule. > There is definitely also a need to use URI query for passing resolution > related parameters to URN resolvers. URN resolvers currently in use are > dumb; of all the resolution services specified in RFC 2483 they usually > support by default only URN - URL mapping (to a single URL only). This > is insufficient, since users may not want the document itself. Instead > they may be interested in descriptive metadata about the resource, or > other versions of the resource (work), etc. > I have tried to make it clear that for instance library community needs > additional functionality which can be provided by query and fragment. Strictly speaking, "additional functionality which can be provided by query and fragment" doesn't *need* to be provided by and . (Within some namespace,) two URN characters could be reserved to demarcate the and within a URN which conforms to the current syntax. But that would be poor design, given that there is unlikely to be a problem if the syntax was expanded to allow URNs to have and parts. > Technically, DOIs (or Handles or ARKs) can be expressed as URNs, and > vice versa. But there is no added value whatsoever if the URN is > resolved in the same way as the DOI. There is added value, in that if a DOI can be expressed as a URN, it can be placed in a location where the context demands a URI. Dale From nobody Thu Jun 19 00:59:29 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD271A0358 for ; Thu, 19 Jun 2014 00:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 ejAkJqMhlJbB for ; Thu, 19 Jun 2014 00:59:21 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (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 D2B431A0084 for ; Thu, 19 Jun 2014 00:59:19 -0700 (PDT) Received: from [172.17.5.100] (hupnet-fw.fe.helsinki.fi [128.214.173.46]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s5J7x610009739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Jun 2014 10:59:07 +0300 Message-ID: <53A29849.4050006@helsinki.fi> Date: Thu, 19 Jun 2014 10:59:05 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dale R. Worley" References: <2461.1400713811@sandelman.ca> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EFA445BC22@dnbf-ex1.AD.DDB.DE> <201406172036.s5HKaWrG014406@hobgoblin.ariadne.com> <53A14B2E.4090100@helsinki.fi> <201406181815.s5IIF6di006163@hobgoblin.ariadne.com> In-Reply-To: <201406181815.s5IIF6di006163@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/iN9Ml4n304wGwx0qQ5_toCFm2-c Cc: urn@ietf.org Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 07:59:25 -0000 Hello, On 18.6.2014 21:15, Dale R. Worley wrote: > I agree with the bulk of these messages, but there are a few points > which I think need modification. > >> From: Juha Hakala >> > >> In practice, two major changes are needed: revised URN syntax should >> allow the use of fragment and query. > I agree that these would be desirable. I expect that very little > running code would fail if URN with fragments and queries were used. Fragments are ignored when URNs are resolved so they should cause no problems whatsoever. When a URN resolver encounters a query service request / request related parameter it does not support, there are several options. In increasing order of preference, the resolver may: - ignore the query completely (which, I think, is what the HTTP servers often do) - inform the user that the resolution service requested is not supported (and, perhaps, send a list of supported ones) - inform the user that the resolution service requested is supported, but not the parameter (for instance, the resolver may support URI to URC, but not the metadata format the user asked for) From the URN resolver application development point of view, supporting rich set of resolution services will be an interesting challenge. Sometimes it will be easy to add new services, but that will not always be the case. For instance, if a user wants metadata about the identified resource, it is easy to map the URN into a URL search request, if the target system supports SRU (http://www.loc.gov/standards/sru/) or some other well known industry standard. But if the target system is proprietary, a technique known as screen scraping must be used. The idea is to emulate a typical end user session. Unfortunately the code needed tends to be complex and it may break down whenever the GUI of the target system is modified. > > Strictly speaking, "additional functionality which can be provided by > query and fragment" doesn't *need* to be provided by and > . (Within some namespace,) two URN characters could be > reserved to demarcate the and within a URN > which conforms to the current syntax. But that would be poor design, > given that there is unlikely to be a problem if the syntax was > expanded to allow URNs to have and parts. Having to specify query and fragment separately for each NID would be cumbersome to the extreme. Also, if any Unicode character can be used in the identifier itself (as in Handles, for instance) it is not possible to reserve some characters to this kind of special usage. >> Technically, DOIs (or Handles or ARKs) can be expressed as URNs, and >> vice versa. But there is no added value whatsoever if the URN is >> resolved in the same way as the DOI. > There is added value, in that if a DOI can be expressed as a URN, it > can be placed in a location where the context demands a URI. Like URNs, DOIs are usually expressed as URIs, with the address of the resolver / proxy included. URN resolvers would not be able to cope with DOIs. For instance, query usage is already possible, but it has a specific meaning. For instance, http://doi.org/10.1000/demo_DOI and http://doi.org/10.1000/demo_DOI?index=3 are both actionable, but they resolve to different documents. Handle record may contain multiple URLs with different index values. The latter DOI resolves to the URL with index value 3. DOI Handbook says about resolution (http://www.doi.org/doi_handbook/3_Resolution.html) that: > Increasing numbers of DOI names include data in addition to the single > default URL. This is sometimes referenced as multiple resolution. > These added values are intended for use by more advanced applications > which have the ability to take advantage of multiple pieces of data, > e.g., the location of enhanced metadata or related documents. DOI and ARK systems are already developing ways of using query in their own, non-interoperable ways to pass resolution related guidelines to resolvers. If IETF can a) agree that query can officially be used for this purpose, and b) provide a means, such as IANA registry, for registering resolution services and service related parameters, the groups developing persistent identifiers may still be able to avoid re-inventing too many wheels. Juha > Dale -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Thu Jun 19 01:38:03 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900DA1A035D for ; Thu, 19 Jun 2014 01:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=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 OaM8RFFtdp6i for ; Thu, 19 Jun 2014 01:37:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198F51A035A for ; Thu, 19 Jun 2014 01:37:58 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 19 Jun 2014 08:37:57 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0954.000; Thu, 19 Jun 2014 08:37:57 +0000 From: Larry Masinter To: John C Klensin , "Svensson, Lars" , "Dale R. Worley" , =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= Thread-Topic: IETF does protocol design, not philosophy Thread-Index: Ac+KMRfZkiYSsFoRTxWsnSg8DJ8OfAASI0YAAENTmyA= Date: Thu, 19 Jun 2014 08:37:56 +0000 Message-ID: References: <02612d1be78948ed8735770116a558e1@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(33646001)(85306003)(15975445006)(54356999)(50986999)(76176999)(83072002)(83322001)(105586002)(74662001)(64706001)(74502001)(99396002)(99286002)(80022001)(85852003)(74316001)(66066001)(95666004)(31966008)(20776003)(81342001)(19580395003)(79102001)(76576001)(86362001)(2656002)(81542001)(2171001)(87936001)(4396001)(92566001)(77982001)(76482001)(551934003)(46102001)(101416001)(15202345003)(21056001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/BMMXT_b7l-JPExf6zzN1D8Gn4Lo Cc: "urn@ietf.org" Subject: Re: [urn] IETF does protocol design, not philosophy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 08:38:01 -0000 > Perhaps your note illustrates another part of the disconnect we > are having in the URN space. =20 I meant it too. > Some of the intended/desired uses > are precisely not in an [Internet] protocol context. =20 I meant "protocol" in the broad sense. I can't think of any use cases that do not involve protocols. UR*'s are strings to be used in protocols, and any use that doesn't involve a communication is out of scope: for discussion of UR* uses, for this working group, for the IETF.=20 > Even of > those that are, many do not follow your "A ------- UR* ---> B" > model because the URNs are used as indicators, not retrieval > indicators of some sort (most, but not all, uses with "HTML, HTTP, XMPP, DNS or whatever" are for retrieval elements, but some, including ones that Peter has identified for XMPP and several recent I-Ds, are not). =20 I think the 'indicator' vs. 'for retrieval' distinction is not about the UR* but about the context of use, not the UR* itself. This is a key point: you can use a 'http:' URI both 'as indicator' and 'for retrieval', and also you can use a 'urn:' URI for both. However, as a matter of implementation, Using 'urn:' URIs for retrieval doesn't work so well. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Let me try to explain in words what I meant by A -- UR* --> B. Alice and Bob are communicating. Somehow. All communication involves a communication protocol. Protocols are simple or complex, are layered and modularized. HTTP is a protocol, but English is a protocol, "the web" is a protocol. Speaking broadly. In the English email protocol which I am using now, English words and punctuation and UR*s are used as protocol elements. As part of Alice communicating with Bob, Alice might include a UR*, embedded in "English email" or HTML or XMPP or XML, and you want to ask about the meaning of that UR*. Does it indicate, is it intended for retrieval, does Alice want Bob to try to retrieve whatever 'fetch'ing the UR* and understand something because of whatever Bob gets? My point is that the answer is the same whether the context is English email or HTML or any other protocol: no one can know for certain what Alice intended by the UR*, the ambiguity is intrinsic, no amount of words in RFCs will change that. If there is to be any disambiguation, it has to be carried out of band or elsewhere in the protocol. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > In particular, Alice may want > to inquire whether a URN with a particular NID and NSS exists in > some data structure or transaction and then take an action on > that basis that is indicated by the URN but that has nothing to > do with communicating the URN to Bob or otherwise executing or > resolving it. I don't understand. How did Alice get the URN? And how did the creator of the data structure or transaction get the URN? =20 I'd say that if there is no communication path that passes the UR* as an opaque string, then you don't have a URI or URL or URN, you just have a string that looks like one and we have nothing to say because it doesn't matter what we say. > In retrospect, perhaps we would have been better off had we > avoided the generic URI idea entirely, preferring a wide variety > of URLs -- all intended for use in contexts that fit your model > and then invented a Universal Digital Indicator or Universal > Digital Flag that would have entirely different properties. Disagree. To repeat: the nature of the context of use (such as indicate vs. for retrieval) is orthogonal the nature of the UR* scheme (http: or uuid:) or scheme type (urn or UDI Or UDF). =20 > But > we didn't go in that direction and it looks to me, right now, as > if there is no practical way to get back there without even more > damage. Mumble about 'back there' (were we ever there) and 'damage'=20 (implies harm). > One of Martin's recent notes in another thread seems to me to be > another aspect of the same problem. For URLs, the "HTTP GET" > and "HTTP HEAD" requests -- same object with different verbs -- > is a useful distinction If a protocol uses a method along with a URL that's fine, but most schemes other than http:/https: don't have much=20 To say about HEAD.=20 > and no further distinctions are needed > among the URL that locates (or describes) the object.=20 The IANA registry of link types is proof that many feel more distinctions are needed.=20 > From a > variation on that perspective, the URN issue is that, at a > slightly higher level of abstraction ("name" versus "location"), > there is a desire to be able to incorporate that distinction > into the identifying string itself, Desire is too weak a design rationale; you can't always get what you want. Because the distinction applies to the=20 context of use, incorporating the distinction in the identifying string itself isn't possible. > not somehow know that > anything that can be the target of a URL can be fully retrieved > with GET or have some specific metadata retrieved with HEAD. "somehow know" =3D by context. >From my point of view, we haven't been completely consistent > about that distinction even with URLs: we say > GET > in HTTP to fetch the whole object > HEAD > to fetch a certain type of metadata, but, if we want only a > section or material after a starting point, we say=20 > GET > and then apply a fragment identifier to the result. That > operation could have been defined differently, e.g., by saying=20 > GET frag=3D > or, for improved backwards compatibility and error messages, > GETPARTIAL frag=3D > to push the extraction job onto the server/ resolution mechanism. Fragment identifiers are much more complicated. http://www.w3.org/2001/tag/doc/mimeTypesAndFragids and ultimately have very little to do with fragments as chunks or components (you're thinking range retrieval) and are more like "highlight" or "view". > As with URLs versus a hypothetical UDI or UDF, one can argue > endlessly about whether a model in which pure indicators (or > information that designates different types of action loci and > instructions for them are necessary). I imagine we will never > agree about that. =20 Barking up the wrong tree, endlessly. =20 > But that, and part of Dale's recent note=20 Getting past TL;DR: > (1) Stop this debate, suck it up as needed, try to elicit (real > or perceived) requirements, and design/modify the URN specs > accordingly. Only according to real requirements, not unsubstantiated ones, please. > (2) To the degree to which some people think this is the wrong > way to proceed (or that the communities who think they have > other requirements are wrong-headed),=20 We should avoid examining heads.=20 Real requirements can come from anywhere.=20 > I would hope that they > would start on an I-D that would explain the One True Path as > clearly and lucidly as possible, with the intent of publishing > that discussion as an informational that reflects their view of > the present and future RFC. Sounds like make-work. If there are real requirements, follow step (1). > WG product or an individual or independent submission is > probably less important than it be written... at least if this > debate about philosophy or perspective is actually important > rather than a delaying or obstructionist action. I'm trying to help here.=20 RFC5988 establishes a link type registry. http://www.iana.org/assignments/link-relations/link-relations.xhtml which seems like a great vehicle for those designing applications that need additional link categorizations. Is there a use case where that won't do? From nobody Thu Jun 19 07:58:03 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBCA1A026E for ; Thu, 19 Jun 2014 07:58:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 ICG_X6I7t678 for ; Thu, 19 Jun 2014 07:58:00 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id E9E881A01EE for ; Thu, 19 Jun 2014 07:57:59 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta15.westchester.pa.mail.comcast.net with comcast id GC6F1o0011ZXKqc5FExzn3; Thu, 19 Jun 2014 14:57:59 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.westchester.pa.mail.comcast.net with comcast id GExy1o0151KKtkw3hExzRJ; Thu, 19 Jun 2014 14:57:59 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s5JEvwb9026297; Thu, 19 Jun 2014 10:57:58 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s5JEvwfv026296; Thu, 19 Jun 2014 10:57:58 -0400 Date: Thu, 19 Jun 2014 10:57:58 -0400 Message-Id: <201406191457.s5JEvwfv026296@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Juha Hakala In-reply-to: <53A29849.4050006@helsinki.fi> (juha.hakala@helsinki.fi) References: <2461.1400713811@sandelman.ca> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EFA445BC22@dnbf-ex1.AD.DDB.DE> <201406172036.s5HKaWrG014406@hobgoblin.ariadne.com> <53A14B2E.4090100@helsinki.fi> <201406181815.s5IIF6di006163@hobgoblin.ariadne.com> <53A29849.4050006@helsinki.fi> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403189879; bh=LpPh2w7bo0lS8mow46LYL/mtSI7m+jR5HFdf9jXyrvI=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=WT5sfKw1uo1UCPu1fX6Do6RaAJackzh1meNKwF1vDHWRbCCGSCHq8F1XmeTUOUK0b cv6cmccGyJG7XHaiR3BrLkpm6XWr9eXifZUvHcSYYYdVFdA8GDa2HrQQ3wWBXxG3mw YhcE1ujcsAuc14TWX0pSh9dHC+wa1X7S1xUl8jamuxpzypjPgeuHc04YLiBRAIWdP8 B6TIz7BpsH+fKP/+k5S9RA5G017Ca3ppocZXYBjmluUoyJdUqZZPhiVhOJ6NuX/wJI HgtNd0BrHi8A6GZlOXk6SQruPyz7IpfUiRei4RLtF2ou+NdTQrnyktvBy/RnlGdx0V oJOUSFBoS5H4Q== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tC8XcmB5Qdl4v_PNik3sMmsq9Es Cc: urn@ietf.org Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 14:58:01 -0000 > From: Juha Hakala > Fragments are ignored when URNs are resolved so they should cause no > problems whatsoever. Strictly speaking, current code to validate URIs could check to see if the scheme is "urn", and if so, verify that no "#" is present, as the current definition does not allow fragments for URNs. But in practice, I don't expect any code to do this. > Also, if any Unicode character can be used in > the identifier itself (as in Handles, for instance) it is not possible > to reserve some characters to this kind of special usage. It's quite easy to reserve characters: If the special character "represents itself", that is, is in the underlying Handle identifier, it must be represented in the URN as a %-escape. If the special character is used with the special meaning, it must be written explicitly as "#" or "?". This is done in numerous places in URIs already. > Like URNs, DOIs are usually expressed as URIs, with the address of the > resolver / proxy included. In my experience, what DOIs I've seen are usually represented directly as DOIs. So DOIs are gaining some currency as identifiers themselves. > DOI and ARK systems are already developing ways of using query in their > own, non-interoperable ways to pass resolution related guidelines to > resolvers. If IETF can a) agree that query can officially be used for > this purpose, and b) provide a means, such as IANA registry, for > registering resolution services and service related parameters, the > groups developing persistent identifiers may still be able to avoid > re-inventing too many wheels. It sounds to me like more IETF work is needed than just that: We want to specify what the contents of the query component are and how they are to be interpreted and used. There will need to be a registry for parameters (sub-values within query), but there will need to be more extensive definitions of semantics and procedures if there is to be any uniformity of resolution services. Dale From nobody Mon Jun 23 00:21:41 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582D41B29CC for ; Mon, 23 Jun 2014 00:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 kleMqgaGih0S for ; Mon, 23 Jun 2014 00:21:36 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (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 EF7511A0564 for ; Mon, 23 Jun 2014 00:21:34 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s5N7LInL030570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Jun 2014 10:21:20 +0300 Message-ID: <53A7D56C.909@helsinki.fi> Date: Mon, 23 Jun 2014 10:21:16 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dale R. Worley" References: <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EFA445BC22@dnbf-ex1.AD.DDB.DE> <201406172036.s5HKaWrG014406@hobgoblin.ariadne.com> <53A14B2E.4090100@helsinki.fi> <201406181815.s5IIF6di006163@hobgoblin.ariadne.com> <53A29849.4050006@helsinki.fi> <201406191457.s5JEvwfv026296@hobgoblin.ariadne! .com> In-Reply-To: <201406191457.s5JEvwfv026296@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/GV1x1CvaXDAr_p4sN41gcbPYVa0 Cc: urn@ietf.org Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 07:21:39 -0000 Hello, On 19.6.2014 17:57, Dale R. Worley wrote: >> From: Juha Hakala >> Fragments are ignored when URNs are resolved so they should cause no >> problems whatsoever. > Strictly speaking, current code to validate URIs could check to see if > the scheme is "urn", and if so, verify that no "#" is present, as the > current definition does not allow fragments for URNs. But in > practice, I don't expect any code to do this. Clients such as web browsers should not even send URI fragments to servers such as URN resolvers. Since fragment has zero impact on how the URN is resolved, disallowing fragments from URNs on the client side would not make much sense. We have discussed earlier on this list about the applicability of fragments in the URN context. If and only if a URN identifies a single digital manifestation of a resource (such as a PDF file) users can apply URI fragment any time after the resource has been identified and the identifier has been made actionable, provided that the MIME type of that file format supports the use of fragment. In such a case it is likely that the URN + fragment will be more persistent than URL + fragment. > >> Also, if any Unicode character can be used in >> the identifier itself (as in Handles, for instance) it is not possible >> to reserve some characters to this kind of special usage. > It's quite easy to reserve characters: If the special character > "represents itself", that is, is in the underlying Handle identifier, > it must be represented in the URN as a %-escape. If the special > character is used with the special meaning, it must be written > explicitly as "#" or "?". This is done in numerous places in URIs > already. OK. For the time being, bibliographic identifier standards do not have annexes explaining how to make them actionable in the Internet. If and when this is done, it is necessary to investigate whether percent-escaping is needed, and if so, explain how to do it. > > >> DOI and ARK systems are already developing ways of using query in their >> own, non-interoperable ways to pass resolution related guidelines to >> resolvers. If IETF can a) agree that query can officially be used for >> this purpose, and b) provide a means, such as IANA registry, for >> registering resolution services and service related parameters, the >> groups developing persistent identifiers may still be able to avoid >> re-inventing too many wheels. > It sounds to me like more IETF work is needed than just that: We want > to specify what the contents of the query component are and how they > are to be interpreted and used. There will need to be a registry for > parameters (sub-values within query), but there will need to be more > extensive definitions of semantics and procedures if there is to be > any uniformity of resolution services. It was my assumption that the contents of the query component and guidelines on query usage will be included in the registry and to large extent supplied by the communities using persistent identifiers. As long as the technologies libraries, archives, museums, publishers etc. are using to manage digital resources are changing fast - and I expect technological change will continue for a long time - resolution services and information about them will be constantly changing. For instance, a service like URI to URC (which provides metadata about the resource) requires a revision whenever - a new metadata format is introduced, or - an existing metadata format is revised, or - a new search & retrieve protocol is introduced, or - an existing search & retrieve protocol is updated. IETF shall, I hope, provide a technical platform needed for maintaining query related documentation. But I am not sure if the actual maintenance work needs to / should be done in IETF. And if URNbis WG cannot agree on how to use URI fragment and query in the URN context, then it might happen that none of this work takes place under the IETF wing. All persistent identifier communities are facing the challenge of how to make the resolvers smart, and how to share the information about the resolver capabilities in machine understandable form. To some extent, the standardization work needed has already been done by IETF or other standard bodies. For instance, SRU protocol has Explain operation via which it is possible to retrieve a description of facilities available at an SRU server (see http://www.loc.gov/standards/sru/explain/). Explain may be used by URN resolvers to find out what SRU servers can do (in order to facilitate provision of URI to URC and other URN resolution services) but URN resolvers could also use SRU Explain to inform each other about the functionality they provide (such as URN namespaces and resolution services supported). Juha > > Dale -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Mon Jun 23 22:16:23 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91BF1B282B for ; Mon, 23 Jun 2014 22:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 pomloPVwvMl0 for ; Mon, 23 Jun 2014 22:16:18 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A7E1B27D0 for ; Mon, 23 Jun 2014 22:16:18 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WzJ32-000Dz4-Lu; Tue, 24 Jun 2014 01:13:36 -0400 Date: Tue, 24 Jun 2014 01:16:06 -0400 From: John C Klensin To: Juha Hakala , "Dale R. Worley" Message-ID: <38E6C8975A8F03A10C0BF773@JcK-HP8200.jck.com> In-Reply-To: <53A7D56C.909@helsinki.fi> References: <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com> <24637769D123E644A105A0AF0E1F92EFA444A63C@dnbf-ex1.AD.DDB.DE> <466690F1671AA4E6EADCB59E@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EFA445BC22@dnbf-ex1.AD.DDB.DE> <201406172036.s5HKaWrG014406@hobgoblin.ariadne.com> <53A14B2E.4090100@helsinki.fi> <201406181815.s5IIF6di006163@hobgoblin.ariadne.com> <53A29849.4050006@helsinki.fi> <201406191457.s5JEvwfv026296@hobgoblin.ariadne! .com> <53A7D56C.909@helsinki.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/qDcXz7TqTL2KjQz9o8wJ06W4MHU Cc: urn@ietf.org Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 05:16:21 -0000 Juha and Dale, A couple of observations which I hope don't get in our way in the near term. --On Monday, June 23, 2014 10:21 +0300 Juha Hakala wrote: > Hello, > > On 19.6.2014 17:57, Dale R. Worley wrote: >>> From: Juha Hakala >>> Fragments are ignored when URNs are resolved so they should >>> cause no problems whatsoever. >> Strictly speaking, current code to validate URIs could check >> to see if the scheme is "urn", and if so, verify that no "#" >> is present, as the current definition does not allow >> fragments for URNs. But in practice, I don't expect any code >> to do this. > > Clients such as web browsers should not even send URI > fragments to servers such as URN resolvers. Since fragment has > zero impact on how the URN is resolved, disallowing fragments > from URNs on the client side would not make much sense. We get all tangled up with the robustness principle here, but my reading of the "reserved" language in 2141 is that any client or system that uses a URN with a fragment is non-conformant to that spec. Speculating about what other systems should or should not do with such things is far outside the specification and hence, from a conformance standpoint, meaningless. > We have discussed earlier on this list about the applicability > of fragments in the URN context. If and only if a URN > identifies a single digital manifestation of a resource (such > as a PDF file) users can apply URI fragment any time after the > resource has been identified and the identifier has been made > actionable, provided that the MIME type of that file format > supports the use of fragment. In such a case it is likely that > the URN + fragment will be more persistent than URL + fragment. That may be true, but it is also tied up with the reason I've been skeptical about the association of "fragment" --even approximately as defined for URLs and generic URIs-- to URNs at all. With the understanding that I'm not going to try to suggest anything resembling syntax or delimiters at this point (it seems to me that agreement to the "URNs are not URI's" spec or equivalent is prerequisite to such a proposal or even having such a discussion), it seems to me that a generic URN string (not URI) is going to be, conceptually "URN" NID NSS [ServiceRequests...] It will ultimately make a difference whether "a URN" is the complete URN string as above or just urn:NID:NSS or, put differently, whether the ServiceRequests are part of the NSS. But it makes less difference in the near term than out trying to make general URIs work for URNs would suggest. In the above, a ServiceRequest is, again conceptually, a tuple of ServiceType ComparisonIndicator ServiceTarget ReequestParameters... ServiceType is nominally some sort of keyword. ComparisonIndicator tells something trying to compare a pair of URNs for identity whether that particular ServiceRequest counts or should be ignored. ServiceTarget identifies where the ServiceRequest is to be sent and, depending on the ServiceType, may be a keyword indicator or, at the risk of descending into recursion hell, a URL or URN. And RequestParameters are anything the ServiceType definition says they are. where any of those may be - defined in the NID registration and omitted from (prohibited in) the URN string - allowed by the NID registration but explicitly included in the URN string - defined in the NID registration as a default but allowed in the URN string as an override. - prohibited entirely by the NID registration (effectively duplicating the "don't do that" rule of 2141 on a per-NID basis) Presumably the NID registration also gets to say whether anything not required is prohibited, and the other variations on that theme. Requests/specificaions for location information, assorted metadata, or model or actual objects themselves are then just specialized ServiceRequests. In particular, "Fragment" disappears as a special type of syntax and reappears as a Service Request that is applicable to some NIDs and not others and whose meaning and action (and how it is "resolved") are specified on an NID basis and as above. "Query" disappears too, not because it (or the syntax) are necessarily problematic but because the term itself is misleading for many possible types of ServiceRequests and therefore causes more confusion than it clears up. >>> Also, if any Unicode character can be used in >>> the identifier itself (as in Handles, for instance) it is >>> not possible to reserve some characters to this kind of >>> special usage. >> It's quite easy to reserve characters: If the special >> character "represents itself", that is, is in the underlying >> Handle identifier, it must be represented in the URN as a >> %-escape. If the special character is used with the special >> meaning, it must be written explicitly as "#" or "?". This >> is done in numerous places in URIs already. > > OK. For the time being, bibliographic identifier standards do > not have annexes explaining how to make them actionable in the > Internet. If and when this is done, it is necessary to > investigate whether percent-escaping is needed, and if so, > explain how to do it. I don't think Dale's comment and Juha's response have much to do with each other. More generally, as a long-term, and much-wounded combatant in the i18n wars, I strongly recommend that, if we separate URNs from the legacy problems of the generic URI syntax, we take advantage of that to clean something up, starting by separating "reserved character" from i18n issues and creasing only one escape model that is prohibited except where it is required and used as little as possible. Specifically: - An NID registration specifies whether non-ASCII characters are allowed (the default, deriving from 2141, etc., is "no"). - If they are not allowed, then they are not allowed, escaped or otherwise. - If they are allowed, the registration must specify what is allowed and how they are interpreted, preferably by normative reference to some other spec (e.g., IDNA U-labels, Unicode Identifiers, W3C CharMod-based specifications, PRECIS types) and, except in the most exceptional of per-NID circumstances, they appear as themselves, not escapes and certainly not as escaped UTF-8 octets. - If actual reserved characters are required to be used in their non-reserved sense, they are quoted, not reduced to error-prone numeric gibberish. Just my opinion, of course, but I note that the above appears to me to be completely consistent with the balance of Juha's note. best, john From nobody Wed Jun 25 06:41:01 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE031B2CA5 for ; Wed, 25 Jun 2014 06:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 2Y8K9eyNMGX5 for ; Wed, 25 Jun 2014 06:40:56 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id E51521B2C9E for ; Wed, 25 Jun 2014 06:40:55 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 14AF47EF34; Wed, 25 Jun 2014 15:40:53 +0200 (CEST) From: "Svensson, Lars" To: Larry Masinter , John C Klensin , "Dale R. Worley" , =?Windows-1252?Q?Martin_J=2E_D=FCrst?= Thread-Topic: RE: IETF does protocol design, not philosophy Thread-Index: Ac+QewoGNASAjxrCRXyJB3v4Nyx7Gg== Date: Wed, 25 Jun 2014 13:40:52 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA445E4C5@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.245] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/RziKnRytwqjHXHsF4igs8eI8uSk Cc: "urn@ietf.org" Subject: Re: [urn] IETF does protocol design, not philosophy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 13:40:59 -0000 On June 19, 2014, Larry Masinter wrote: > > Some of the intended/desired uses > > are precisely not in an [Internet] protocol context. >=20 > I meant "protocol" in the broad sense. I can't think of > any use cases that do not involve protocols. UR*'s > are strings to be used in protocols, and any use > that doesn't involve a communication is out of scope: > for discussion of UR* uses, for this working group, for > the IETF. >=20 > > Even of > > those that are, many do not follow your "A ------- UR* ---> B" > > model because the URNs are used as indicators, not retrieval > > indicators of some sort (most, but not all, uses with "HTML, > > HTTP, XMPP, DNS or whatever" are for retrieval elements, but > > some, including ones that Peter has identified for XMPP and > > several recent I-Ds, are not). >=20 > I think the 'indicator' vs. 'for retrieval' distinction is not > about the UR* but about the context of use, not the UR* > itself. This is a key point: you can use a 'http:' URI both > 'as indicator' and 'for retrieval', and also you can use > a 'urn:' URI for both. However, as a matter of implementation, > Using 'urn:' URIs for retrieval doesn't work so well. My reading of this is that a URI (in the sense of a string conforming to th= e URI syntax as specified in RFC 3986 *and* using one of the registered URI= schemes [1]) can be used as both an 'indicator' and 'for retrieval', but t= hat you say that if you cannot use it 'for retrieval', it should be out of = scope for IETF. Have I understood that correctly? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Let me try to explain in words what I meant by > A -- UR* --> B. >=20 > Alice and Bob are communicating. Somehow. All communication > involves a communication protocol. Protocols are simple or complex, > are layered and modularized. HTTP is a protocol, but English is > a protocol, "the web" is a protocol. Speaking broadly. >=20 > In the English email protocol which I am using now, English > words and punctuation and UR*s are used as protocol > elements. >=20 > As part of Alice communicating with Bob, Alice might include > a UR*, embedded in "English email" or HTML or XMPP or XML, > and you want to ask about the meaning of that UR*. > Does it indicate, is it intended for retrieval, does Alice want > Bob to try to retrieve whatever 'fetch'ing the UR* and understand > something because of whatever Bob gets? >=20 > My point is that the answer is the same whether the context > is English email or HTML or any other protocol: no one can > know for certain what Alice intended by the UR*, the > ambiguity is intrinsic, no amount of words in RFCs will > change that. If there is to be any disambiguation, it has > to be carried out of band or elsewhere in the protocol. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D But there are plenty of examples of registered URI schemes that are not spe= cifying resolution or usage in protocols. Some examples: 1) geo: (RFC 5870) explicitly says that=20 Data contained in a 'geo' URI identifies a physical resource: a spatial location identified by the geographic coordinates and the CRS encoded in the URI. (=A73.4) and As many other URI scheme definitions, the 'geo' URI provides resource identification independent of a specific application or protocol. Examples of potential protocol mappings and use cases can be found in Section 6. (=A73.6) So this is even protocol-independent. 2) xcon: (RFC 6501) An XCON-URI is not designed to be resolved, and an application MUST NOT attempt to perform a standard DNS lookup on the host portion of such a URI in an attempt to discover an IP address or port at which to connect. (=A73.3.1) 3) data: (RFC 2397) You could say that this is about packaging content transported through a sp= ecific protocol, but it neither about identification, nor about location. 4) crid: (RFC 4078) As addressed in [TVA-CR], the CRID is ultimately resolved either directly by the CRID authority or by another party. If another party is providing resolution, the ability to resolve the CRID requires the flow of some information from the authority to the resolution provider, in order to tie the CRID to its resolution. Examples of relationships between CRID authors and the suppliers of resolution information are given in [TVA-Sys]. As described in [TVA-CR], there will in all likelihood be more than one CRID that can resolve directly or indirectly to a given single locator at a given time. (=A76.3) To me, this seems very similar to the URN scenario, where the resolution pr= otocol is not part of the UR* scheme, but we rely on external resolution se= rvices that may or may not be authoritative.=20 > > In particular, Alice may want > > to inquire whether a URN with a particular NID and NSS exists in > > some data structure or transaction and then take an action on > > that basis that is indicated by the URN but that has nothing to > > do with communicating the URN to Bob or otherwise executing or > > resolving it. >=20 > I don't understand. How did Alice get the URN? And how > did the creator of the data structure or transaction > get the URN? A colleague of hers sent her an email with an attachment. The attachment tu= rned out to be a document and on the first page of that document a URN iden= tifying that document was printed. > I'd say that if there is no communication path that passes > the UR* as an opaque string, then you don't have a URI or > URL or URN, you just have a string that looks like one and > we have nothing to say because it doesn't matter what > we say. Of course we cannot know if urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 a= ctually is a URN, but since it starts with urn:, a qualified guess would be= that it is one and a user with knowledge of that would try to use it as su= ch. > > In retrospect, perhaps we would have been better off had we > > avoided the generic URI idea entirely, preferring a wide variety > > of URLs -- all intended for use in contexts that fit your model > > and then invented a Universal Digital Indicator or Universal > > Digital Flag that would have entirely different properties. >=20 > Disagree. To repeat: the nature of the context of use > (such as indicate vs. for retrieval) is orthogonal the > nature of the UR* scheme (http: or uuid:) or scheme type > (urn or UDI Or UDF). +1 > RFC5988 establishes a link type registry. > http://www.iana.org/assignments/link-relations/link-relations.xhtml >=20 > which seems like a great vehicle for those designing > applications that need additional link categorizations. > Is there a use case where that won't do? Can you please elaborate a bit on which part the link types would play in a= URN resolution scenario? I admit I don't quite grasp that... Best, Lars From nobody Wed Jun 25 07:09:32 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F971B2CB0 for ; Wed, 25 Jun 2014 07:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 o3mLDTUPH21V for ; Wed, 25 Jun 2014 07:09:24 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id DBEF01B2CBF for ; Wed, 25 Jun 2014 07:09:23 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 453697F010; Wed, 25 Jun 2014 16:09:23 +0200 (CEST) From: "Svensson, Lars" To: John C Klensin , Juha Hakala , "Dale R. Worley" Thread-Topic: Re: [urn] urn:ietf:rfc Thread-Index: Ac+Qfw4Z2TMRg/HuRoiaOIVMXKf3zA== Date: Wed, 25 Jun 2014 14:09:22 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA445E513@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.245] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1oqspLWjoGNth3e5bPfFCanrmFc Cc: "urn@ietf.org" Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 14:09:30 -0000 John, [...] > > We have discussed earlier on this list about the applicability > > of fragments in the URN context. If and only if a URN > > identifies a single digital manifestation of a resource (such > > as a PDF file) users can apply URI fragment any time after the > > resource has been identified and the identifier has been made > > actionable, provided that the MIME type of that file format > > supports the use of fragment. In such a case it is likely that > > the URN + fragment will be more persistent than URL + fragment. >=20 > That may be true, but it is also tied up with the reason I've > been skeptical about the association of "fragment" --even > approximately as defined for URLs and generic URIs-- to URNs at > all. Having looked at the Best Practices for Fragment Identifiers [1] (which I w= asn't aware of) the task is really daunting. *If* we can talk about FIs in = the context of URNs at all, it has to be as "semantic fragid structures". > With the understanding that I'm not going to try to suggest > anything resembling syntax or delimiters at this point (it seems > to me that agreement to the "URNs are not URI's" spec or > equivalent is prerequisite to such a proposal or even having > such a discussion), it seems to me that a generic URN string > (not URI) is going to be, conceptually >=20 > "URN" NID NSS [ServiceRequests...] >=20 > It will ultimately make a difference whether "a URN" is the > complete URN string as above or just urn:NID:NSS or, put > differently, whether the ServiceRequests are part of the NSS. > But it makes less difference in the near term than out trying to > make general URIs work for URNs would suggest. >=20 > In the above, a ServiceRequest is, again conceptually, a tuple > of >=20 > ServiceType ComparisonIndicator ServiceTarget > ReequestParameters... >=20 > ServiceType is nominally some sort of keyword. > ComparisonIndicator tells something trying to compare a pair of > URNs for identity whether that particular ServiceRequest counts > or should be ignored. ServiceTarget identifies where the > ServiceRequest is to be sent and, depending on the ServiceType, > may be a keyword indicator or, at the risk of descending into > recursion hell, a URL or URN. And RequestParameters are > anything the ServiceType definition says they are. >=20 [...] >=20 > Requests/specificaions for location information, assorted > metadata, or model or actual objects themselves are then just > specialized ServiceRequests. In particular, "Fragment" > disappears as a special type of syntax and reappears as a > Service Request that is applicable to some NIDs and not others > and whose meaning and action (and how it is "resolved") are > specified on an NID basis and as above. "Query" disappears too, > not because it (or the syntax) are necessarily problematic but > because the term itself is misleading for many possible types of > ServiceRequests and therefore causes more confusion than it > clears up. Apart from the name "query", do you think this could be done using the URI = query syntax? [1] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids Best, Lars From nobody Wed Jun 25 07:24:47 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27C31B2CC1 for ; Wed, 25 Jun 2014 07:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 TT8wJBozMfc3 for ; Wed, 25 Jun 2014 07:24:38 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id D8FCA1B2CB8 for ; Wed, 25 Jun 2014 07:24:37 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 48BA87F2A1; Wed, 25 Jun 2014 16:24:37 +0200 (CEST) From: "Svensson, Lars" To: Juha Hakala , "urn@ietf.org" , "John C Klensin" Thread-Topic: Re: [urn] Tuning the "URNs are not URIs" spec Thread-Index: Ac+QgS2sjzZEmAJ3S9STbSNq9cJmCQ== Date: Wed, 25 Jun 2014 14:24:36 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA445E54B@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.245] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FmUuCduRcTB3_8NsvdCzApX4dxM Subject: Re: [urn] Tuning the "URNs are not URIs" spec X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 14:24:43 -0000 All, > >> Instead, the question is whether the IETF is willing to > >> evolve and adapt the URN definition to accommodate those > >> perceived needs or whether if prefers to have that work > >> done elsewhere, either by adoption in the broader > >> community and marketplace of a different approach or, > >> potentially, even a competing URN standard. > > As far as I can tell, the key question is "Is the syntax of RFC 2141 > > ("URN syntax") inadequate for the needs of important groups of users?" > Urnbis charter requires (among other things) the WG to make >=20 > > an update of the formal syntax specification in the light of the > > URI Standard (STD 66, RFC 3986) using the ABNF from STD 68 > > (RFC 5234) >=20 > In practice, two major changes are needed: revised URN syntax should > allow the use of fragment and query. >=20 > The use of URI fragment to indicate locations within identified > resources enables creation of URN-based citations instead of URL-based > ones. But in order to avoid breaking the assignment rules of traditional > standard identifiers, RFC2141bis must make it clear that the fragment is > not part of the namespace specific string (that is, from URN point of > view, it does not identify anything). Isn't this a question if we look at the fragment from a generic URI point o= f view or specifically as a URN? As an example (looking at http:): >From a generic URI point of view the strings http://example.org/ and http:/= /example.org:80/ are different resources. The http specification says that = for comparison resources the port is to be ignored if it is 80, so under ht= tp semantics those are equivalent (identify the same resources). Since comp= arison should always be about avoiding false positives, that is OK. Could i= t be an option to state in the URN syntax, that when comparing for equivale= nce, the fragment identifier can be ignored? That said, I don't know if the commitment from the urn:nbn community to ens= ure that fragment identifiers will always work is enough to have them added= to the generic URN syntax. > > If that actually is so, it is a fairly concrete fact, it shouldn't be > > very difficult to make the case in a convincing way. And once the > > case is made, it would be a sound reason to move ahead with > > significant changes to the status quo. >=20 > The problem is that what looks convincing to e.g. library community - > and we are not the only significant group out here which is using > persistent identifiers - may not convince other groups which have > different requirements and applications. If there is no need to preserve > millions of documents for hundreds of years, even cool URIs may look > like a sufficient solution. So it seems that there are different requirements for different URN namespa= ces. One further reason to keep identification (common area) and resolution= /services separate. Best, Lars From nobody Wed Jun 25 23:00:10 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6C71B2AC7 for ; Wed, 25 Jun 2014 23:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 jKbKS-CMuMME for ; Wed, 25 Jun 2014 23:00:05 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (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 691941B2AB9 for ; Wed, 25 Jun 2014 23:00:03 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s5Q5xwTK032431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 26 Jun 2014 08:59:59 +0300 Message-ID: <53ABB6DC.7000907@helsinki.fi> Date: Thu, 26 Jun 2014 08:59:56 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Svensson, Lars" , "urn@ietf.org" , John C Klensin References: <24637769D123E644A105A0AF0E1F92EFA445E54B@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA445E54B@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/OFaiGrKxjr_i75lzxeftvvdI8Aw Subject: Re: [urn] Tuning the "URNs are not URIs" spec X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 06:00:08 -0000 Hello, On 25.6.2014 17:24, Svensson, Lars wrote: > All, > >>>> >>>> >>>> From a generic URI point of view the strings http://example.org/ and http://example.org:80/ are different resources. The http specification says that for comparison resources the port is to be ignored if it is 80, so under http semantics those are equivalent (identify the same resources). Since comparison should always be about avoiding false positives, that is OK. Could it be an option to state in the URN syntax, that when comparing for equivalence, the fragment identifier can be ignored? Two URNs should be considered to be equivalent if they identify the same thing. Therefore the latest version of RFC2141bis says that > If a query component, fragment identifier component, or both have > been appended to the assigned URN, they MUST be ignored for purposes > of determining equivalence. ...because neither fragment nor query are part of the NSS. > > That said, I don't know if the commitment from the urn:nbn community to ensure that fragment identifiers will always work is enough to have them added to the generic URN syntax. From the URN point of view fragments have nothing to do with identification. National libraries and our allies assign urn:nbns to resources, but typically it will be the users of these resources who will add fragments to the urns when they cite identified resources. It is unfortunate that URI generic syntax talks about fragment identifiers. We should not do the same mistake, since it is very unclear what fragments could actually identify and how such fragment-driven identification process would be managed properly. A lay person may not see any problems here, but in this respect my point of view is one of a professional who has been closely involved with development and use of ISO identifier standards for about 20 years. Generally speaking, fragments can be added to URNs which identify just a single manifestation of a resource and the mime type of the resource allows fragment usage. There are plenty of namespaces and mime types which meet these requirement. The requirement for being able to use fragment does not really come only from the urn:nbn community. Adding fragment to the URN syntax has more to do with the needs of the people who will cite resources which have already been identified with URNs which then provide access to these resources. IMO people will add fragments to URNs no matter what the URN syntax says. But if the URN syntax says nothing about fragments, then URI syntax applies, which means that everyone who cites a resource identifies something (location or segment or something else) within that resource by the act of citing, which sounds absurd (and unmanageable) to me. Juha > >>> If that actually is so, it is a fairly concrete fact, it shouldn't be >>> very difficult to make the case in a convincing way. And once the >>> case is made, it would be a sound reason to move ahead with >>> significant changes to the status quo. >> The problem is that what looks convincing to e.g. library community - >> and we are not the only significant group out here which is using >> persistent identifiers - may not convince other groups which have >> different requirements and applications. If there is no need to preserve >> millions of documents for hundreds of years, even cool URIs may look >> like a sufficient solution. > So it seems that there are different requirements for different URN namespaces. One further reason to keep identification (common area) and resolution/services separate. > > Best, > > Lars -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Thu Jun 26 01:22:28 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93551B2AF1 for ; Thu, 26 Jun 2014 01:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 mAPqCuj5CtZm for ; Thu, 26 Jun 2014 01:22:19 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (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 2A4841B2CF8 for ; Thu, 26 Jun 2014 01:22:15 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s5Q8M0rA017504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 26 Jun 2014 11:22:01 +0300 Message-ID: <53ABD826.20606@helsinki.fi> Date: Thu, 26 Jun 2014 11:21:58 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Svensson, Lars" , John C Klensin , "Dale R. Worley" References: <24637769D123E644A105A0AF0E1F92EFA445E513@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA445E513@dnbf-ex1.AD.DDB.DE> Content-Type: multipart/alternative; boundary="------------050803060606080703010603" Archived-At: http://mailarchive.ietf.org/arch/msg/urn/6RYznZVTwWZ9NyZ8xB8NwFSqT_E Cc: "urn@ietf.org" Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 08:22:25 -0000 This is a multi-part message in MIME format. --------------050803060606080703010603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello, On 25.6.2014 17:09, Svensson, Lars wrote: > John, > > [...] >>> We have discussed earlier on this list about the applicability >>> of fragments in the URN context. If and only if a URN >>> identifies a single digital manifestation of a resource (such >>> as a PDF file) users can apply URI fragment any time after the >>> resource has been identified and the identifier has been made >>> actionable, provided that the MIME type of that file format >>> supports the use of fragment. In such a case it is likely that >>> the URN + fragment will be more persistent than URL + fragment. >> That may be true, but it is also tied up with the reason I've >> been skeptical about the association of "fragment" --even >> approximately as defined for URLs and generic URIs-- to URNs at >> all. > Having looked at the Best Practices for Fragment Identifiers [1] (which I wasn't aware of) the task is really daunting. *If* we can talk about FIs in the context of URNs at all, it has to be as "semantic fragid structures". Insisting that fragments identify something makes this best practices document more complicated than it needs to be. It would be easier to write a text with the title "Best practices for URI fragments and media type definitions". Even in [1] the author occasionally avoids the term identification. For instance on chapter C.5 URI http://example.org/potter#hermione just "means" the person named Hermione Granger, but does not "identify" her. When fragment was first introduced to the URI syntax it may have made sense to think of it as an identifier of something. But over the years novel usages have been invented, and the problems inherent in this approach have become more obvious. For instance, does |http://example.com/document.txt#match=[rR][fF][cC] identify words (every "RFC" and "rfc" within the document) or locations of these words within document.txt or something else? And if the base document changes so that there are no more matches, what does the fragment identify? Or, does |||http://example.com/document.txt#match=[J][U][H][A][H][A][K][A][L][A] identify me or just two words or something else? | Fragments can also be used for searching, using syntax |||#!s!search terms. So the fragment this URI || |||http://example.com/index.html#!s3!RFC would instruct the browser to search the third occurrence of the term RFC in the document. But does this fragment identify that particular word, or that location in the resource? ||Or, if the fragment is the MD5 checksum of a document, which fragment of the document is identified? | Technical issues aside, the key problem here is that fragment assignment is completely un-managed process, even more so than naming of files and creation of URLs. Anyone who sees identifier assignment as something controlled should a priori have major issue with the idea of "fragment identifier". There are a lot of reasons why fragments must not be part of the namespace specific strings. But I see no problem in allowing them in URNs, as long as we don't think of them as identifiers. I fully agree with [1] that "authors can use fragments within referenced URIs (that is, URLs and URNs) to address content on documents published by others" . > >> With the understanding that I'm not going to try to suggest >> anything resembling syntax or delimiters at this point (it seems >> to me that agreement to the "URNs are not URI's" spec or >> equivalent is prerequisite to such a proposal or even having >> such a discussion), it seems to me that a generic URN string >> (not URI) is going to be, conceptually >> >> "URN" NID NSS [ServiceRequests...] >> >> It will ultimately make a difference whether "a URN" is the >> complete URN string as above or just urn:NID:NSS or, put >> differently, whether the ServiceRequests are part of the NSS. Like URI queries, ServiceRequests must not be part of the NSS. Assigning an identifier to a resource is (ideally) a managed process, and identifiers themselves must never change. ServiceRequests are dependent on technical infrastructure which supports URN resolution, and may or may not be present on URNs to be resolved. >> But it makes less difference in the near term than out trying to >> make general URIs work for URNs would suggest. >> >> In the above, a ServiceRequest is, again conceptually, a tuple >> of >> >> ServiceType ComparisonIndicator ServiceTarget >> ReequestParameters... >> >> ServiceType is nominally some sort of keyword. OK. RFC 2483 defines a handful of these keywords and services, but not nearly enough. >> ComparisonIndicator tells something trying to compare a pair of >> URNs for identity whether that particular ServiceRequest counts >> or should be ignored. I am not sure I understand the need for ComparisonIndicator. >> ServiceTarget identifies where the >> ServiceRequest is to be sent and, depending on the ServiceType, >> may be a keyword indicator or, at the risk of descending into >> recursion hell, a URL or URN. Including ServiceTarget into ServiceRequest may not be necessary. URN resolver appropriate for the namespace in question should know which server is able to cater for ServiceRequests of given type. For instance, if a user wants full metadata about an academid dissertation, the resolver "knows" that the national bibliography should be able to fulfill the request. But if the document itself is requested, open repository (using Fedora, DSpace or some other such application) is better choice. >> And RequestParameters are >> anything the ServiceType definition says they are. Yes, and the number of parameters required will vary a lot depending on the ServiceType. >> Requests/specificaions for location information, assorted >> metadata, or model or actual objects themselves are then just >> specialized ServiceRequests. In particular, "Fragment" >> disappears as a special type of syntax and reappears as a >> Service Request that is applicable to some NIDs and not others >> and whose meaning and action (and how it is "resolved") are >> specified on an NID basis and as above. "Query" disappears too, >> not because it (or the syntax) are necessarily problematic but >> because the term itself is misleading for many possible types of >> ServiceRequests and therefore causes more confusion than it >> clears up. I am not sure it is necessary / productive to make fragments reappear as ServiceRequest. As I see it, Service Requests are something that URN resolvers must deal with, whereas fragments will be processed by clients such as web browsers, both for URLs and URNs. At least for now I cannot see a need for a fragment-like Service Request, or understand properly what these services would be like. Using URI query for passing ServiceRequests looks like an attractive option with minimal technical overhead. Whether this kind of use of query would be confusing, and whether using some other mechanism would make things more clear I can't tell, before seeing more detailed proposal on how to proceed. Like Lars, I wonder if the intention is to drop just the word query, or the syntax as well. Juha > Apart from the name "query", do you think this could be done using the URI query syntax? > > [1] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids > > Best, > > Lars -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 --------------050803060606080703010603 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hello,

On 25.6.2014 17:09, Svensson, Lars wrote:
John,

[...]

We have discussed earlier on this list about the applicability
of fragments in the URN context. If and only if a URN
identifies a single digital manifestation of a resource (such
as a PDF file) users can apply URI fragment any time after the
resource has been identified and the identifier has been made
actionable, provided that the MIME type of that file format
supports the use of fragment. In such a case it is likely that
the URN + fragment will be more persistent than URL + fragment.

That may be true, but it is also tied up with the reason I've
been skeptical about the association of "fragment" --even
approximately as defined for URLs and generic URIs-- to URNs at
all.

Having looked at the Best Practices for Fragment Identifiers [1] (which I wasn't aware of) the task is really daunting. *If* we can talk about FIs in the context of URNs at all, it has to be as "semantic fragid structures".

Insisting that fragments identify something makes this best practices document more complicated than it needs to be. It would be easier to write a text with the title "Best practices for URI fragments and media type definitions".

Even in [1] the author occasionally avoids the term identification. For instance on chapter C.5 URI http://example.org/potter#hermione just "means" the person named Hermione Granger, but does not "identify" her.

When fragment was first introduced to the URI syntax it may have made sense to think of it as an identifier of something. But over the years novel usages have been invented, and the problems inherent in this approach have become more obvious. For instance, does

http://example.com/document.txt#match=[rR][fF][cC]

identify words (every "RFC" and "rfc" within the document) or locations of these words within document.txt or something else? And if the base document changes so that there are no more matches, what does the fragment identify? Or, does

http://example.com/document.txt#match=[J][U][H][A][H][A][K][A][L][A]

identify me or just two words or something else? 

Fragments can also be used for searching, using syntax #!s!search terms. So the fragment this URI 

http://example.com/index.html#!s3!RFC

would instruct the browser to search the third occurrence of the term RFC in the document. But does this fragment identify that particular word, or that location in the resource? Or, if the fragment is the MD5 checksum of a document, which fragment of the document is identified?

Technical issues aside, the key problem here is that fragment assignment is completely un-managed process, even more so than naming of files and creation of URLs. Anyone who sees identifier assignment as something controlled should a priori have major issue with the idea of "fragment identifier".  

There are a lot of reasons why fragments must not be part of the namespace specific strings. But I see no problem in allowing them in URNs, as long as we don't think of them as identifiers. I fully agree with [1] that "authors can use fragments within referenced URIs (that is, URLs and URNs) to address content on documents published by others" . 




With the understanding that I'm not going to try to suggest
anything resembling syntax or delimiters at this point (it seems
to me that agreement to the "URNs are not URI's" spec or
equivalent is prerequisite to such a proposal or  even having
such a discussion), it seems to me that a generic URN string
(not URI) is going to be, conceptually

    "URN" NID NSS [ServiceRequests...]

It will ultimately make a difference whether "a URN" is the
complete URN string as above or just urn:NID:NSS or, put
differently, whether the ServiceRequests are part of the NSS.

Like URI queries, ServiceRequests must not be part of the NSS. Assigning an identifier to a resource is (ideally) a managed process, and identifiers themselves must never change. ServiceRequests are dependent on technical infrastructure which supports URN resolution, and may or may not be present on URNs to be resolved. 

But it makes less difference in the near term than out trying to
make general URIs work for URNs would suggest.

In the above, a ServiceRequest is, again conceptually, a tuple
of

   ServiceType ComparisonIndicator ServiceTarget
ReequestParameters...

ServiceType is nominally some sort of keyword.

OK. RFC 2483 defines a handful of these keywords and services, but not nearly enough.
 
ComparisonIndicator tells something trying to compare a pair of
URNs for identity whether that particular ServiceRequest counts
or should be ignored.

I am not sure I understand the need for ComparisonIndicator.  

ServiceTarget identifies where the
ServiceRequest is to be sent and, depending on the ServiceType,
may be a keyword indicator or, at the risk of descending into
recursion hell, a URL or URN.

Including ServiceTarget into ServiceRequest may not be necessary. URN resolver appropriate for the namespace in question should know which server is able to cater for ServiceRequests of given type. For instance, if a user wants full metadata about an academid dissertation, the resolver "knows" that the national bibliography should be able to fulfill the request. But if the document itself is requested, open repository (using Fedora, DSpace or some other such application) is better choice. 

And RequestParameters are
anything the ServiceType definition says they are.

Yes, and the number of parameters required will vary a lot depending on the ServiceType. 

    

      

        
Requests/specificaions for location information, assorted
metadata, or model or actual objects themselves are then just
specialized ServiceRequests.  In particular, "Fragment"
disappears as a special type of syntax and reappears as a
Service Request that is applicable to some NIDs and not others
and whose meaning and action (and how it is "resolved") are
specified on an NID basis and as above.  "Query" disappears too,
not because it (or the syntax) are necessarily problematic but
because the term itself is misleading for many possible types of
ServiceRequests and therefore causes more confusion than it
clears up.

      

    

    

    I am not sure it is  necessary / productive to make fragments
    reappear as ServiceRequest. As I see it, Service Requests are
    something that URN resolvers must deal with, whereas fragments will
    be processed by clients such as web browsers, both for URLs and
    URNs. At least for now I cannot see a need for a fragment-like
    Service Request, or understand properly what these services would be
    like. 

    

    Using URI query for passing ServiceRequests looks like an attractive
    option with minimal technical overhead. Whether this kind of use of
    query would be confusing, and whether using some other mechanism
    would make things more clear I can't tell, before seeing more
    detailed proposal on how to proceed. Like Lars, I wonder if the
    intention is to drop just the word query, or the syntax as well. 

    

    Juha   

    

    

      

        

      

      
Apart from the name "query", do you think this could be done using the URI query syntax?

[1] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids

Best,

Lars


    

    

    

    
-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University
 Tel. +358 9 191 44293
 Mobile +358 50 3827678 




  


--------------050803060606080703010603--


From nobody Thu Jun 26 03:27:45 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759561B2B41 for ; Thu, 26 Jun 2014 03:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.95
X-Spam-Level: 
X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 908KCcbIciJQ for ; Thu, 26 Jun 2014 03:27:42 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id CED311B2B18 for ; Thu, 26 Jun 2014 03:27:41 -0700 (PDT)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 3A30C7F3B0; Thu, 26 Jun 2014 12:27:40 +0200 (CEST)
From: "Svensson, Lars" 
To: Juha Hakala 
Thread-Topic: Re: [urn] Tuning the "URNs are not URIs" spec
Thread-Index: Ac+RKTk0+4oOtD8hSiOs18aXjZoVQA==
Date: Thu, 26 Jun 2014 10:27:39 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA445E960@dnbf-ex1.AD.DDB.DE>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.69.12.182]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/8bAxKlz318njmwmsTgIiUphS0BE
Cc: "urn@ietf.org" 
Subject: Re: [urn] Tuning the "URNs are not URIs" spec
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 10:27:44 -0000

Juha,

> On 25.6.2014 17:24, Svensson, Lars wrote:
> > All,
> >
> >>>>
> >>>>
> >>>>  From a generic URI point of view the strings http://example.org/ an=
d
> http://example.org:80/ are different resources. The http specification sa=
ys
> that for comparison resources the port is to be ignored if it is 80, so u=
nder
> http semantics those are equivalent (identify the same resources). Since
> comparison should always be about avoiding false positives, that is OK. C=
ould
> it be an option to state in the URN syntax, that when comparing for
> equivalence, the fragment identifier can be ignored?
>=20
> Two URNs should be considered to be equivalent if they identify the same
> thing.

Yes, and this depends on your definition of "thing"...

> Therefore the latest version of RFC2141bis says that
>=20
> > If a query component, fragment identifier component, or both have
> >     been appended to the assigned URN, they MUST be ignored for
> purposes
> >     of determining equivalence.
>=20
> ...because neither fragment nor query are part of the NSS.

In my eyes, that is not a strong enough argument since that is obvious from=
 the syntax urn:nid:nss?query#fragment. We need an explicit statement that =
says that "for identification purposes, the URN ends after the last charact=
er of the NSS. This implies that while a generic URI parser would consider =
the two URIs urn:example:foo and urn:example:foo?bar#baz two different URIs=
 and thus -- without further knowledge -- identifying two different resourc=
es, a URN parser would treat them as equivalent." (Or something along those=
 lines, which I cannot find in 2141bis). I also suggest that rfc 2141bis ad=
ds some examples with queries and fragments to =A76.1.

> > That said, I don't know if the commitment from the urn:nbn community to
> ensure that fragment identifiers will always work is enough to have them
> added to the generic URN syntax.
>=20
>  From the URN point of view fragments have nothing to do with
> identification. National libraries and our allies assign urn:nbns to
> resources, but typically it will be the users of these resources who
> will add fragments to the urns when they cite identified resources.

This makes the users/patrons responsible for using the correct fragment ide=
ntifier syntax for the media type in use, which requires good tool support.=
 Perhaps we need some use cases to illustrate how this would work.

> It is unfortunate that URI generic syntax talks about fragment
> identifiers. We should not do the same mistake, since it is very unclear
> what fragments could actually identify and how such fragment-driven
> identification process would be managed properly. A lay person may not
> see any problems here, but in this respect my point of view is one of a
> professional who has been closely involved with development and use of
> ISO identifier standards for about 20 years.

Yes, terminology can be a PITA, but that's nothing we can change (modulo up=
dating 3986).

> Generally speaking, fragments can be added to URNs which identify just a
> single manifestation of a resource and the mime type of the resource
> allows fragment usage. There are plenty of namespaces and mime types
> which meet these requirement. The requirement for being able to use
> fragment does not really come only from the urn:nbn community. Adding
> fragment to the URN syntax has more to do with the needs of the people
> who will cite resources which have already been identified with URNs
> which then provide access to these resources. IMO people will add
> fragments to URNs no matter what the URN syntax says. But if the URN
> syntax says nothing about fragments, then URI syntax applies, which
> means that everyone who cites a resource identifies something (location
> or segment or something else) within that resource by the act of citing,
> which sounds absurd (and unmanageable) to me.

If we don't add fragments to the URN syntax, a URN with an added fragment s=
imply will not be a valid URN...

Best,

Lars


From nobody Thu Jun 26 03:39:52 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26ECE1B2B06 for ; Thu, 26 Jun 2014 03:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.95
X-Spam-Level: 
X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 iviQf3o1wBlL for ; Thu, 26 Jun 2014 03:39:46 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8C51B2A61 for ; Thu, 26 Jun 2014 03:39:46 -0700 (PDT)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id B03197F3B5; Thu, 26 Jun 2014 12:39:45 +0200 (CEST)
From: "Svensson, Lars" 
To: Juha Hakala , John C Klensin ,  "Dale R. Worley" 
Thread-Topic: Re: [urn] urn:ietf:rfc
Thread-Index: Ac+RKuvpQ/S/bY0TTB6Q/jkrIzxQhg==
Date: Thu, 26 Jun 2014 10:39:43 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA445E97D@dnbf-ex1.AD.DDB.DE>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.69.12.182]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/2B62TpftAdgdldFgLQWsItqaCPI
Cc: "urn@ietf.org" 
Subject: Re: [urn] urn:ietf:rfc
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 10:39:48 -0000

Juha wrote:

> Insisting that fragments identify something makes this best practices
> document more complicated than it needs to be. It would be easier to writ=
e
> a text with the title "Best practices for URI fragments and media type
> definitions".

But they *do* identify something, namely a resource within another resource=
 (or in other words, a specific place in a resource). Nothing we do in URN =
space can change that. What we can do is to say that for *identification* p=
urposes, a URN can only identify primary resources and that any secondary r=
esource is not considered a *named* resource (since it doesn't have a resou=
rce _Name_).=20
On the other hand there is nothing that prevents me from constructing the a=
xiom

 owl:sameAs  .

which in a SemWeb setting allows me to use urn:example:bar as a name for a =
primary resource...

> Even in [1] the author occasionally avoids the term identification. For i=
nstance
> on chapter C.5 URI http://example.org/potter#hermione just "means" the
> person named Hermione Granger, but does not "identify" her.

Perhaps we should ask Jeni if that is intentional. As said: Yes, the term "=
fragment identifier" might be problematic, but I'd still say that it identi=
fies something and I don't think that changing its name to "fragment" solve=
s any problem (except the terminological one).

[...]

> There are a lot of reasons why fragments must not be part of the namespac=
e
> specific strings. But I see no problem in allowing them in URNs, as long =
as we
> don't think of them as identifiers. I fully agree with [1] that "authors =
can use
> fragments within referenced URIs (that is, URLs and URNs) to address
> content on documents published by others" .

Yes, but I think we need to more explicit in 2141bis what are the implicati=
ons and that they are not only not part of the NSS, but also that they play=
 no role in identification (but I'm repeating myself).

Best,

Lars


From nobody Thu Jun 26 05:14:25 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8812C1B2B7D for ; Thu, 26 Jun 2014 05:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.049
X-Spam-Level: 
X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 8OwmhwL2yeNK for ; Thu, 26 Jun 2014 05:14:17 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5F71B2B7F for ; Thu, 26 Jun 2014 05:14:17 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X08WP-000Ilt-0K; Thu, 26 Jun 2014 08:11:21 -0400
Date: Thu, 26 Jun 2014 08:13:59 -0400
From: John C Klensin 
To: Juha Hakala , "Svensson, Lars" , "Dale R. Worley" 
Message-ID: <2729E5F8517591572578FADD@JcK-HP8200.jck.com>
In-Reply-To: <53ABD826.20606@helsinki.fi>
References: <24637769D123E644A105A0AF0E1F92EFA445E513@dnbf-ex1.AD.DDB.DE> <53ABD826.20606@helsinki.fi>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MDPZd8iEsSu0L0avhlgaJOrsQpI
Cc: urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 12:14:23 -0000

Hi Juha and Lars,

Some comments below, mostly to clarify my earlier note to which
both of you partially responded.  First, and most important,
please understand that, while I have biases and opinions about
URNs and their proper definition and use, I'm trying to be
completely pragmatic about this.  That means I am putting three
strategic principles ahead of declarations about what is or is
not correct from some perspective.  Those pragmatic principles
are=20

 -- try to accommodate all of those who think URNs are
	necessary, i.e., that they are distinct from URLs.
	
 -- try to avoid getting bogged down in declarative/
	definitional statements about what is and is not correct
	in the abstract.
	
 -- avoid a fork in the standard in which we have
	multiple, conflicting, definitions or criteria for URNs
	around.

I say "opinions and biases" because, while I have preferences
about what I believe to be correct, they are not nearly as
informed as yours nor nearly as focused on the needs of a small
cluster of applications as those of some others.  Instead, for
the purposes on these discussions generally and getting this
work to a successful conclusion in particular, I'm just trying
to listen to comments and generate a model that is general
enough to accommodate all of those that seem to be based in
clear needs and applications (specifically, I'm no longer
interested in the positions of those who believe that URNs, or
the distinctions that define the need for them, are fictional or
irrelevant).

This is a radical point of view.  I generally don't like radical
points of view but just don't see any other way out for us.  See
[3] for a further caveat about this note.

It is just a corollary to the above that I am trying to avoid
discussions about what is or is not "persistent" (or "persistent
enough") and what is or is not formally an "identifier".  I
think the much more pragmatic question of naming constructs that
are independent of resolution or accessing method(s) and which
have to be usable for periods of time that range from weeks or
months to many centuries, with those difference in time
expectations depending on the NID, not the fundamental nature of
URNs.

This is a difficult discussion and many of us (certainly
including myself) seem easily distracted into discussions that
don't move the URN effort forward.  They are very interesting
and philosophically important -- that is probably what makes
them such tempting distractions -- but getting diverted into
them is really not helpful.  I'm trying to be very resistant to
those discussions and hope that others will grow more resistant
to them too.

So, with that background...

--On Thursday, June 26, 2014 11:21 +0300 Juha Hakala
 wrote:

>...
>>>> We have discussed earlier on this list about the
>>>> applicability of fragments in the URN context. If and only
>>>> if a URN identifies a single digital manifestation of a
>>>> resource (such as a PDF file) users can apply URI fragment
>>>> any time after the resource has been identified and the
>>>> identifier has been made actionable, provided that the MIME
>>>> type of that file format supports the use of fragment. In
>>>> such a case it is likely that the URN + fragment will be
>>>> more persistent than URL + fragment.

>>> That may be true, but it is also tied up with the reason =
I've
>>> been skeptical about the association of "fragment" --even
>>> approximately as defined for URLs and generic URIs-- to URNs
>>> at all.

>> Having looked at the Best Practices for Fragment Identifiers
>> [1] (which I wasn't aware of) the task is really daunting.
>> *If* we can talk about FIs in the context of URNs at all, it
>> has to be as "semantic fragid structures".
>=20
> Insisting that fragments identify something makes this best
> practices document more complicated than it needs to be. It
> would be easier to write a text with the title "Best practices
> for URI fragments and media type definitions".
>...

Here, as elsewhere in this note, the principles above cause me
to take a position very different from where you (and Lars) are
going -- not contradictory, but orthogonal.  Because of those
principles and the question of the legitimacy of URNs as a
construction separate from URLs (or URLs generalized into URIs),
I believe the document cited [1] is simply irrelevant.   I
really want to see us discuss and evolve URNs in a way that
responds to needs --as concrete as possible-- identified by
legitimate communities, not whether the results (or thinking)
conform to some notions about generalized HTTP URLs.    As I
tried to say in my earlier note, I'd like to move away from the
terms "fragment" and "query" entirely, just because their
historical association with 3986 creates confusion and leads to
discussions that primarily apply to URLs (and maybe HTTP URLs in
particular) and whether those other specs require entire
conformance or support of particular capabilities in URNs. =20

I note that this "best practices" document is still a Proposed
Recommendation and not authoritative, even within W3C, for even
HTTP URLs.  I don't believe that debating the particular
terminology the editor used is helpful to making progress on
URNs and, while we might try to use what we think we know now
about URNs to refine it, I think such an effort would impede
moving forward with a [non-forked] updated URN spec.   Put
differently, my proposed and pragmatic point of view (including
the separation of URNs from the generic URI spec) says that this
document is simply not relevant to URNs and that trying to make
it relevant (or assert its relevancy) just gets in our way.

>...
> would instruct the browser to search the third occurrence of
> the term RFC in the document. But does this fragment identify
> that particular word, or that location in the resource? ||Or,
> if the fragment is the MD5 checksum of a document, which
> fragment of the document is identified?

I want to stay with "irrelevant" and away from distractions, but
the above helps show why that position is important: if one
believes that URNs have to be stable independent of what happens
with method-dependent "identifiers" (or "locators", etc.), then
I think we have to simply avoid getting entangled by statements
about instructions to browsers because we cannot to know what a
"browser" is with sufficient clarity, abstraction, and
persistence/stability.

> Technical issues aside, the key problem here is that fragment
> assignment is completely un-managed process, even more so than
> naming of files and creation of URLs. Anyone who sees
> identifier assignment as something controlled should a priori
> have major issue with the idea of "fragment identifier".

Yes.  But, even while I agree with that distinction, I think it
leads us around in a circle and back to another distraction.  If
one steps back from the 3986 "generic" definition and thinks of
fragments were, IIR, they started, we end up with two types of
prototype fragments.  One involves a marked-up document (not
necessarily HTML but certainly thought of in that context) with
anchor labels (definitely "identifiers" in the context of that
document) and the other a counted object in a specific form of a
document.  In both cases the "fragment identifier" is just a
pointer that is as persistent as the object itself.  I note
that, in an alternate reality, that view generalizes.  For
example, ISBNs could have been defined to include numbered
chapters and chapter designations as an intrinsic property of
the work being identified/numbered.  That wasn't done for
_really_ good reasons, but, had it been done,=20
    urn:isbn:...#Chapter3
would have been fully as meaningful as an HTTP URL that locates
an HTML object and that contains a fragment "identifier".

What is important about that hypothetical variant ISBN is that
the definition of "fragment" becomes completely dependent on the
properties of the NID definition, just as [1] is very dependent
on assumed properties of HTTP URLs that point to HTML objects.
The problem arises only when one tries to make generic
statements about URLs (or generic URIs) independent of what they
locate, identify, or with which they are otherwise associated.

=20
> There are a lot of reasons why fragments must not be part of
> the namespace specific strings. But I see no problem in
> allowing them in URNs, as long as we don't think of them as
> identifiers. I fully agree with [1] that "authors can use
> fragments within referenced URIs (that is, URLs and URNs) to
> address content on documents published by others" .

And my problem is that, in a fully general sense (more general
than either HTTP-URLs references HTML-like objects or your
library/ museum/ etc., context) I'm not sure what many of the
words you mean above mean.  The words themselves are
context-dependent.  Using them as if they are broad generic
terms introduces confusion; trying to define them precisely
enough to cover all possible cases, including future ones, is,
in the "get to a non-forked URN" context, a distraction.

See below.

>...
> Like URI queries, ServiceRequests must not be part of the NSS.
> Assigning an identifier to a resource is (ideally) a managed
> process, and identifiers themselves must never change.
> ServiceRequests are dependent on technical infrastructure
> which supports URN resolution, and may or may not be present
> on URNs to be resolved.

If you equate "part of the NSS" with "differences in it at the
bit level cause two URNs to compare non-equal" then that is a
discussion I'm trying to avoid.  Again, I can completely agree
with you in your context; I'm just trying to avoid needing to
have the discussion, much less reach consensus about the
answers, in a much more general context.  And that leads
directly to "ComparisonIndicator", so see below.
=20
>>> But it makes less difference in the near term than out
>>> trying to make general URIs work for URNs would suggest.
>>>=20
>>> In the above, a ServiceRequest is, again conceptually, a
>>> tuple of
>>>=20
>>>     ServiceType ComparisonIndicator ServiceTarget
>>> ReequestParameters...
>>>=20
>>> ServiceType is nominally some sort of keyword.
>=20
> OK. RFC 2483 defines a handful of these keywords and services,
> but not nearly enough.

Another example of what I'm trying to avoid.  I am certain your
statement above is true.  I am equally certain the trying to
define (or even adequately characterize) the others will bog us
down for a very long time and lead us to Plan C or D [2].  So
I'm trying to push that problem away by making those services
and keywords a per-NID matter.  If it turns out that we can
later make groups of NIDs into categories that share some set of
services and keywords, that would be great.  But, if we make
doing so, or even proving that we can do so, a condition for
URNs, then we will be back to where we were when I first killed
the URI WG.

>>> ComparisonIndicator tells something trying to compare a pair
>>> of URNs for identity whether that particular ServiceRequest
>>> counts or should be ignored.
>=20
> I am not sure I understand the need for ComparisonIndicator.

It is a trick to avoid having to resolve the question of whether
a particular Service Request --or Service Requests in general--
are "part of the NSS".   I called it "ComparisonIndicator"
because I believe that, absent the question of comparing a pair
of URNs for equality, the "part of the NSS" question doesn't
need a precise answer and might be a distraction.

>>> ServiceTarget identifies where the
>>> ServiceRequest is to be sent and, depending on the
>>> ServiceType, may be a keyword indicator or, at the risk of
>>> descending into recursion hell, a URL or URN.
>=20
> Including ServiceTarget into ServiceRequest may not be
> necessary. URN resolver appropriate for the namespace in
> question should know which server is able to cater for
> ServiceRequests of given type. For instance, if a user wants
> full metadata about an academid dissertation, the resolver
> "knows" that the national bibliography should be able to
> fulfill the request. But if the document itself is requested,
> open repository (using Fedora, DSpace or some other such
> application) is better choice.

In the language I've used, what you have just said is "for all
NIDs, it should be possible to specify the ServiceTarget as part
of the definition/ registration, thereby not requiring it to
appear in the ServiceRequest associated with a URN and probably
prohibiting it there".    If that is true, it is wonderful.  But
I'm trying to avoid a requirement to prove such statements about
"all NIDs" rather than particular NIDs or, e.g., NIDs that might
sensibly be used in the library community.

>>> And RequestParameters are
>>> anything the ServiceType definition says they are.
>=20
> Yes, and the number of parameters required will vary a lot
> depending on the ServiceType.

So there we agree on the abstraction and dependency on NID.  I'm
just trying to avoid a different version of the "generic
something-or-other" trap by similarly abstracting ServiceTarget
and ComparisonIndicator.   If they can be kept as part of the
NID definitions and consequently kept out of URN strings, it
will make a better, easier, and less complex world.  But I don't
see any way to demonstrate that there are no possible reasonable
namespaces for which different conventions may not be needed.
And I don't want that demonstration/proof to be in the critical
path.

>>> Requests/specificaions for location information, assorted
>>> metadata, or model or actual objects themselves are then =
just
>>> specialized ServiceRequests.  In particular, "Fragment"
>>> disappears as a special type of syntax and reappears as a
>>> Service Request that is applicable to some NIDs and not
>>> others and whose meaning and action (and how it is
>>> "resolved") are specified on an NID basis and as above.
>>> "Query" disappears too, not because it (or the syntax) are
>>> necessarily problematic but because the term itself is
>>> misleading for many possible types of ServiceRequests and
>>> therefore causes more confusion than it clears up.
>=20
> I am not sure it is  necessary / productive to make fragments
> reappear as ServiceRequest. As I see it, Service Requests are
> something that URN resolvers must deal with, whereas fragments
> will be processed by clients such as web browsers, both for
> URLs and URNs. At least for now I cannot see a need for a
> fragment-like Service Request, or understand properly what
> these services would be like.

See above and note that, just as I'm not sure that a generic URN
definition needs to know (or can know) what a "browser" is, I'm
not confident, generically, what a "URN resolver" is (other
than, like "browser", more handwaving).

> Using URI query for passing ServiceRequests looks like an
> attractive option with minimal technical overhead. Whether
> this kind of use of query would be confusing, and whether
> using some other mechanism would make things more clear I
> can't tell, before seeing more detailed proposal on how to
> proceed. Like Lars, I wonder if the intention is to drop just
> the word query, or the syntax as well.

Both.  Possibly we could preserve the syntax, but I think that
requires that someone make the case that the advantages of doing
so outweigh the disadvantages.  In particular, if the tuple
described above every actually needs to be present in a URN
string, I'm not sure the existing syntax works without a great
deal of confusing and error-prone clutter.




--On Thursday, June 26, 2014 10:27 +0000 "Svensson, Lars"
 wrote:

>> Two URNs should be considered to be equivalent if they
>> identify the same thing.
>=20
> Yes, and this depends on your definition of "thing"...

Indeed.  And I'm essentially suggesting that, in the general
case, we don't know how to define "thing" except on a
per-namespace (NID-dependent) basis.  I believe there may be
categories of namespeaces (and NIDs) that would share
thing-definitions but we haven't even begun to talk about such
categories, much less their definitions and properties.
However, I think we can demonstrate that the differences exist
just by looking at the differences in starting point, language,
and assumptions between Juha and Dale -- both of whom, I'm
convinced are acting in good faith and with a good understanding
to the problems they need to solve for their communities.

>...
>> ...because neither fragment nor query are part of the NSS.
>=20
> In my eyes, that is not a strong enough argument since that is
> obvious from the syntax urn:nid:nss?query#fragment. We need an
> explicit statement that says that "for identification
> purposes, the URN ends after the last character of the NSS.
> This implies that while a generic URI parser would consider
> the two URIs urn:example:foo and urn:example:foo?bar#baz two
> different URIs and thus -- without further knowledge --
> identifying two different resources, a URN parser would treat
> them as equivalent." (Or something along those lines, which I
> cannot find in 2141bis). I also suggest that rfc 2141bis adds
> some examples with queries and fragments to =C2=A76.1.

See above and note that, if URNs are not URIs, then, if there is
such a thing as a "generic URI parser", it doesn't inherently
apply to URNs.  That, in turn, takes us back to a comment of
some months ago about a generic URI really consisting of a
method followed by method-dependent "stuff".

>...
>>  From the URN point of view fragments have nothing to do with
>> identification. National libraries and our allies assign
>> urn:nbns to resources, but typically it will be the users of
>> these resources who will add fragments to the urns when they
>> cite identified resources.
>=20
> This makes the users/patrons responsible for using the correct
> fragment identifier syntax for the media type in use, which
> requires good tool support. Perhaps we need some use cases to
> illustrate how this would work.

It is more than "good tool support" unless the tools themselves
are to become de facto part of the URN definition and at least
as permanent/ persistent as the definition itself.  I don't see
that as impossible, just unlikely.

>> It is unfortunate that URI generic syntax talks about =
fragment
>> identifiers. We should not do the same mistake, since it is
>> very unclear what fragments could actually identify and how
>> such fragment-driven identification process would be managed
>> properly. A lay person may not see any problems here, but in
>> this respect my point of view is one of a professional who
>> has been closely involved with development and use of ISO
>> identifier standards for about 20 years.
>=20
> Yes, terminology can be a PITA, but that's nothing we can
> change (modulo updating 3986).

Or separating URNs from 3986 and then defining whatever is
needed to be defined for URNs in a URN-appropriate way.  That is
exactly what "Plan B" [2] and "URNs are not URIs" are about.

>> Generally speaking, fragments can be added to URNs which
>> identify just a single manifestation of a resource and the
>> mime type of the resource allows fragment usage. There are
>> plenty of namespaces and mime types which meet these
>> requirement. The requirement for being able to use fragment
>> does not really come only from the urn:nbn community. Adding
>> fragment to the URN syntax has more to do with the needs of
>> the people who will cite resources which have already been
>> identified with URNs which then provide access to these
>> resources. IMO people will add fragments to URNs no matter
>> what the URN syntax says. But if the URN syntax says nothing
>> about fragments, then URI syntax applies, which means that
>> everyone who cites a resource identifies something (location
>> or segment or something else) within that resource by the act
>> of citing, which sounds absurd (and unmanageable) to me.
>=20
> If we don't add fragments to the URN syntax, a URN with an
> added fragment simply will not be a valid URN...

Right.  And I'm trying to encourage making a distinction between
"the functionality that the urn:nbn community (and other
communities) need from "fragment" and the syntax and semantics
attached to that term by 3986 and other URL-derived documents.

 best,
    john


[1] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids

[2]  From my point of view, we had to move beyond "Plan A" when
trying to meet everyone's perceived needs while staying within
the boundaries established by RFC 3986 and its penumbra
(including [1] and several "URLs are sufficient" assumptions).
"Plan B" separates URNs from generic URLs, in the "URNs are not
URIs" spec or in some other way.  If that fails, then we will
need to either start thinking about how to manage a forked
specification with not-quote-compatible branches or with getting
rid of URNs in favor of field-specific UR*, possibly starting
with URSs (Uniform Resource SNAFU).

[3] Disclaimer: For better or worse, I had several interesting
conversations yesterday about Norbert Wiener's legacy (including
but not limited to "Cybernetics") and its 21st Century
implications, particularly about the importance of rigor and
precision in discussions at the man-machine boundary.  While
those discussions clearly postdate my thinking of the last
several months (and, in particular, the "URNs are not URIs" spec
and my earlier comments in this thread), they almost certainly
contribute to whatever impatience comes through in this note
about making broad generalizations about categories that cannot
be fully identified (and syntax and other rules based on those
generalizations).  As was the case two decades ago, I want to
see if we can define URNs without falling into that trap.



From nobody Fri Jun 27 08:39:17 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3441B305D for ; Fri, 27 Jun 2014 08:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.25
X-Spam-Level: 
X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 uJNdR082DPTb for ; Fri, 27 Jun 2014 08:39:07 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF821B3253 for ; Fri, 27 Jun 2014 08:39:06 -0700 (PDT)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 87FE87EF73; Fri, 27 Jun 2014 17:39:05 +0200 (CEST)
From: "Svensson, Lars" 
To: John C Klensin , Juha Hakala ,  "Dale R. Worley" 
Thread-Topic: Re: [urn] urn:ietf:rfc
Thread-Index: Ac+SHePaVwcDVS5VS+KkgP1l21qfgg==
Date: Fri, 27 Jun 2014 15:39:04 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA445F063@dnbf-ex1.AD.DDB.DE>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.69.24]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/oVkI8yjr-Ky0PYS2PxP9E27x1V0
Cc: "urn@ietf.org" 
Subject: Re: [urn] urn:ietf:rfc
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 15:39:13 -0000

Sm9obiwNCg0KPiBTb21lIGNvbW1lbnRzIGJlbG93LCBtb3N0bHkgdG8gY2xhcmlmeSBteSBlYXJs
aWVyIG5vdGUgdG8gd2hpY2gNCj4gYm90aCBvZiB5b3UgcGFydGlhbGx5IHJlc3BvbmRlZC4gIEZp
cnN0LCBhbmQgbW9zdCBpbXBvcnRhbnQsDQo+IHBsZWFzZSB1bmRlcnN0YW5kIHRoYXQsIHdoaWxl
IEkgaGF2ZSBiaWFzZXMgYW5kIG9waW5pb25zIGFib3V0DQo+IFVSTnMgYW5kIHRoZWlyIHByb3Bl
ciBkZWZpbml0aW9uIGFuZCB1c2UsIEknbSB0cnlpbmcgdG8gYmUNCj4gY29tcGxldGVseSBwcmFn
bWF0aWMgYWJvdXQgdGhpcy4gIFRoYXQgbWVhbnMgSSBhbSBwdXR0aW5nIHRocmVlDQo+IHN0cmF0
ZWdpYyBwcmluY2lwbGVzIGFoZWFkIG9mIGRlY2xhcmF0aW9ucyBhYm91dCB3aGF0IGlzIG9yIGlz
DQo+IG5vdCBjb3JyZWN0IGZyb20gc29tZSBwZXJzcGVjdGl2ZS4gIFRob3NlIHByYWdtYXRpYyBw
cmluY2lwbGVzDQo+IGFyZQ0KPiANCj4gIC0tIHRyeSB0byBhY2NvbW1vZGF0ZSBhbGwgb2YgdGhv
c2Ugd2hvIHRoaW5rIFVSTnMgYXJlDQo+IAluZWNlc3NhcnksIGkuZS4sIHRoYXQgdGhleSBhcmUg
ZGlzdGluY3QgZnJvbSBVUkxzLg0KDQpXZWxsLCBvZiBjb3Vyc2UgdGhleSBhcmUuIEkgdGhpbmsg
d2UgZ2V0IGJvZ2dlZCBkb3duIHdpdGggdGhlIHF1ZXN0aW9uLCBpZiBVUk5zIGFyZSBhIHN1YmNs
YXNzIG9mIFVSSXMgb3Igbm90LiBJIHRyeSB0byBhcmd1ZSB0aGF0IFVSTnMgX3Nob3VsZF8gYmUg
YSBzdWJjbGFzcyBvZiBVUklzIGZvciB0aGUgc2ltcGxlIHJlYXNvbiB0aGF0IGl0IGFsbG93cyBt
ZSB0byB1c2UgYSBVUk4gaW4gYWxsIHBsYWNlcyB3aGVyZSBhIFVSSSBpcyBleHBlY3RlZCwgZS4g
Zy4gYXMgYW4gWE1MIG5hbWVzcGFjZSBpZGVudGlmaWVyLCBvciBpbiBhIFNlbVdlYi9MaW5rZWRE
YXRhIHNldHRpbmcsIHdoZXJlIGlkZW50aWZpZXJzIGZvciBlbnRpdGllcyBhcmUgcmVxdWVzdGVk
IHRvIGJlIFVSSXMuIFRoaXMgaXMgbm90IG9ubHkgYSBjb25jZXJuIGFib3V0IGJyZWFraW5nIGJh
Y2t3YXJkIGNvbXBhdGliaWxpdHksIGJ1dCBhbHNvIGEgbWFya2V0aW5nIGlzc3VlOiBPbmUgb2Yg
b3VyIHNlbGxpbmcgcG9pbnRzIHdoZW4gd2UgdHJ5IHRvIGNvbnZpbmNlIHBlb3BsZSB0byB1c2Ug
VVJOcyBpcyBleGFjdGx5IHRoZSBwb2ludCB0aGF0IHRoZXkgYXJlIFVSSXMsIHRvbyBhbmQgdGhh
dCBhbGwgdGhlIHVzYWdlcyBtZW50aW9uZWQgYWJvdmUgYXJlIG9wZW4gdG8gdGhlbS4NCg0KPiAg
LS0gdHJ5IHRvIGF2b2lkIGdldHRpbmcgYm9nZ2VkIGRvd24gaW4gZGVjbGFyYXRpdmUvDQo+IAlk
ZWZpbml0aW9uYWwgc3RhdGVtZW50cyBhYm91dCB3aGF0IGlzIGFuZCBpcyBub3QgY29ycmVjdA0K
PiAJaW4gdGhlIGFic3RyYWN0Lg0KPiANCj4gIC0tIGF2b2lkIGEgZm9yayBpbiB0aGUgc3RhbmRh
cmQgaW4gd2hpY2ggd2UgaGF2ZQ0KPiAJbXVsdGlwbGUsIGNvbmZsaWN0aW5nLCBkZWZpbml0aW9u
cyBvciBjcml0ZXJpYSBmb3IgVVJOcw0KPiAJYXJvdW5kLg0KPiANCj4gSSBzYXkgIm9waW5pb25z
IGFuZCBiaWFzZXMiIGJlY2F1c2UsIHdoaWxlIEkgaGF2ZSBwcmVmZXJlbmNlcw0KPiBhYm91dCB3
aGF0IEkgYmVsaWV2ZSB0byBiZSBjb3JyZWN0LCB0aGV5IGFyZSBub3QgbmVhcmx5IGFzDQo+IGlu
Zm9ybWVkIGFzIHlvdXJzIG5vciBuZWFybHkgYXMgZm9jdXNlZCBvbiB0aGUgbmVlZHMgb2YgYSBz
bWFsbA0KPiBjbHVzdGVyIG9mIGFwcGxpY2F0aW9ucyBhcyB0aG9zZSBvZiBzb21lIG90aGVycy4g
IEluc3RlYWQsIGZvcg0KPiB0aGUgcHVycG9zZXMgb24gdGhlc2UgZGlzY3Vzc2lvbnMgZ2VuZXJh
bGx5IGFuZCBnZXR0aW5nIHRoaXMNCj4gd29yayB0byBhIHN1Y2Nlc3NmdWwgY29uY2x1c2lvbiBp
biBwYXJ0aWN1bGFyLCBJJ20ganVzdCB0cnlpbmcNCj4gdG8gbGlzdGVuIHRvIGNvbW1lbnRzIGFu
ZCBnZW5lcmF0ZSBhIG1vZGVsIHRoYXQgaXMgZ2VuZXJhbA0KPiBlbm91Z2ggdG8gYWNjb21tb2Rh
dGUgYWxsIG9mIHRob3NlIHRoYXQgc2VlbSB0byBiZSBiYXNlZCBpbg0KPiBjbGVhciBuZWVkcyBh
bmQgYXBwbGljYXRpb25zIChzcGVjaWZpY2FsbHksIEknbSBubyBsb25nZXINCj4gaW50ZXJlc3Rl
ZCBpbiB0aGUgcG9zaXRpb25zIG9mIHRob3NlIHdobyBiZWxpZXZlIHRoYXQgVVJOcywgb3INCj4g
dGhlIGRpc3RpbmN0aW9ucyB0aGF0IGRlZmluZSB0aGUgbmVlZCBmb3IgdGhlbSwgYXJlIGZpY3Rp
b25hbCBvcg0KPiBpcnJlbGV2YW50KS4NCj4gDQo+IFRoaXMgaXMgYSByYWRpY2FsIHBvaW50IG9m
IHZpZXcuICBJIGdlbmVyYWxseSBkb24ndCBsaWtlIHJhZGljYWwNCj4gcG9pbnRzIG9mIHZpZXcg
YnV0IGp1c3QgZG9uJ3Qgc2VlIGFueSBvdGhlciB3YXkgb3V0IGZvciB1cy4gIFNlZQ0KPiBbM10g
Zm9yIGEgZnVydGhlciBjYXZlYXQgYWJvdXQgdGhpcyBub3RlLg0KPiANCj4gSXQgaXMganVzdCBh
IGNvcm9sbGFyeSB0byB0aGUgYWJvdmUgdGhhdCBJIGFtIHRyeWluZyB0byBhdm9pZA0KPiBkaXNj
dXNzaW9ucyBhYm91dCB3aGF0IGlzIG9yIGlzIG5vdCAicGVyc2lzdGVudCIgKG9yICJwZXJzaXN0
ZW50DQo+IGVub3VnaCIpIGFuZCB3aGF0IGlzIG9yIGlzIG5vdCBmb3JtYWxseSBhbiAiaWRlbnRp
ZmllciIuICBJDQo+IHRoaW5rIHRoZSBtdWNoIG1vcmUgcHJhZ21hdGljIHF1ZXN0aW9uIG9mIG5h
bWluZyBjb25zdHJ1Y3RzIHRoYXQNCj4gYXJlIGluZGVwZW5kZW50IG9mIHJlc29sdXRpb24gb3Ig
YWNjZXNzaW5nIG1ldGhvZChzKSBhbmQgd2hpY2gNCj4gaGF2ZSB0byBiZSB1c2FibGUgZm9yIHBl
cmlvZHMgb2YgdGltZSB0aGF0IHJhbmdlIGZyb20gd2Vla3Mgb3INCj4gbW9udGhzIHRvIG1hbnkg
Y2VudHVyaWVzLCB3aXRoIHRob3NlIGRpZmZlcmVuY2UgaW4gdGltZQ0KPiBleHBlY3RhdGlvbnMg
ZGVwZW5kaW5nIG9uIHRoZSBOSUQsIG5vdCB0aGUgZnVuZGFtZW50YWwgbmF0dXJlIG9mDQo+IFVS
TnMuDQo+IA0KPiBUaGlzIGlzIGEgZGlmZmljdWx0IGRpc2N1c3Npb24gYW5kIG1hbnkgb2YgdXMg
KGNlcnRhaW5seQ0KPiBpbmNsdWRpbmcgbXlzZWxmKSBzZWVtIGVhc2lseSBkaXN0cmFjdGVkIGlu
dG8gZGlzY3Vzc2lvbnMgdGhhdA0KPiBkb24ndCBtb3ZlIHRoZSBVUk4gZWZmb3J0IGZvcndhcmQu
ICBUaGV5IGFyZSB2ZXJ5IGludGVyZXN0aW5nDQo+IGFuZCBwaGlsb3NvcGhpY2FsbHkgaW1wb3J0
YW50IC0tIHRoYXQgaXMgcHJvYmFibHkgd2hhdCBtYWtlcw0KPiB0aGVtIHN1Y2ggdGVtcHRpbmcg
ZGlzdHJhY3Rpb25zIC0tIGJ1dCBnZXR0aW5nIGRpdmVydGVkIGludG8NCj4gdGhlbSBpcyByZWFs
bHkgbm90IGhlbHBmdWwuICBJJ20gdHJ5aW5nIHRvIGJlIHZlcnkgcmVzaXN0YW50IHRvDQo+IHRo
b3NlIGRpc2N1c3Npb25zIGFuZCBob3BlIHRoYXQgb3RoZXJzIHdpbGwgZ3JvdyBtb3JlIHJlc2lz
dGFudA0KPiB0byB0aGVtIHRvby4NCj4gDQo+IFNvLCB3aXRoIHRoYXQgYmFja2dyb3VuZC4uLg0K
PiANCj4gLS1PbiBUaHVyc2RheSwgSnVuZSAyNiwgMjAxNCAxMToyMSArMDMwMCBKdWhhIEhha2Fs
YQ0KPiA8anVoYS5oYWthbGFAaGVsc2lua2kuZmk+IHdyb3RlOg0KPiANCj4gPi4uLg0KPiA+Pj4+
IFdlIGhhdmUgZGlzY3Vzc2VkIGVhcmxpZXIgb24gdGhpcyBsaXN0IGFib3V0IHRoZQ0KPiA+Pj4+
IGFwcGxpY2FiaWxpdHkgb2YgZnJhZ21lbnRzIGluIHRoZSBVUk4gY29udGV4dC4gSWYgYW5kIG9u
bHkNCj4gPj4+PiBpZiBhIFVSTiBpZGVudGlmaWVzIGEgc2luZ2xlIGRpZ2l0YWwgbWFuaWZlc3Rh
dGlvbiBvZiBhDQo+ID4+Pj4gcmVzb3VyY2UgKHN1Y2ggYXMgYSBQREYgZmlsZSkgdXNlcnMgY2Fu
IGFwcGx5IFVSSSBmcmFnbWVudA0KPiA+Pj4+IGFueSB0aW1lIGFmdGVyIHRoZSByZXNvdXJjZSBo
YXMgYmVlbiBpZGVudGlmaWVkIGFuZCB0aGUNCj4gPj4+PiBpZGVudGlmaWVyIGhhcyBiZWVuIG1h
ZGUgYWN0aW9uYWJsZSwgcHJvdmlkZWQgdGhhdCB0aGUgTUlNRQ0KPiA+Pj4+IHR5cGUgb2YgdGhh
dCBmaWxlIGZvcm1hdCBzdXBwb3J0cyB0aGUgdXNlIG9mIGZyYWdtZW50LiBJbg0KPiA+Pj4+IHN1
Y2ggYSBjYXNlIGl0IGlzIGxpa2VseSB0aGF0IHRoZSBVUk4gKyBmcmFnbWVudCB3aWxsIGJlDQo+
ID4+Pj4gbW9yZSBwZXJzaXN0ZW50IHRoYW4gVVJMICsgZnJhZ21lbnQuDQo+IA0KPiA+Pj4gVGhh
dCBtYXkgYmUgdHJ1ZSwgYnV0IGl0IGlzIGFsc28gdGllZCB1cCB3aXRoIHRoZSByZWFzb24gSSd2
ZQ0KPiA+Pj4gYmVlbiBza2VwdGljYWwgYWJvdXQgdGhlIGFzc29jaWF0aW9uIG9mICJmcmFnbWVu
dCIgLS1ldmVuDQo+ID4+PiBhcHByb3hpbWF0ZWx5IGFzIGRlZmluZWQgZm9yIFVSTHMgYW5kIGdl
bmVyaWMgVVJJcy0tIHRvIFVSTnMNCj4gPj4+IGF0IGFsbC4NCj4gDQo+ID4+IEhhdmluZyBsb29r
ZWQgYXQgdGhlIEJlc3QgUHJhY3RpY2VzIGZvciBGcmFnbWVudCBJZGVudGlmaWVycw0KPiA+PiBb
MV0gKHdoaWNoIEkgd2Fzbid0IGF3YXJlIG9mKSB0aGUgdGFzayBpcyByZWFsbHkgZGF1bnRpbmcu
DQo+ID4+ICpJZiogd2UgY2FuIHRhbGsgYWJvdXQgRklzIGluIHRoZSBjb250ZXh0IG9mIFVSTnMg
YXQgYWxsLCBpdA0KPiA+PiBoYXMgdG8gYmUgYXMgInNlbWFudGljIGZyYWdpZCBzdHJ1Y3R1cmVz
Ii4NCj4gPg0KPiA+IEluc2lzdGluZyB0aGF0IGZyYWdtZW50cyBpZGVudGlmeSBzb21ldGhpbmcg
bWFrZXMgdGhpcyBiZXN0DQo+ID4gcHJhY3RpY2VzIGRvY3VtZW50IG1vcmUgY29tcGxpY2F0ZWQg
dGhhbiBpdCBuZWVkcyB0byBiZS4gSXQNCj4gPiB3b3VsZCBiZSBlYXNpZXIgdG8gd3JpdGUgYSB0
ZXh0IHdpdGggdGhlIHRpdGxlICJCZXN0IHByYWN0aWNlcw0KPiA+IGZvciBVUkkgZnJhZ21lbnRz
IGFuZCBtZWRpYSB0eXBlIGRlZmluaXRpb25zIi4NCj4gPi4uLg0KPiANCj4gSGVyZSwgYXMgZWxz
ZXdoZXJlIGluIHRoaXMgbm90ZSwgdGhlIHByaW5jaXBsZXMgYWJvdmUgY2F1c2UgbWUNCj4gdG8g
dGFrZSBhIHBvc2l0aW9uIHZlcnkgZGlmZmVyZW50IGZyb20gd2hlcmUgeW91IChhbmQgTGFycykg
YXJlDQo+IGdvaW5nIC0tIG5vdCBjb250cmFkaWN0b3J5LCBidXQgb3J0aG9nb25hbC4gIEJlY2F1
c2Ugb2YgdGhvc2UNCj4gcHJpbmNpcGxlcyBhbmQgdGhlIHF1ZXN0aW9uIG9mIHRoZSBsZWdpdGlt
YWN5IG9mIFVSTnMgYXMgYQ0KPiBjb25zdHJ1Y3Rpb24gc2VwYXJhdGUgZnJvbSBVUkxzIChvciBV
UkxzIGdlbmVyYWxpemVkIGludG8gVVJJcyksDQoNClRoaXMgc2VlbXMgdG8gYmUgdGhlIHBsYWNl
IHdoZXJlIHdlIG5lZWQgdG8gZmluZCBhIGNvbW1vbiB2aWV3IG9uIHRoaW5ncy4gTXkgcmVhZGlu
ZyBpcyB0aGF0IFVSSXMgKGFzIGRlZmluZWQgYnkgMzk4NikgYXJlIF9hbHdheXNfIGlkZW50aWZp
ZXJzIGFuZCB0aGF0IF9zb21lXyBVUklzIChkZXBlbmRpbmcgb24gdGhlaXIgc2NoZW1lKSBhcmUg
YWxzbyBsb2NhdG9ycy4gVG8gdGhlICJwdXJlIGlkZW50aWZpZXJzIiBJIGNvdW50IGUuIGcuIGdl
bzosIHhjb246IGFuZCBjcmlkOiAoYW5kIHVybjopLCB3aGlsZSBlLiBnLiBodHRwOiwgZnRwOiBh
bmQgc210cDogd291bGQgYmUgbG9jYXRvcnMgYXMgd2VsbC4gU28gaW4gbXkgdmlldywgd2UgY2Fu
bm90IGdlbmVyYWxpc2UgVVJMcyBpbnRvIFVSSXMsIHdoaWNoIHdvdWxkIGFsbG93IHVzIHRvIGtl
ZXAgVVJOcyBhcyBhIHN1YmNsYXNzIG9mIFVSSXMuDQoNCj4gSSBiZWxpZXZlIHRoZSBkb2N1bWVu
dCBjaXRlZCBbMV0gaXMgc2ltcGx5IGlycmVsZXZhbnQuICAgSQ0KPiByZWFsbHkgd2FudCB0byBz
ZWUgdXMgZGlzY3VzcyBhbmQgZXZvbHZlIFVSTnMgaW4gYSB3YXkgdGhhdA0KPiByZXNwb25kcyB0
byBuZWVkcyAtLWFzIGNvbmNyZXRlIGFzIHBvc3NpYmxlLS0gaWRlbnRpZmllZCBieQ0KPiBsZWdp
dGltYXRlIGNvbW11bml0aWVzLCBub3Qgd2hldGhlciB0aGUgcmVzdWx0cyAob3IgdGhpbmtpbmcp
DQo+IGNvbmZvcm0gdG8gc29tZSBub3Rpb25zIGFib3V0IGdlbmVyYWxpemVkIEhUVFAgVVJMcy4g
ICAgQXMgSQ0KPiB0cmllZCB0byBzYXkgaW4gbXkgZWFybGllciBub3RlLCBJJ2QgbGlrZSB0byBt
b3ZlIGF3YXkgZnJvbSB0aGUNCj4gdGVybXMgImZyYWdtZW50IiBhbmQgInF1ZXJ5IiBlbnRpcmVs
eSwganVzdCBiZWNhdXNlIHRoZWlyDQo+IGhpc3RvcmljYWwgYXNzb2NpYXRpb24gd2l0aCAzOTg2
IGNyZWF0ZXMgY29uZnVzaW9uIGFuZCBsZWFkcyB0bw0KPiBkaXNjdXNzaW9ucyB0aGF0IHByaW1h
cmlseSBhcHBseSB0byBVUkxzIChhbmQgbWF5YmUgSFRUUCBVUkxzIGluDQo+IHBhcnRpY3VsYXIp
IGFuZCB3aGV0aGVyIHRob3NlIG90aGVyIHNwZWNzIHJlcXVpcmUgZW50aXJlDQo+IGNvbmZvcm1h
bmNlIG9yIHN1cHBvcnQgb2YgcGFydGljdWxhciBjYXBhYmlsaXRpZXMgaW4gVVJOcy4NCg0KWWVz
LCBpdCBpcyBzdGlsbCB2ZXJ5IG9idmlvdXMgdGhhdCBmcmFnbWVudHMgKGFuZCBxdWVyaWVzKSBj
b21lIGZyb20gaHR0cC4gVGhlIHF1ZXN0aW9uIGlzIGlmIHdlIGNhbiBnZW5lcmFsaXNlIHRoZW0g
dG8gYmUgdXNlZCBpbiBVUk5zLCB0b28uDQoNCj4gSSBub3RlIHRoYXQgdGhpcyAiYmVzdCBwcmFj
dGljZXMiIGRvY3VtZW50IGlzIHN0aWxsIGEgUHJvcG9zZWQNCj4gUmVjb21tZW5kYXRpb24gYW5k
IG5vdCBhdXRob3JpdGF0aXZlLCBldmVuIHdpdGhpbiBXM0MsIGZvciBldmVuDQo+IEhUVFAgVVJM
cy4gIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IGRlYmF0aW5nIHRoZSBwYXJ0aWN1bGFyDQo+IHRlcm1p
bm9sb2d5IHRoZSBlZGl0b3IgdXNlZCBpcyBoZWxwZnVsIHRvIG1ha2luZyBwcm9ncmVzcyBvbg0K
PiBVUk5zIGFuZCwgd2hpbGUgd2UgbWlnaHQgdHJ5IHRvIHVzZSB3aGF0IHdlIHRoaW5rIHdlIGtu
b3cgbm93DQo+IGFib3V0IFVSTnMgdG8gcmVmaW5lIGl0LCBJIHRoaW5rIHN1Y2ggYW4gZWZmb3J0
IHdvdWxkIGltcGVkZQ0KPiBtb3ZpbmcgZm9yd2FyZCB3aXRoIGEgW25vbi1mb3JrZWRdIHVwZGF0
ZWQgVVJOIHNwZWMuICAgUHV0DQo+IGRpZmZlcmVudGx5LCBteSBwcm9wb3NlZCBhbmQgcHJhZ21h
dGljIHBvaW50IG9mIHZpZXcgKGluY2x1ZGluZw0KPiB0aGUgc2VwYXJhdGlvbiBvZiBVUk5zIGZy
b20gdGhlIGdlbmVyaWMgVVJJIHNwZWMpIHNheXMgdGhhdCB0aGlzDQo+IGRvY3VtZW50IGlzIHNp
bXBseSBub3QgcmVsZXZhbnQgdG8gVVJOcyBhbmQgdGhhdCB0cnlpbmcgdG8gbWFrZQ0KPiBpdCBy
ZWxldmFudCAob3IgYXNzZXJ0IGl0cyByZWxldmFuY3kpIGp1c3QgZ2V0cyBpbiBvdXIgd2F5Lg0K
DQpDdXJyZW50bHksIGl0J3MganVzdCBhbiBlZGl0b3IncyBkcmFmdCwgc28geW91IGFyZSBwZXJm
ZWN0bHkgcmlnaHQgdGhhdCBpdCBpcyBpbiBubyB3YXkgYXV0aG9yaXRhdGl2ZS4NCiANCj4gPi4u
Lg0KPiA+IHdvdWxkIGluc3RydWN0IHRoZSBicm93c2VyIHRvIHNlYXJjaCB0aGUgdGhpcmQgb2Nj
dXJyZW5jZSBvZg0KPiA+IHRoZSB0ZXJtIFJGQyBpbiB0aGUgZG9jdW1lbnQuIEJ1dCBkb2VzIHRo
aXMgZnJhZ21lbnQgaWRlbnRpZnkNCj4gPiB0aGF0IHBhcnRpY3VsYXIgd29yZCwgb3IgdGhhdCBs
b2NhdGlvbiBpbiB0aGUgcmVzb3VyY2U/IHx8T3IsDQo+ID4gaWYgdGhlIGZyYWdtZW50IGlzIHRo
ZSBNRDUgY2hlY2tzdW0gb2YgYSBkb2N1bWVudCwgd2hpY2gNCj4gPiBmcmFnbWVudCBvZiB0aGUg
ZG9jdW1lbnQgaXMgaWRlbnRpZmllZD8NCj4gDQo+IEkgd2FudCB0byBzdGF5IHdpdGggImlycmVs
ZXZhbnQiIGFuZCBhd2F5IGZyb20gZGlzdHJhY3Rpb25zLCBidXQNCj4gdGhlIGFib3ZlIGhlbHBz
IHNob3cgd2h5IHRoYXQgcG9zaXRpb24gaXMgaW1wb3J0YW50OiBpZiBvbmUNCj4gYmVsaWV2ZXMg
dGhhdCBVUk5zIGhhdmUgdG8gYmUgc3RhYmxlIGluZGVwZW5kZW50IG9mIHdoYXQgaGFwcGVucw0K
PiB3aXRoIG1ldGhvZC1kZXBlbmRlbnQgImlkZW50aWZpZXJzIiAob3IgImxvY2F0b3JzIiwgZXRj
LiksIHRoZW4NCj4gSSB0aGluayB3ZSBoYXZlIHRvIHNpbXBseSBhdm9pZCBnZXR0aW5nIGVudGFu
Z2xlZCBieSBzdGF0ZW1lbnRzDQo+IGFib3V0IGluc3RydWN0aW9ucyB0byBicm93c2VycyBiZWNh
dXNlIHdlIGNhbm5vdCB0byBrbm93IHdoYXQgYQ0KPiAiYnJvd3NlciIgaXMgd2l0aCBzdWZmaWNp
ZW50IGNsYXJpdHksIGFic3RyYWN0aW9uLCBhbmQNCj4gcGVyc2lzdGVuY2Uvc3RhYmlsaXR5Lg0K
DQpXZSBfY291bGRfIG1ha2Ugc3RhdGVtZW50cyBvZiBob3cgYSBzcGVjLWNvbmZvcm1pbmcgdXNl
ciBhZ2VudCBoYXMgdG8gYmVoYXZlLg0KDQo+ID4gVGVjaG5pY2FsIGlzc3VlcyBhc2lkZSwgdGhl
IGtleSBwcm9ibGVtIGhlcmUgaXMgdGhhdCBmcmFnbWVudA0KPiA+IGFzc2lnbm1lbnQgaXMgY29t
cGxldGVseSB1bi1tYW5hZ2VkIHByb2Nlc3MsIGV2ZW4gbW9yZSBzbyB0aGFuDQo+ID4gbmFtaW5n
IG9mIGZpbGVzIGFuZCBjcmVhdGlvbiBvZiBVUkxzLiBBbnlvbmUgd2hvIHNlZXMNCj4gPiBpZGVu
dGlmaWVyIGFzc2lnbm1lbnQgYXMgc29tZXRoaW5nIGNvbnRyb2xsZWQgc2hvdWxkIGEgcHJpb3Jp
DQo+ID4gaGF2ZSBtYWpvciBpc3N1ZSB3aXRoIHRoZSBpZGVhIG9mICJmcmFnbWVudCBpZGVudGlm
aWVyIi4NCj4gDQo+IFllcy4gIEJ1dCwgZXZlbiB3aGlsZSBJIGFncmVlIHdpdGggdGhhdCBkaXN0
aW5jdGlvbiwgSSB0aGluayBpdA0KPiBsZWFkcyB1cyBhcm91bmQgaW4gYSBjaXJjbGUgYW5kIGJh
Y2sgdG8gYW5vdGhlciBkaXN0cmFjdGlvbi4gIElmDQo+IG9uZSBzdGVwcyBiYWNrIGZyb20gdGhl
IDM5ODYgImdlbmVyaWMiIGRlZmluaXRpb24gYW5kIHRoaW5rcyBvZg0KPiBmcmFnbWVudHMgd2Vy
ZSwgSUlSLCB0aGV5IHN0YXJ0ZWQsIHdlIGVuZCB1cCB3aXRoIHR3byB0eXBlcyBvZg0KPiBwcm90
b3R5cGUgZnJhZ21lbnRzLiAgT25lIGludm9sdmVzIGEgbWFya2VkLXVwIGRvY3VtZW50IChub3QN
Cj4gbmVjZXNzYXJpbHkgSFRNTCBidXQgY2VydGFpbmx5IHRob3VnaHQgb2YgaW4gdGhhdCBjb250
ZXh0KSB3aXRoDQo+IGFuY2hvciBsYWJlbHMgKGRlZmluaXRlbHkgImlkZW50aWZpZXJzIiBpbiB0
aGUgY29udGV4dCBvZiB0aGF0DQo+IGRvY3VtZW50KSBhbmQgdGhlIG90aGVyIGEgY291bnRlZCBv
YmplY3QgaW4gYSBzcGVjaWZpYyBmb3JtIG9mIGENCj4gZG9jdW1lbnQuICBJbiBib3RoIGNhc2Vz
IHRoZSAiZnJhZ21lbnQgaWRlbnRpZmllciIgaXMganVzdCBhDQo+IHBvaW50ZXIgdGhhdCBpcyBh
cyBwZXJzaXN0ZW50IGFzIHRoZSBvYmplY3QgaXRzZWxmLiAgSSBub3RlDQo+IHRoYXQsIGluIGFu
IGFsdGVybmF0ZSByZWFsaXR5LCB0aGF0IHZpZXcgZ2VuZXJhbGl6ZXMuICBGb3INCj4gZXhhbXBs
ZSwgSVNCTnMgY291bGQgaGF2ZSBiZWVuIGRlZmluZWQgdG8gaW5jbHVkZSBudW1iZXJlZA0KPiBj
aGFwdGVycyBhbmQgY2hhcHRlciBkZXNpZ25hdGlvbnMgYXMgYW4gaW50cmluc2ljIHByb3BlcnR5
IG9mDQo+IHRoZSB3b3JrIGJlaW5nIGlkZW50aWZpZWQvbnVtYmVyZWQuICBUaGF0IHdhc24ndCBk
b25lIGZvcg0KPiBfcmVhbGx5XyBnb29kIHJlYXNvbnMsIGJ1dCwgaGFkIGl0IGJlZW4gZG9uZSwN
Cj4gICAgIHVybjppc2JuOi4uLiNDaGFwdGVyMw0KPiB3b3VsZCBoYXZlIGJlZW4gZnVsbHkgYXMg
bWVhbmluZ2Z1bCBhcyBhbiBIVFRQIFVSTCB0aGF0IGxvY2F0ZXMNCj4gYW4gSFRNTCBvYmplY3Qg
YW5kIHRoYXQgY29udGFpbnMgYSBmcmFnbWVudCAiaWRlbnRpZmllciIuDQo+IA0KPiBXaGF0IGlz
IGltcG9ydGFudCBhYm91dCB0aGF0IGh5cG90aGV0aWNhbCB2YXJpYW50IElTQk4gaXMgdGhhdA0K
PiB0aGUgZGVmaW5pdGlvbiBvZiAiZnJhZ21lbnQiIGJlY29tZXMgY29tcGxldGVseSBkZXBlbmRl
bnQgb24gdGhlDQo+IHByb3BlcnRpZXMgb2YgdGhlIE5JRCBkZWZpbml0aW9uLCBqdXN0IGFzIFsx
XSBpcyB2ZXJ5IGRlcGVuZGVudA0KPiBvbiBhc3N1bWVkIHByb3BlcnRpZXMgb2YgSFRUUCBVUkxz
IHRoYXQgcG9pbnQgdG8gSFRNTCBvYmplY3RzLg0KPiBUaGUgcHJvYmxlbSBhcmlzZXMgb25seSB3
aGVuIG9uZSB0cmllcyB0byBtYWtlIGdlbmVyaWMNCj4gc3RhdGVtZW50cyBhYm91dCBVUkxzIChv
ciBnZW5lcmljIFVSSXMpIGluZGVwZW5kZW50IG9mIHdoYXQgdGhleQ0KPiBsb2NhdGUsIGlkZW50
aWZ5LCBvciB3aXRoIHdoaWNoIHRoZXkgYXJlIG90aGVyd2lzZSBhc3NvY2lhdGVkLg0KDQpJIHRo
aW5rIGl0IGhhcyBiZWVuIHNhaWQgb24gdGhpcyBsaXN0IGJlZm9yZSAoYW5kIG5vdyBJIHN0YXJ0
IHRvIHVuZGVyc3RhbmQgdGhhdC4uLikgdGhhdCBvbmUgb2YgdGhlIGZsYXdzIGluIDM5ODYgaXMg
dGhhdCBpdCBpcyBub3Qgb25seSBhYm91dCBzeW50YXgsIGJ1dCBhbHNvIGFib3V0IHNlbWFudGlj
cy4gSXQgd291bGQgaGF2ZSBiZWVuIG11Y2ggZWFzaWVyIGlmIDM5ODYgaGFkIG9ubHkgc3BlY2lm
aWVkIHRoYXQgZnJhZ21lbnRzIGFyZSBhbGxvd2VkIGFuZCB3aGVyZSB0aGV5IGZpdCBpbiB0aGUg
c3ludGF4LCBhbmQgbGVmdCBpdCB0byBpbmRpdmlkdWFsIFVSSSBzY2hlbWFzIHRvIGRlZmluZSB0
aGUgc2VtYW50aWNzLiBUaGUgc2FtZSBhcHBsaWVzIHRvIHF1ZXJpZXMuDQoNClsuLi5dDQoNCj4g
Pj4+IEluIHRoZSBhYm92ZSwgYSBTZXJ2aWNlUmVxdWVzdCBpcywgYWdhaW4gY29uY2VwdHVhbGx5
LCBhDQo+ID4+PiB0dXBsZSBvZg0KPiA+Pj4NCj4gPj4+ICAgICBTZXJ2aWNlVHlwZSBDb21wYXJp
c29uSW5kaWNhdG9yIFNlcnZpY2VUYXJnZXQNCj4gPj4+IFJlZXF1ZXN0UGFyYW1ldGVycy4uLg0K
PiA+Pj4NCj4gPj4+IFNlcnZpY2VUeXBlIGlzIG5vbWluYWxseSBzb21lIHNvcnQgb2Yga2V5d29y
ZC4NCj4gPg0KPiA+IE9LLiBSRkMgMjQ4MyBkZWZpbmVzIGEgaGFuZGZ1bCBvZiB0aGVzZSBrZXl3
b3JkcyBhbmQgc2VydmljZXMsDQo+ID4gYnV0IG5vdCBuZWFybHkgZW5vdWdoLg0KPiANCj4gQW5v
dGhlciBleGFtcGxlIG9mIHdoYXQgSSdtIHRyeWluZyB0byBhdm9pZC4gIEkgYW0gY2VydGFpbiB5
b3VyDQo+IHN0YXRlbWVudCBhYm92ZSBpcyB0cnVlLiAgSSBhbSBlcXVhbGx5IGNlcnRhaW4gdGhl
IHRyeWluZyB0bw0KPiBkZWZpbmUgKG9yIGV2ZW4gYWRlcXVhdGVseSBjaGFyYWN0ZXJpemUpIHRo
ZSBvdGhlcnMgd2lsbCBib2cgdXMNCj4gZG93biBmb3IgYSB2ZXJ5IGxvbmcgdGltZSBhbmQgbGVh
ZCB1cyB0byBQbGFuIEMgb3IgRCBbMl0uICBTbw0KPiBJJ20gdHJ5aW5nIHRvIHB1c2ggdGhhdCBw
cm9ibGVtIGF3YXkgYnkgbWFraW5nIHRob3NlIHNlcnZpY2VzDQo+IGFuZCBrZXl3b3JkcyBhIHBl
ci1OSUQgbWF0dGVyLiAgSWYgaXQgdHVybnMgb3V0IHRoYXQgd2UgY2FuDQo+IGxhdGVyIG1ha2Ug
Z3JvdXBzIG9mIE5JRHMgaW50byBjYXRlZ29yaWVzIHRoYXQgc2hhcmUgc29tZSBzZXQgb2YNCj4g
c2VydmljZXMgYW5kIGtleXdvcmRzLCB0aGF0IHdvdWxkIGJlIGdyZWF0LiAgQnV0LCBpZiB3ZSBt
YWtlDQo+IGRvaW5nIHNvLCBvciBldmVuIHByb3ZpbmcgdGhhdCB3ZSBjYW4gZG8gc28sIGEgY29u
ZGl0aW9uIGZvcg0KPiBVUk5zLCB0aGVuIHdlIHdpbGwgYmUgYmFjayB0byB3aGVyZSB3ZSB3ZXJl
IHdoZW4gSSBmaXJzdCBraWxsZWQNCj4gdGhlIFVSSSBXRy4NCg0KRG9lcyB0aGlzIGltcGx5IHRo
YXQgd2Ugc2hvdWxkIG5vdCB0cnkgdG8gdXBkYXRlIDI0ODMgYXQgYWxsIGJ1dCBpbnN0ZWFkIG1h
a2UgdGhlIHNlcnZpY2UgZGVzY3JpcHRpb24gKGtleXdvcmRzIGV0Yy4pIHBhcnQgb2YgdGhlIE5J
RCByZWdpc3RyYXRpb24gcHJvY2Vzcz8NCg0KPiA+Pj4gQ29tcGFyaXNvbkluZGljYXRvciB0ZWxs
cyBzb21ldGhpbmcgdHJ5aW5nIHRvIGNvbXBhcmUgYSBwYWlyDQo+ID4+PiBvZiBVUk5zIGZvciBp
ZGVudGl0eSB3aGV0aGVyIHRoYXQgcGFydGljdWxhciBTZXJ2aWNlUmVxdWVzdA0KPiA+Pj4gY291
bnRzIG9yIHNob3VsZCBiZSBpZ25vcmVkLg0KPiA+DQo+ID4gSSBhbSBub3Qgc3VyZSBJIHVuZGVy
c3RhbmQgdGhlIG5lZWQgZm9yIENvbXBhcmlzb25JbmRpY2F0b3IuDQo+IA0KPiBJdCBpcyBhIHRy
aWNrIHRvIGF2b2lkIGhhdmluZyB0byByZXNvbHZlIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyDQo+
IGEgcGFydGljdWxhciBTZXJ2aWNlIFJlcXVlc3QgLS1vciBTZXJ2aWNlIFJlcXVlc3RzIGluIGdl
bmVyYWwtLQ0KPiBhcmUgInBhcnQgb2YgdGhlIE5TUyIuICAgSSBjYWxsZWQgaXQgIkNvbXBhcmlz
b25JbmRpY2F0b3IiDQo+IGJlY2F1c2UgSSBiZWxpZXZlIHRoYXQsIGFic2VudCB0aGUgcXVlc3Rp
b24gb2YgY29tcGFyaW5nIGEgcGFpcg0KPiBvZiBVUk5zIGZvciBlcXVhbGl0eSwgdGhlICJwYXJ0
IG9mIHRoZSBOU1MiIHF1ZXN0aW9uIGRvZXNuJ3QNCj4gbmVlZCBhIHByZWNpc2UgYW5zd2VyIGFu
ZCBtaWdodCBiZSBhIGRpc3RyYWN0aW9uLg0KDQpJIHRoaW5rIEkgdW5kZXJzdGFuZCB3aGF0IHlv
dSBhcmUgYWltaW5nIGF0LCBidXQgZG8geW91IHRoaW5rIHlvdSBjb3VsZCBwcm92aWRlIGFuIGV4
YW1wbGUgb3IgdHdvIGp1c3QgZm9yIGNsYXJpdHk/IChObywgSSB3b24ndCBuYWlsIHlvdSBkb3du
IG9uIHN5bnRheC4uLikuDQoNCj4gPj4+IFNlcnZpY2VUYXJnZXQgaWRlbnRpZmllcyB3aGVyZSB0
aGUNCj4gPj4+IFNlcnZpY2VSZXF1ZXN0IGlzIHRvIGJlIHNlbnQgYW5kLCBkZXBlbmRpbmcgb24g
dGhlDQo+ID4+PiBTZXJ2aWNlVHlwZSwgbWF5IGJlIGEga2V5d29yZCBpbmRpY2F0b3Igb3IsIGF0
IHRoZSByaXNrIG9mDQo+ID4+PiBkZXNjZW5kaW5nIGludG8gcmVjdXJzaW9uIGhlbGwsIGEgVVJM
IG9yIFVSTi4NCj4gPg0KPiA+IEluY2x1ZGluZyBTZXJ2aWNlVGFyZ2V0IGludG8gU2VydmljZVJl
cXVlc3QgbWF5IG5vdCBiZQ0KPiA+IG5lY2Vzc2FyeS4gVVJOIHJlc29sdmVyIGFwcHJvcHJpYXRl
IGZvciB0aGUgbmFtZXNwYWNlIGluDQo+ID4gcXVlc3Rpb24gc2hvdWxkIGtub3cgd2hpY2ggc2Vy
dmVyIGlzIGFibGUgdG8gY2F0ZXIgZm9yDQo+ID4gU2VydmljZVJlcXVlc3RzIG9mIGdpdmVuIHR5
cGUuIEZvciBpbnN0YW5jZSwgaWYgYSB1c2VyIHdhbnRzDQo+ID4gZnVsbCBtZXRhZGF0YSBhYm91
dCBhbiBhY2FkZW1pZCBkaXNzZXJ0YXRpb24sIHRoZSByZXNvbHZlcg0KPiA+ICJrbm93cyIgdGhh
dCB0aGUgbmF0aW9uYWwgYmlibGlvZ3JhcGh5IHNob3VsZCBiZSBhYmxlIHRvDQo+ID4gZnVsZmls
bCB0aGUgcmVxdWVzdC4gQnV0IGlmIHRoZSBkb2N1bWVudCBpdHNlbGYgaXMgcmVxdWVzdGVkLA0K
PiA+IG9wZW4gcmVwb3NpdG9yeSAodXNpbmcgRmVkb3JhLCBEU3BhY2Ugb3Igc29tZSBvdGhlciBz
dWNoDQo+ID4gYXBwbGljYXRpb24pIGlzIGJldHRlciBjaG9pY2UuDQo+IA0KPiBJbiB0aGUgbGFu
Z3VhZ2UgSSd2ZSB1c2VkLCB3aGF0IHlvdSBoYXZlIGp1c3Qgc2FpZCBpcyAiZm9yIGFsbA0KPiBO
SURzLCBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gc3BlY2lmeSB0aGUgU2VydmljZVRhcmdldCBh
cyBwYXJ0DQo+IG9mIHRoZSBkZWZpbml0aW9uLyByZWdpc3RyYXRpb24sIHRoZXJlYnkgbm90IHJl
cXVpcmluZyBpdCB0bw0KPiBhcHBlYXIgaW4gdGhlIFNlcnZpY2VSZXF1ZXN0IGFzc29jaWF0ZWQg
d2l0aCBhIFVSTiBhbmQgcHJvYmFibHkNCj4gcHJvaGliaXRpbmcgaXQgdGhlcmUiLiAgICBJZiB0
aGF0IGlzIHRydWUsIGl0IGlzIHdvbmRlcmZ1bC4gIEJ1dA0KPiBJJ20gdHJ5aW5nIHRvIGF2b2lk
IGEgcmVxdWlyZW1lbnQgdG8gcHJvdmUgc3VjaCBzdGF0ZW1lbnRzIGFib3V0DQo+ICJhbGwgTklE
cyIgcmF0aGVyIHRoYW4gcGFydGljdWxhciBOSURzIG9yLCBlLmcuLCBOSURzIHRoYXQgbWlnaHQN
Cj4gc2Vuc2libHkgYmUgdXNlZCBpbiB0aGUgbGlicmFyeSBjb21tdW5pdHkuDQoNClJpZ2h0LiBV
Uk5zIGFyZSB0b28gZGl2ZXJzZSB0aGF0IHdlIGNvdWxkIHNwZWNpZnkgc29tZXRoaW5nIGZvciBh
bGwgb2YgdGhlbS4gQW5vdGhlciBhcmd1bWVudCBmb3IgdGhlIE5JRCBsZXZlbCBvZiBzcGVjaWZp
Y2F0aW9uLg0KDQo+ID4+PiBBbmQgUmVxdWVzdFBhcmFtZXRlcnMgYXJlDQo+ID4+PiBhbnl0aGlu
ZyB0aGUgU2VydmljZVR5cGUgZGVmaW5pdGlvbiBzYXlzIHRoZXkgYXJlLg0KPiA+DQo+ID4gWWVz
LCBhbmQgdGhlIG51bWJlciBvZiBwYXJhbWV0ZXJzIHJlcXVpcmVkIHdpbGwgdmFyeSBhIGxvdA0K
PiA+IGRlcGVuZGluZyBvbiB0aGUgU2VydmljZVR5cGUuDQo+IA0KPiBTbyB0aGVyZSB3ZSBhZ3Jl
ZSBvbiB0aGUgYWJzdHJhY3Rpb24gYW5kIGRlcGVuZGVuY3kgb24gTklELiAgSSdtDQo+IGp1c3Qg
dHJ5aW5nIHRvIGF2b2lkIGEgZGlmZmVyZW50IHZlcnNpb24gb2YgdGhlICJnZW5lcmljDQo+IHNv
bWV0aGluZy1vci1vdGhlciIgdHJhcCBieSBzaW1pbGFybHkgYWJzdHJhY3RpbmcgU2VydmljZVRh
cmdldA0KPiBhbmQgQ29tcGFyaXNvbkluZGljYXRvci4gICBJZiB0aGV5IGNhbiBiZSBrZXB0IGFz
IHBhcnQgb2YgdGhlDQo+IE5JRCBkZWZpbml0aW9ucyBhbmQgY29uc2VxdWVudGx5IGtlcHQgb3V0
IG9mIFVSTiBzdHJpbmdzLCBpdA0KPiB3aWxsIG1ha2UgYSBiZXR0ZXIsIGVhc2llciwgYW5kIGxl
c3MgY29tcGxleCB3b3JsZC4gIEJ1dCBJIGRvbid0DQo+IHNlZSBhbnkgd2F5IHRvIGRlbW9uc3Ry
YXRlIHRoYXQgdGhlcmUgYXJlIG5vIHBvc3NpYmxlIHJlYXNvbmFibGUNCj4gbmFtZXNwYWNlcyBm
b3Igd2hpY2ggZGlmZmVyZW50IGNvbnZlbnRpb25zIG1heSBub3QgYmUgbmVlZGVkLg0KPiBBbmQg
SSBkb24ndCB3YW50IHRoYXQgZGVtb25zdHJhdGlvbi9wcm9vZiB0byBiZSBpbiB0aGUgY3JpdGlj
YWwNCj4gcGF0aC4NCg0KT0suDQoNCj4gPj4+IFJlcXVlc3RzL3NwZWNpZmljYWlvbnMgZm9yIGxv
Y2F0aW9uIGluZm9ybWF0aW9uLCBhc3NvcnRlZA0KPiA+Pj4gbWV0YWRhdGEsIG9yIG1vZGVsIG9y
IGFjdHVhbCBvYmplY3RzIHRoZW1zZWx2ZXMgYXJlIHRoZW4ganVzdA0KPiA+Pj4gc3BlY2lhbGl6
ZWQgU2VydmljZVJlcXVlc3RzLiAgSW4gcGFydGljdWxhciwgIkZyYWdtZW50Ig0KPiA+Pj4gZGlz
YXBwZWFycyBhcyBhIHNwZWNpYWwgdHlwZSBvZiBzeW50YXggYW5kIHJlYXBwZWFycyBhcyBhDQo+
ID4+PiBTZXJ2aWNlIFJlcXVlc3QgdGhhdCBpcyBhcHBsaWNhYmxlIHRvIHNvbWUgTklEcyBhbmQg
bm90DQo+ID4+PiBvdGhlcnMgYW5kIHdob3NlIG1lYW5pbmcgYW5kIGFjdGlvbiAoYW5kIGhvdyBp
dCBpcw0KPiA+Pj4gInJlc29sdmVkIikgYXJlIHNwZWNpZmllZCBvbiBhbiBOSUQgYmFzaXMgYW5k
IGFzIGFib3ZlLg0KPiA+Pj4gIlF1ZXJ5IiBkaXNhcHBlYXJzIHRvbywgbm90IGJlY2F1c2UgaXQg
KG9yIHRoZSBzeW50YXgpIGFyZQ0KPiA+Pj4gbmVjZXNzYXJpbHkgcHJvYmxlbWF0aWMgYnV0IGJl
Y2F1c2UgdGhlIHRlcm0gaXRzZWxmIGlzDQo+ID4+PiBtaXNsZWFkaW5nIGZvciBtYW55IHBvc3Np
YmxlIHR5cGVzIG9mIFNlcnZpY2VSZXF1ZXN0cyBhbmQNCj4gPj4+IHRoZXJlZm9yZSBjYXVzZXMg
bW9yZSBjb25mdXNpb24gdGhhbiBpdCBjbGVhcnMgdXAuDQo+ID4NCj4gPiBJIGFtIG5vdCBzdXJl
IGl0IGlzICBuZWNlc3NhcnkgLyBwcm9kdWN0aXZlIHRvIG1ha2UgZnJhZ21lbnRzDQo+ID4gcmVh
cHBlYXIgYXMgU2VydmljZVJlcXVlc3QuIEFzIEkgc2VlIGl0LCBTZXJ2aWNlIFJlcXVlc3RzIGFy
ZQ0KPiA+IHNvbWV0aGluZyB0aGF0IFVSTiByZXNvbHZlcnMgbXVzdCBkZWFsIHdpdGgsIHdoZXJl
YXMgZnJhZ21lbnRzDQo+ID4gd2lsbCBiZSBwcm9jZXNzZWQgYnkgY2xpZW50cyBzdWNoIGFzIHdl
YiBicm93c2VycywgYm90aCBmb3INCj4gPiBVUkxzIGFuZCBVUk5zLiBBdCBsZWFzdCBmb3Igbm93
IEkgY2Fubm90IHNlZSBhIG5lZWQgZm9yIGENCj4gPiBmcmFnbWVudC1saWtlIFNlcnZpY2UgUmVx
dWVzdCwgb3IgdW5kZXJzdGFuZCBwcm9wZXJseSB3aGF0DQo+ID4gdGhlc2Ugc2VydmljZXMgd291
bGQgYmUgbGlrZS4NCj4gDQo+IFNlZSBhYm92ZSBhbmQgbm90ZSB0aGF0LCBqdXN0IGFzIEknbSBu
b3Qgc3VyZSB0aGF0IGEgZ2VuZXJpYyBVUk4NCj4gZGVmaW5pdGlvbiBuZWVkcyB0byBrbm93IChv
ciBjYW4ga25vdykgd2hhdCBhICJicm93c2VyIiBpcywgSSdtDQo+IG5vdCBjb25maWRlbnQsIGdl
bmVyaWNhbGx5LCB3aGF0IGEgIlVSTiByZXNvbHZlciIgaXMgKG90aGVyDQo+IHRoYW4sIGxpa2Ug
ImJyb3dzZXIiLCBtb3JlIGhhbmR3YXZpbmcpLg0KDQpNeSBkZWZpbml0aW9uIGlzIHRoYXQgYSBV
Uk4gcmVzb2x2ZXIgaXMgYW4gYXBwbGljYXRpb24gdGhhdCBnaXZlbiBhIFVSTiBhbmQgYSBzZXQg
b2Ygc2VydmljZSByZXF1ZXN0cyByZXR1cm5zIHRoZSBvYmplY3QsIG1ldGFkYXRhIG9yIHdoYXRl
dmVyIHRoYXQgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBVUk4gYXMgc3BlY2lmaWVkIGJ5IHRoZSBz
ZXJ2aWNlIHJlcXVlc3RzLg0KDQo+ID4gVXNpbmcgVVJJIHF1ZXJ5IGZvciBwYXNzaW5nIFNlcnZp
Y2VSZXF1ZXN0cyBsb29rcyBsaWtlIGFuDQo+ID4gYXR0cmFjdGl2ZSBvcHRpb24gd2l0aCBtaW5p
bWFsIHRlY2huaWNhbCBvdmVyaGVhZC4gV2hldGhlcg0KPiA+IHRoaXMga2luZCBvZiB1c2Ugb2Yg
cXVlcnkgd291bGQgYmUgY29uZnVzaW5nLCBhbmQgd2hldGhlcg0KPiA+IHVzaW5nIHNvbWUgb3Ro
ZXIgbWVjaGFuaXNtIHdvdWxkIG1ha2UgdGhpbmdzIG1vcmUgY2xlYXIgSQ0KPiA+IGNhbid0IHRl
bGwsIGJlZm9yZSBzZWVpbmcgbW9yZSBkZXRhaWxlZCBwcm9wb3NhbCBvbiBob3cgdG8NCj4gPiBw
cm9jZWVkLiBMaWtlIExhcnMsIEkgd29uZGVyIGlmIHRoZSBpbnRlbnRpb24gaXMgdG8gZHJvcCBq
dXN0DQo+ID4gdGhlIHdvcmQgcXVlcnksIG9yIHRoZSBzeW50YXggYXMgd2VsbC4NCj4gDQo+IEJv
dGguICBQb3NzaWJseSB3ZSBjb3VsZCBwcmVzZXJ2ZSB0aGUgc3ludGF4LCBidXQgSSB0aGluayB0
aGF0DQo+IHJlcXVpcmVzIHRoYXQgc29tZW9uZSBtYWtlIHRoZSBjYXNlIHRoYXQgdGhlIGFkdmFu
dGFnZXMgb2YgZG9pbmcNCj4gc28gb3V0d2VpZ2ggdGhlIGRpc2FkdmFudGFnZXMuICBJbiBwYXJ0
aWN1bGFyLCBpZiB0aGUgdHVwbGUNCj4gZGVzY3JpYmVkIGFib3ZlIGV2ZXJ5IGFjdHVhbGx5IG5l
ZWRzIHRvIGJlIHByZXNlbnQgaW4gYSBVUk4NCj4gc3RyaW5nLCBJJ20gbm90IHN1cmUgdGhlIGV4
aXN0aW5nIHN5bnRheCB3b3JrcyB3aXRob3V0IGEgZ3JlYXQNCj4gZGVhbCBvZiBjb25mdXNpbmcg
YW5kIGVycm9yLXByb25lIGNsdXR0ZXIuDQoNCkFzIHNhaWQsIHRvIG1lIHRoZXJlIGlzIHZhbHVl
IGluIGtlZXBpbmcgVVJOcyBhcyBhIHN1YmNsYXNzIG9mIFVSSXMuDQogDQo+IC0tT24gVGh1cnNk
YXksIEp1bmUgMjYsIDIwMTQgMTA6MjcgKzAwMDAgIlN2ZW5zc29uLCBMYXJzIg0KPiA8TC5TdmVu
c3NvbkBkbmIuZGU+IHdyb3RlOg0KPiANCj4gPj4gVHdvIFVSTnMgc2hvdWxkIGJlIGNvbnNpZGVy
ZWQgdG8gYmUgZXF1aXZhbGVudCBpZiB0aGV5DQo+ID4+IGlkZW50aWZ5IHRoZSBzYW1lIHRoaW5n
Lg0KPiA+DQo+ID4gWWVzLCBhbmQgdGhpcyBkZXBlbmRzIG9uIHlvdXIgZGVmaW5pdGlvbiBvZiAi
dGhpbmciLi4uDQo+IA0KPiBJbmRlZWQuICBBbmQgSSdtIGVzc2VudGlhbGx5IHN1Z2dlc3Rpbmcg
dGhhdCwgaW4gdGhlIGdlbmVyYWwNCj4gY2FzZSwgd2UgZG9uJ3Qga25vdyBob3cgdG8gZGVmaW5l
ICJ0aGluZyIgZXhjZXB0IG9uIGENCj4gcGVyLW5hbWVzcGFjZSAoTklELWRlcGVuZGVudCkgYmFz
aXMuICBJIGJlbGlldmUgdGhlcmUgbWF5IGJlDQo+IGNhdGVnb3JpZXMgb2YgbmFtZXNwZWFjZXMg
KGFuZCBOSURzKSB0aGF0IHdvdWxkIHNoYXJlDQo+IHRoaW5nLWRlZmluaXRpb25zIGJ1dCB3ZSBo
YXZlbid0IGV2ZW4gYmVndW4gdG8gdGFsayBhYm91dCBzdWNoDQo+IGNhdGVnb3JpZXMsIG11Y2gg
bGVzcyB0aGVpciBkZWZpbml0aW9ucyBhbmQgcHJvcGVydGllcy4NCj4gSG93ZXZlciwgSSB0aGlu
ayB3ZSBjYW4gZGVtb25zdHJhdGUgdGhhdCB0aGUgZGlmZmVyZW5jZXMgZXhpc3QNCj4ganVzdCBi
eSBsb29raW5nIGF0IHRoZSBkaWZmZXJlbmNlcyBpbiBzdGFydGluZyBwb2ludCwgbGFuZ3VhZ2Us
DQo+IGFuZCBhc3N1bXB0aW9ucyBiZXR3ZWVuIEp1aGEgYW5kIERhbGUgLS0gYm90aCBvZiB3aG9t
LCBJJ20NCj4gY29udmluY2VkIGFyZSBhY3RpbmcgaW4gZ29vZCBmYWl0aCBhbmQgd2l0aCBhIGdv
b2QgdW5kZXJzdGFuZGluZw0KPiB0byB0aGUgcHJvYmxlbXMgdGhleSBuZWVkIHRvIHNvbHZlIGZv
ciB0aGVpciBjb21tdW5pdGllcy4NCj4gDQo+ID4uLi4NCj4gPj4gLi4uYmVjYXVzZSBuZWl0aGVy
IGZyYWdtZW50IG5vciBxdWVyeSBhcmUgcGFydCBvZiB0aGUgTlNTLg0KPiA+DQo+ID4gSW4gbXkg
ZXllcywgdGhhdCBpcyBub3QgYSBzdHJvbmcgZW5vdWdoIGFyZ3VtZW50IHNpbmNlIHRoYXQgaXMN
Cj4gPiBvYnZpb3VzIGZyb20gdGhlIHN5bnRheCB1cm46bmlkOm5zcz9xdWVyeSNmcmFnbWVudC4g
V2UgbmVlZCBhbg0KPiA+IGV4cGxpY2l0IHN0YXRlbWVudCB0aGF0IHNheXMgdGhhdCAiZm9yIGlk
ZW50aWZpY2F0aW9uDQo+ID4gcHVycG9zZXMsIHRoZSBVUk4gZW5kcyBhZnRlciB0aGUgbGFzdCBj
aGFyYWN0ZXIgb2YgdGhlIE5TUy4NCj4gPiBUaGlzIGltcGxpZXMgdGhhdCB3aGlsZSBhIGdlbmVy
aWMgVVJJIHBhcnNlciB3b3VsZCBjb25zaWRlcg0KPiA+IHRoZSB0d28gVVJJcyB1cm46ZXhhbXBs
ZTpmb28gYW5kIHVybjpleGFtcGxlOmZvbz9iYXIjYmF6IHR3bw0KPiA+IGRpZmZlcmVudCBVUklz
IGFuZCB0aHVzIC0tIHdpdGhvdXQgZnVydGhlciBrbm93bGVkZ2UgLS0NCj4gPiBpZGVudGlmeWlu
ZyB0d28gZGlmZmVyZW50IHJlc291cmNlcywgYSBVUk4gcGFyc2VyIHdvdWxkIHRyZWF0DQo+ID4g
dGhlbSBhcyBlcXVpdmFsZW50LiIgKE9yIHNvbWV0aGluZyBhbG9uZyB0aG9zZSBsaW5lcywgd2hp
Y2ggSQ0KPiA+IGNhbm5vdCBmaW5kIGluIDIxNDFiaXMpLiBJIGFsc28gc3VnZ2VzdCB0aGF0IHJm
YyAyMTQxYmlzIGFkZHMNCj4gPiBzb21lIGV4YW1wbGVzIHdpdGggcXVlcmllcyBhbmQgZnJhZ21l
bnRzIHRvIMKnNi4xLg0KPiANCj4gU2VlIGFib3ZlIGFuZCBub3RlIHRoYXQsIGlmIFVSTnMgYXJl
IG5vdCBVUklzLCB0aGVuLCBpZiB0aGVyZSBpcw0KPiBzdWNoIGEgdGhpbmcgYXMgYSAiZ2VuZXJp
YyBVUkkgcGFyc2VyIiwgaXQgZG9lc24ndCBpbmhlcmVudGx5DQo+IGFwcGx5IHRvIFVSTnMuICBU
aGF0LCBpbiB0dXJuLCB0YWtlcyB1cyBiYWNrIHRvIGEgY29tbWVudCBvZg0KPiBzb21lIG1vbnRo
cyBhZ28gYWJvdXQgYSBnZW5lcmljIFVSSSByZWFsbHkgY29uc2lzdGluZyBvZiBhDQo+IG1ldGhv
ZCBmb2xsb3dlZCBieSBtZXRob2QtZGVwZW5kZW50ICJzdHVmZiIuDQo+IA0KPiA+Li4uDQo+ID4+
ICBGcm9tIHRoZSBVUk4gcG9pbnQgb2YgdmlldyBmcmFnbWVudHMgaGF2ZSBub3RoaW5nIHRvIGRv
IHdpdGgNCj4gPj4gaWRlbnRpZmljYXRpb24uIE5hdGlvbmFsIGxpYnJhcmllcyBhbmQgb3VyIGFs
bGllcyBhc3NpZ24NCj4gPj4gdXJuOm5ibnMgdG8gcmVzb3VyY2VzLCBidXQgdHlwaWNhbGx5IGl0
IHdpbGwgYmUgdGhlIHVzZXJzIG9mDQo+ID4+IHRoZXNlIHJlc291cmNlcyB3aG8gd2lsbCBhZGQg
ZnJhZ21lbnRzIHRvIHRoZSB1cm5zIHdoZW4gdGhleQ0KPiA+PiBjaXRlIGlkZW50aWZpZWQgcmVz
b3VyY2VzLg0KPiA+DQo+ID4gVGhpcyBtYWtlcyB0aGUgdXNlcnMvcGF0cm9ucyByZXNwb25zaWJs
ZSBmb3IgdXNpbmcgdGhlIGNvcnJlY3QNCj4gPiBmcmFnbWVudCBpZGVudGlmaWVyIHN5bnRheCBm
b3IgdGhlIG1lZGlhIHR5cGUgaW4gdXNlLCB3aGljaA0KPiA+IHJlcXVpcmVzIGdvb2QgdG9vbCBz
dXBwb3J0LiBQZXJoYXBzIHdlIG5lZWQgc29tZSB1c2UgY2FzZXMgdG8NCj4gPiBpbGx1c3RyYXRl
IGhvdyB0aGlzIHdvdWxkIHdvcmsuDQo+IA0KPiBJdCBpcyBtb3JlIHRoYW4gImdvb2QgdG9vbCBz
dXBwb3J0IiB1bmxlc3MgdGhlIHRvb2xzIHRoZW1zZWx2ZXMNCj4gYXJlIHRvIGJlY29tZSBkZSBm
YWN0byBwYXJ0IG9mIHRoZSBVUk4gZGVmaW5pdGlvbiBhbmQgYXQgbGVhc3QNCj4gYXMgcGVybWFu
ZW50LyBwZXJzaXN0ZW50IGFzIHRoZSBkZWZpbml0aW9uIGl0c2VsZi4gIEkgZG9uJ3Qgc2VlDQo+
IHRoYXQgYXMgaW1wb3NzaWJsZSwganVzdCB1bmxpa2VseS4NCg0KV2UgY2FuIGRlZmluZSBiZWhh
dmlvdXIgZm9yIGNvbmZvcm1pbmcgYWdlbnRzLCBqdXN0IGFzIG90aGVyIHNwZWNpZmljYXRpb25z
IGRvLg0KDQo+ID4+IEl0IGlzIHVuZm9ydHVuYXRlIHRoYXQgVVJJIGdlbmVyaWMgc3ludGF4IHRh
bGtzIGFib3V0IGZyYWdtZW50DQo+ID4+IGlkZW50aWZpZXJzLiBXZSBzaG91bGQgbm90IGRvIHRo
ZSBzYW1lIG1pc3Rha2UsIHNpbmNlIGl0IGlzDQo+ID4+IHZlcnkgdW5jbGVhciB3aGF0IGZyYWdt
ZW50cyBjb3VsZCBhY3R1YWxseSBpZGVudGlmeSBhbmQgaG93DQo+ID4+IHN1Y2ggZnJhZ21lbnQt
ZHJpdmVuIGlkZW50aWZpY2F0aW9uIHByb2Nlc3Mgd291bGQgYmUgbWFuYWdlZA0KPiA+PiBwcm9w
ZXJseS4gQSBsYXkgcGVyc29uIG1heSBub3Qgc2VlIGFueSBwcm9ibGVtcyBoZXJlLCBidXQgaW4N
Cj4gPj4gdGhpcyByZXNwZWN0IG15IHBvaW50IG9mIHZpZXcgaXMgb25lIG9mIGEgcHJvZmVzc2lv
bmFsIHdobw0KPiA+PiBoYXMgYmVlbiBjbG9zZWx5IGludm9sdmVkIHdpdGggZGV2ZWxvcG1lbnQg
YW5kIHVzZSBvZiBJU08NCj4gPj4gaWRlbnRpZmllciBzdGFuZGFyZHMgZm9yIGFib3V0IDIwIHll
YXJzLg0KPiA+DQo+ID4gWWVzLCB0ZXJtaW5vbG9neSBjYW4gYmUgYSBQSVRBLCBidXQgdGhhdCdz
IG5vdGhpbmcgd2UgY2FuDQo+ID4gY2hhbmdlIChtb2R1bG8gdXBkYXRpbmcgMzk4NikuDQo+IA0K
PiBPciBzZXBhcmF0aW5nIFVSTnMgZnJvbSAzOTg2IGFuZCB0aGVuIGRlZmluaW5nIHdoYXRldmVy
IGlzDQo+IG5lZWRlZCB0byBiZSBkZWZpbmVkIGZvciBVUk5zIGluIGEgVVJOLWFwcHJvcHJpYXRl
IHdheS4gIFRoYXQgaXMNCj4gZXhhY3RseSB3aGF0ICJQbGFuIEIiIFsyXSBhbmQgIlVSTnMgYXJl
IG5vdCBVUklzIiBhcmUgYWJvdXQuDQoNClNpbmNlICJVUk5zIGFyZSBub3QgVVJJcyIgcmVxdWVz
dHMgYW4gdXBkYXRlIG9mIDM5ODYgYW55d2F5LCB3aHkgY2FuJ3Qgd2UgdHJ5IHRvIG1vdmUgdGhl
IF9zZW1hbnRpY3NfIG9mIGZyYWdtZW50IG91dCBvZiBpdCBhbmQgaW50byB0aGUgaHR0cCBzcGVj
aWZpY2F0aW9uIGluc3RlYWQ/DQoNCj4gPj4gR2VuZXJhbGx5IHNwZWFraW5nLCBmcmFnbWVudHMg
Y2FuIGJlIGFkZGVkIHRvIFVSTnMgd2hpY2gNCj4gPj4gaWRlbnRpZnkganVzdCBhIHNpbmdsZSBt
YW5pZmVzdGF0aW9uIG9mIGEgcmVzb3VyY2UgYW5kIHRoZQ0KPiA+PiBtaW1lIHR5cGUgb2YgdGhl
IHJlc291cmNlIGFsbG93cyBmcmFnbWVudCB1c2FnZS4gVGhlcmUgYXJlDQo+ID4+IHBsZW50eSBv
ZiBuYW1lc3BhY2VzIGFuZCBtaW1lIHR5cGVzIHdoaWNoIG1lZXQgdGhlc2UNCj4gPj4gcmVxdWly
ZW1lbnQuIFRoZSByZXF1aXJlbWVudCBmb3IgYmVpbmcgYWJsZSB0byB1c2UgZnJhZ21lbnQNCj4g
Pj4gZG9lcyBub3QgcmVhbGx5IGNvbWUgb25seSBmcm9tIHRoZSB1cm46bmJuIGNvbW11bml0eS4g
QWRkaW5nDQo+ID4+IGZyYWdtZW50IHRvIHRoZSBVUk4gc3ludGF4IGhhcyBtb3JlIHRvIGRvIHdp
dGggdGhlIG5lZWRzIG9mDQo+ID4+IHRoZSBwZW9wbGUgd2hvIHdpbGwgY2l0ZSByZXNvdXJjZXMg
d2hpY2ggaGF2ZSBhbHJlYWR5IGJlZW4NCj4gPj4gaWRlbnRpZmllZCB3aXRoIFVSTnMgd2hpY2gg
dGhlbiBwcm92aWRlIGFjY2VzcyB0byB0aGVzZQ0KPiA+PiByZXNvdXJjZXMuIElNTyBwZW9wbGUg
d2lsbCBhZGQgZnJhZ21lbnRzIHRvIFVSTnMgbm8gbWF0dGVyDQo+ID4+IHdoYXQgdGhlIFVSTiBz
eW50YXggc2F5cy4gQnV0IGlmIHRoZSBVUk4gc3ludGF4IHNheXMgbm90aGluZw0KPiA+PiBhYm91
dCBmcmFnbWVudHMsIHRoZW4gVVJJIHN5bnRheCBhcHBsaWVzLCB3aGljaCBtZWFucyB0aGF0DQo+
ID4+IGV2ZXJ5b25lIHdobyBjaXRlcyBhIHJlc291cmNlIGlkZW50aWZpZXMgc29tZXRoaW5nIChs
b2NhdGlvbg0KPiA+PiBvciBzZWdtZW50IG9yIHNvbWV0aGluZyBlbHNlKSB3aXRoaW4gdGhhdCBy
ZXNvdXJjZSBieSB0aGUgYWN0DQo+ID4+IG9mIGNpdGluZywgd2hpY2ggc291bmRzIGFic3VyZCAo
YW5kIHVubWFuYWdlYWJsZSkgdG8gbWUuDQo+ID4NCj4gPiBJZiB3ZSBkb24ndCBhZGQgZnJhZ21l
bnRzIHRvIHRoZSBVUk4gc3ludGF4LCBhIFVSTiB3aXRoIGFuDQo+ID4gYWRkZWQgZnJhZ21lbnQg
c2ltcGx5IHdpbGwgbm90IGJlIGEgdmFsaWQgVVJOLi4uDQo+IA0KPiBSaWdodC4gIEFuZCBJJ20g
dHJ5aW5nIHRvIGVuY291cmFnZSBtYWtpbmcgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuDQo+ICJ0aGUg
ZnVuY3Rpb25hbGl0eSB0aGF0IHRoZSB1cm46bmJuIGNvbW11bml0eSAoYW5kIG90aGVyDQo+IGNv
bW11bml0aWVzKSBuZWVkIGZyb20gImZyYWdtZW50IiBhbmQgdGhlIHN5bnRheCBhbmQgc2VtYW50
aWNzDQo+IGF0dGFjaGVkIHRvIHRoYXQgdGVybSBieSAzOTg2IGFuZCBvdGhlciBVUkwtZGVyaXZl
ZCBkb2N1bWVudHMuDQo+IA0KPiAgYmVzdCwNCj4gICAgIGpvaG4NCj4gDQo+IA0KPiBbMV0gaHR0
cDovL3d3dy53My5vcmcvMjAwMS90YWcvZG9jL21pbWVUeXBlc0FuZEZyYWdpZHMNCj4gDQo+IFsy
XSAgRnJvbSBteSBwb2ludCBvZiB2aWV3LCB3ZSBoYWQgdG8gbW92ZSBiZXlvbmQgIlBsYW4gQSIg
d2hlbg0KPiB0cnlpbmcgdG8gbWVldCBldmVyeW9uZSdzIHBlcmNlaXZlZCBuZWVkcyB3aGlsZSBz
dGF5aW5nIHdpdGhpbg0KPiB0aGUgYm91bmRhcmllcyBlc3RhYmxpc2hlZCBieSBSRkMgMzk4NiBh
bmQgaXRzIHBlbnVtYnJhDQo+IChpbmNsdWRpbmcgWzFdIGFuZCBzZXZlcmFsICJVUkxzIGFyZSBz
dWZmaWNpZW50IiBhc3N1bXB0aW9ucykuDQo+ICJQbGFuIEIiIHNlcGFyYXRlcyBVUk5zIGZyb20g
Z2VuZXJpYyBVUkxzLCBpbiB0aGUgIlVSTnMgYXJlIG5vdA0KPiBVUklzIiBzcGVjIG9yIGluIHNv
bWUgb3RoZXIgd2F5LiAgSWYgdGhhdCBmYWlscywgdGhlbiB3ZSB3aWxsDQo+IG5lZWQgdG8gZWl0
aGVyIHN0YXJ0IHRoaW5raW5nIGFib3V0IGhvdyB0byBtYW5hZ2UgYSBmb3JrZWQNCj4gc3BlY2lm
aWNhdGlvbiB3aXRoIG5vdC1xdW90ZS1jb21wYXRpYmxlIGJyYW5jaGVzIG9yIHdpdGggZ2V0dGlu
Zw0KPiByaWQgb2YgVVJOcyBpbiBmYXZvciBvZiBmaWVsZC1zcGVjaWZpYyBVUiosIHBvc3NpYmx5
IHN0YXJ0aW5nDQo+IHdpdGggVVJTcyAoVW5pZm9ybSBSZXNvdXJjZSBTTkFGVSkuDQo+IA0KPiBb
M10gRGlzY2xhaW1lcjogRm9yIGJldHRlciBvciB3b3JzZSwgSSBoYWQgc2V2ZXJhbCBpbnRlcmVz
dGluZw0KPiBjb252ZXJzYXRpb25zIHllc3RlcmRheSBhYm91dCBOb3JiZXJ0IFdpZW5lcidzIGxl
Z2FjeSAoaW5jbHVkaW5nDQo+IGJ1dCBub3QgbGltaXRlZCB0byAiQ3liZXJuZXRpY3MiKSBhbmQg
aXRzIDIxc3QgQ2VudHVyeQ0KPiBpbXBsaWNhdGlvbnMsIHBhcnRpY3VsYXJseSBhYm91dCB0aGUg
aW1wb3J0YW5jZSBvZiByaWdvciBhbmQNCj4gcHJlY2lzaW9uIGluIGRpc2N1c3Npb25zIGF0IHRo
ZSBtYW4tbWFjaGluZSBib3VuZGFyeS4gIFdoaWxlDQo+IHRob3NlIGRpc2N1c3Npb25zIGNsZWFy
bHkgcG9zdGRhdGUgbXkgdGhpbmtpbmcgb2YgdGhlIGxhc3QNCj4gc2V2ZXJhbCBtb250aHMgKGFu
ZCwgaW4gcGFydGljdWxhciwgdGhlICJVUk5zIGFyZSBub3QgVVJJcyIgc3BlYw0KPiBhbmQgbXkg
ZWFybGllciBjb21tZW50cyBpbiB0aGlzIHRocmVhZCksIHRoZXkgYWxtb3N0IGNlcnRhaW5seQ0K
PiBjb250cmlidXRlIHRvIHdoYXRldmVyIGltcGF0aWVuY2UgY29tZXMgdGhyb3VnaCBpbiB0aGlz
IG5vdGUNCj4gYWJvdXQgbWFraW5nIGJyb2FkIGdlbmVyYWxpemF0aW9ucyBhYm91dCBjYXRlZ29y
aWVzIHRoYXQgY2Fubm90DQo+IGJlIGZ1bGx5IGlkZW50aWZpZWQgKGFuZCBzeW50YXggYW5kIG90
aGVyIHJ1bGVzIGJhc2VkIG9uIHRob3NlDQo+IGdlbmVyYWxpemF0aW9ucykuICBBcyB3YXMgdGhl
IGNhc2UgdHdvIGRlY2FkZXMgYWdvLCBJIHdhbnQgdG8NCj4gc2VlIGlmIHdlIGNhbiBkZWZpbmUg
VVJOcyB3aXRob3V0IGZhbGxpbmcgaW50byB0aGF0IHRyYXAuDQo+IA0KDQo=


From nobody Sun Jun 29 00:46:18 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF291A03CF for ; Sun, 29 Jun 2014 00:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.551
X-Spam-Level: 
X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 URZVDCy6Po1S for ; Sun, 29 Jun 2014 00:46:13 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7031A02F5 for ; Sun, 29 Jun 2014 00:46:13 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X19lT-000Nts-8s; Sun, 29 Jun 2014 03:43:07 -0400
Date: Sun, 29 Jun 2014 03:45:56 -0400
From: John C Klensin 
To: "Svensson, Lars" , Juha Hakala , "Dale R. Worley" 
Message-ID: 
In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA445F063@dnbf-ex1.AD.DDB.DE>
References: <24637769D123E644A105A0AF0E1F92EFA445F063@dnbf-ex1.AD.DDB.DE>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/iBEgWe7H6sthV4G-DNWQGDx24RU
Cc: urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 07:46:17 -0000

--On Friday, June 27, 2014 15:39 +0000 "Svensson, Lars"
 wrote:

> John,
>=20
>> Some comments below, mostly to clarify my earlier note to
>> which both of you partially responded.  First, and most
>> important, please understand that, while I have biases and
>> opinions about URNs and their proper definition and use, I'm
>> trying to be completely pragmatic about this.  That means I
>> am putting three strategic principles ahead of declarations
>> about what is or is not correct from some perspective.  Those
>> pragmatic principles are
>>=20
>>  -- try to accommodate all of those who think URNs are
>> 	necessary, i.e., that they are distinct from URLs.
>=20
> Well, of course they are.

Unless I've misunderstood a number of remarks, your "of course"
view is not universally shared.

> I think we get bogged down with the
> question, if URNs are a subclass of URIs or not. I try to
> argue that URNs _should_ be a subclass of URIs for the simple
> reason that it allows me to use a URN in all places where a
> URI is expected, e. g. as an XML namespace identifier, or in a
> SemWeb/LinkedData setting, where identifiers for entities are
> requested to be URIs. This is not only a concern about
> breaking backward compatibility, but also a marketing issue:
> One of our selling points when we try to convince people to
> use URNs is exactly the point that they are URIs, too and that
> all the usages mentioned above are open to them.

First, I think "a URN can be used in all places where a URI is
expected" is, operationally, something of a fantasy.  The
problem is that we have URNs for which "resolution" is
meaningless and so is any "use" other than "ok, the syntax works
and nothing will break in parsing"  (the latter argument would
have been stronger if we had adopted the requirement that URIs
be clearly delimited, or at least clearly (and unambiguously and
consistently) terminated, in running text).   Arguably a
statement like "a URI can be used anywhere a URI can be used",
however tautological-sounding, is a fantasy too.  The difficulty
is that we don't have a URI syntax definition that is =
ultimately:

   Method:  

Instead, we have a lot of Method-dependent stuff that affects
how the rest of the URI (whatever that means) is parsed and
interpreted.  If some program doesn't understand the Method in
context, all it can do is parse the URI away from other text
and, I believe in principle, might not even be able to do that.
Knowing that it can break the URI into enough pieces to pass the
components to a generic API really just kicks the proverbial can
down the road -- that API must still have method-dependent
actions to make any use of the material or it needs a good way
to back out and deliver a failure message to the user -- one
that should really be better than "Huh?" but often isn't.

All of that said, it would be perfectly reasonable to not go as
far as "URNs are not URIs" but instead rip all of the semantics
and maybe some of the syntax restrictions out of 3986.   As I
said in earlier notes and, to some degree, in the document, it
would be a lot of work to pick 3986 apart and would be hard to
get consensus because that sort of revision would require
agreement across the whole URI community.  I'm not willing to do
that work (even if I had time, which I don't), in part because I
see other developments making it irrelevant.  And I think that
holding URNs hostage until it is done guarantees a fork or
worse.   But, if you want to take it on, go to it.

>...

>> Here, as elsewhere in this note, the principles above cause =
me
>> to take a position very different from where you (and Lars)
>> are going -- not contradictory, but orthogonal.  Because of
>> those principles and the question of the legitimacy of URNs
>> as a construction separate from URLs (or URLs generalized
>> into URIs),
>=20
> This seems to be the place where we need to find a common view
> on things. My reading is that URIs (as defined by 3986) are
> _always_ identifiers and that _some_ URIs (depending on their
> scheme) are also locators. To the "pure identifiers" I count
> e. g. geo:, xcon: and crid: (and urn:), while e. g. http:,
> ftp: and smtp: would be locators as well. So in my view, we
> cannot generalise URLs into URIs, which would allow us to keep
> URNs as a subclass of URIs.

As I've tried to say before, I think that a philosophical debate
about the precise proper usage of the term "identifier" is
extremely interesting but doesn't lead us anywhere on which
agreement is likely in the foreseeable future.  That makes one
important question whether we are willing to delay any progress
on URNs until we do agree.

However, "we cannot generalise URLs into URIs,..." is a
statement with which I've come to agree.   RFC 3986 is precisely
a generalization of URLs into URI.  Yet another view of it is
that it attempted the impossible (or contradictory) and failed.
So where does that leave us?

>=20
>> I believe the document cited [1] is simply irrelevant.   I
>> really want to see us discuss and evolve URNs in a way that
>> responds to needs --as concrete as possible-- identified by
>> legitimate communities, not whether the results (or thinking)
>...

> Yes, it is still very obvious that fragments (and queries)
> come from http. The question is if we can generalise them to
> be used in URNs, too.

I think the question is a little different.  I'd like to see us
start by either figuring out what functionality we need across
the whole family of potential URNs, at least temporarily
avoiding the terms "fragment" and "query" because they carry
both syntactic and semantic baggage with them, and only then
asking how closely we can adapt those answers to the general URI
framework.  Maybe things could have worked out differently,
especially if 3986 were better designed and written, but, today,
"generalise them to
> be used in URNs" has too many aspects of a Procrustean
solution.

>...
>> I want to stay with "irrelevant" and away from distractions,
>> but the above helps show why that position is important: if
>> one believes that URNs have to be stable independent of what
>> happens with method-dependent "identifiers" (or "locators",
>> etc.), then I think we have to simply avoid getting entangled
>> by statements about instructions to browsers because we
>> cannot to know what a "browser" is with sufficient clarity,
>> abstraction, and persistence/stability.
>=20
> We _could_ make statements of how a spec-conforming user agent
> has to behave.

Yes.  But the IETF (as distinct from, e.g., W3C) generally
avoids making statements about user agent behavior.  More
important, because, while all URLs must be resolvable in at
least some general sense, we've seen several examples of URNs
that are not resolvable or intended to be resolved.  A statement
about user agent conformity that would be broad enough to cover
all of those cases would probably not be useful.  Or perhaps I
don't understand what you have in mind.

>...
> I think it has been said on this list before (and now I start
> to understand that...) that one of the flaws in 3986 is that
> it is not only about syntax, but also about semantics. It
> would have been much easier if 3986 had only specified that
> fragments are allowed and where they fit in the syntax, and
> left it to individual URI schemas to define the semantics. The
> same applies to queries.

Yes, see above.

> [...]
>=20
>> >>> In the above, a ServiceRequest is, again conceptually, a
>> >>> tuple of
>> >>>=20
>> >>>     ServiceType ComparisonIndicator ServiceTarget
>> >>> ReequestParameters...
>> >>>=20
>> >>> ServiceType is nominally some sort of keyword.
>> >=20
>> > OK. RFC 2483 defines a handful of these keywords and
>> > services, but not nearly enough.
>>=20
>> Another example of what I'm trying to avoid.  I am certain
>> your statement above is true.  I am equally certain the
>> trying to define (or even adequately characterize) the others
>> will bog us down for a very long time and lead us to Plan C
>> or D [2].  So I'm trying to push that problem away by making
>> those services and keywords a per-NID matter.  If it turns
>> out that we can later make groups of NIDs into categories
>> that share some set of services and keywords, that would be
>> great.  But, if we make doing so, or even proving that we can
>> do so, a condition for URNs, then we will be back to where we
>> were when I first killed the URI WG.
>=20
> Does this imply that we should not try to update 2483 at all
> but instead make the service description (keywords etc.) part
> of the NID registration process?

Two separate questions.  First, 2483 (and the relevant
DDDS-specific specs) are mostly irrelevant to this discussion
and have been overtaken by events, especially the event of
indicator-style (never resolved) URNs.  I presume it is not an
accident that work on them was never part of the URNbis charter.
And, yes, I think any service descriptions have to be part of
the registration process... and that 3406 already goes a
significant distance in that direction.

>> >>> ComparisonIndicator tells something trying to compare a
>> >>> pair of URNs for identity whether that particular
>> >>> ServiceRequest counts or should be ignored.
>...
>> It is a trick to avoid having to resolve the question of
>> whether a particular Service Request --or Service Requests in
>> general-- are "part of the NSS".   I called it
>> "ComparisonIndicator" because I believe that, absent the
>> question of comparing a pair of URNs for equality, the "part
>> of the NSS" question doesn't need a precise answer and might
>> be a distraction.
>=20
> I think I understand what you are aiming at, but do you think
> you could provide an example or two just for clarity? (No, I
> won't nail you down on syntax...).

For "ComparisonIndicator", I'm worried about, and trying to
evade, the argument about whether Service Requests are, or are
not, enough part of the URN to effect whether or not two
URN-strings compare equal.  So (and again with the understanding
that there are lots of ways to do with syntax and defaults,
suppose we defined two categories of Service Requests, one of
which was considered integral to the URN (i.e., that, if a
particular request appeared in one URN-string but not another,
the two URNs would be treated as not equal) and one that was
not.  Now, suppose (I hope you can render UTF-8 because, for
this example, I need to choose delimiters that are not
complicated by 3986 -- if you cannot, the two funny characters
below are U+2191, upwards arrow, and U+2193, downwards arrow,
respectively) that, rather than using "?" to introduce both
categories on the assumption that all Service Requests are
queries, we had=20

   =E2=86=91ServiceRequest
denoting the integral ones and
   =E2=86=93ServiceRequst=20
denoting the non-integral ones

Then=20
   urn:xxx:string=E2=86=91foo  and urn:xxx:string=E2=86=91bar =
would compare
"not equal"
but
   urn:xxx:string=E2=86=93foo  and urn:xxx:string=E2=86=93bar =
would be
considered equal URNs.

If my interpretation of Juha's comments is correct and he is
correct that we would never need the first case ("=E2=86=91") =
than
that would be fine -- we'd just never see that delimiter and
everyone would be happy.  But I want to avoid getting a
correctness proof on "Service Requests are never to be
considered part of the NSS" in our critical path if we possibly
can.  Something like the above may be a way to make that
separation.

>...
>> In the language I've used, what you have just said is "for =
all
>> NIDs, it should be possible to specify the ServiceTarget as
>> part of the definition/ registration, thereby not requiring
>> it to appear in the ServiceRequest associated with a URN and
>> probably prohibiting it there".    If that is true, it is
>> wonderful.  But I'm trying to avoid a requirement to prove
>> such statements about "all NIDs" rather than particular NIDs
>> or, e.g., NIDs that might sensibly be used in the library
>> community.
>=20
> Right. URNs are too diverse that we could specify something
> for all of them. Another argument for the NID level of
> specification.

And another argument for considering any work based on RFC 2483
or the DDDS work to be about techniques available for use in
selected URNs (with the selection occurring as part of NID
specification) rather than as generic URN functions.

>...
>> See above and note that, just as I'm not sure that a generic
>> URN definition needs to know (or can know) what a "browser"
>> is, I'm not confident, generically, what a "URN resolver" is
>> (other than, like "browser", more handwaving).
>=20
> My definition is that a URN resolver is an application that
> given a URN and a set of service requests returns the object,
> metadata or whatever that is associated with the URN as
> specified by the service requests.

Ok, Accepting that definition for the moment, what happens when
a URN resolver is given an indicator-only URN (with or without
service requests).  Those indicators (see Peter's XMPP example)
don't have "objects, metadata, or whatever", they just exist or
don't.  I imagine we could come up with an elaborate definition
that would cause them to have values, even if the values were
self-identity, but I'm not yet persuaded that such kludges are
worth the costs.

>...
>> > Yes, terminology can be a PITA, but that's nothing we can
>> > change (modulo updating 3986).
>>=20
>> Or separating URNs from 3986 and then defining whatever is
>> needed to be defined for URNs in a URN-appropriate way.  That
>> is exactly what "Plan B" [2] and "URNs are not URIs" are
>> about.
>=20
> Since "URNs are not URIs" requests an update of 3986 anyway,
> why can't we try to move the _semantics_ of fragment out of it
> and into the http specification instead?

I'd be delighted to.  But see the "no time" comments above and
note that the integrity of 3986 is under attack from the URL
side as well and that we would do ourselves no favors by trying
to change it in divergent directions and without coordination.

Put differently, I believe that tearing down 3986 and clarifying
its boundaries would, in a more perfect world, be exactly the
right thing to do.  In our present world, I'd rather get the URN
specs moving forward and finished.

>...

best,
   john


From nobody Mon Jun 30 11:54:58 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4D31A02DE for ; Mon, 30 Jun 2014 11:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 vLcDyfXnXuO9 for ; Mon, 30 Jun 2014 11:54:36 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6074A1A063B for ; Mon, 30 Jun 2014 11:54:32 -0700 (PDT)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 3D9D27F2EF; Mon, 30 Jun 2014 20:54:31 +0200 (CEST)
From: "Svensson, Lars" 
To: John C Klensin , Juha Hakala ,  "Dale R. Worley" 
Thread-Topic: RE: Re: [urn] urn:ietf:rfc
Thread-Index: Ac+UlKT0TDDcdlNVRb2bLbqBYFkefA==
Date: Mon, 30 Jun 2014 18:54:28 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA445FD34@dnbf-ex1.AD.DDB.DE>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.69.22]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/psBmLhwlCq9vfSKaYZn8OmJCQ30
Cc: "urn@ietf.org" 
Subject: Re: [urn] urn:ietf:rfc
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 18:54:48 -0000

Sm9obiwNCg0KPiBGcm9tOiBKb2huIEMgS2xlbnNpbiBbbWFpbHRvOmpvaG4taWV0ZkBqY2suY29t
XQ0KPiBTZW50OiBTdW5kYXksIEp1bmUgMjksIDIwMTQgOTo0NiBBTQ0KPiBUbzogU3ZlbnNzb24s
IExhcnM7IEp1aGEgSGFrYWxhOyBEYWxlIFIuIFdvcmxleQ0KPiBDYzogdXJuQGlldGYub3JnDQo+
IFN1YmplY3Q6IFJFOiBSZTogW3Vybl0gdXJuOmlldGY6cmZjDQo+IA0KPiANCj4gDQo+IC0tT24g
RnJpZGF5LCBKdW5lIDI3LCAyMDE0IDE1OjM5ICswMDAwICJTdmVuc3NvbiwgTGFycyINCj4gPEwu
U3ZlbnNzb25AZG5iLmRlPiB3cm90ZToNCj4gDQo+ID4gSm9obiwNCj4gPg0KPiA+PiBTb21lIGNv
bW1lbnRzIGJlbG93LCBtb3N0bHkgdG8gY2xhcmlmeSBteSBlYXJsaWVyIG5vdGUgdG8NCj4gPj4g
d2hpY2ggYm90aCBvZiB5b3UgcGFydGlhbGx5IHJlc3BvbmRlZC4gIEZpcnN0LCBhbmQgbW9zdA0K
PiA+PiBpbXBvcnRhbnQsIHBsZWFzZSB1bmRlcnN0YW5kIHRoYXQsIHdoaWxlIEkgaGF2ZSBiaWFz
ZXMgYW5kDQo+ID4+IG9waW5pb25zIGFib3V0IFVSTnMgYW5kIHRoZWlyIHByb3BlciBkZWZpbml0
aW9uIGFuZCB1c2UsIEknbQ0KPiA+PiB0cnlpbmcgdG8gYmUgY29tcGxldGVseSBwcmFnbWF0aWMg
YWJvdXQgdGhpcy4gIFRoYXQgbWVhbnMgSQ0KPiA+PiBhbSBwdXR0aW5nIHRocmVlIHN0cmF0ZWdp
YyBwcmluY2lwbGVzIGFoZWFkIG9mIGRlY2xhcmF0aW9ucw0KPiA+PiBhYm91dCB3aGF0IGlzIG9y
IGlzIG5vdCBjb3JyZWN0IGZyb20gc29tZSBwZXJzcGVjdGl2ZS4gIFRob3NlDQo+ID4+IHByYWdt
YXRpYyBwcmluY2lwbGVzIGFyZQ0KPiA+Pg0KPiA+PiAgLS0gdHJ5IHRvIGFjY29tbW9kYXRlIGFs
bCBvZiB0aG9zZSB3aG8gdGhpbmsgVVJOcyBhcmUNCj4gPj4gCW5lY2Vzc2FyeSwgaS5lLiwgdGhh
dCB0aGV5IGFyZSBkaXN0aW5jdCBmcm9tIFVSTHMuDQo+ID4NCj4gPiBXZWxsLCBvZiBjb3Vyc2Ug
dGhleSBhcmUuDQo+IA0KPiBVbmxlc3MgSSd2ZSBtaXN1bmRlcnN0b29kIGEgbnVtYmVyIG9mIHJl
bWFya3MsIHlvdXIgIm9mIGNvdXJzZSINCj4gdmlldyBpcyBub3QgdW5pdmVyc2FsbHkgc2hhcmVk
Lg0KDQpNeSByZWFkaW5nIG9mIHRoZSBkaXNjdXNzaW9uIGlzIHJhdGhlciB0aGF0IHdlICg9PSAi
dGhlIGNvbW11bml0eSIpIGRvbid0IGRpZmZlciBvbiB0aGUgbmVjZXNzaXR5IG9mIFVSTnMuIFRv
IG1lIHRoZSBiaWcgcXVlc3Rpb24gaXMgaWYgd2UgY2FuIHNheSBVUkk9PVVSTC4gSSBzYXkgaXQn
cyBub3QuIFRoZXJlIGFyZSBuYW1lcyBhbmQgdGhlcmUgYXJlIGxvY2F0b3JzLiBJbiBzb21lIHNl
dHRpbmdzLCBpdCBtYWtlcyBzZW5zZSB0byB1c2UgYSBsb2NhdG9yIGFzIGEgbmFtZSAoYW5kIHNv
bWV0aW1lcyBpdCBkb2Vzbid0KS4gSW4gbXkgZXllcyB0aGF0IGRvZXNuJ3QgbWFrZSBhbGwgVVJJ
cyBVUkxzIChidXQgcGVyaGFwcyBJIGxpdmUgaW4gYSBwYXJhbGxlbCB1bml2ZXJzZS4uLikuDQoN
Cj4gPiBJIHRoaW5rIHdlIGdldCBib2dnZWQgZG93biB3aXRoIHRoZQ0KPiA+IHF1ZXN0aW9uLCBp
ZiBVUk5zIGFyZSBhIHN1YmNsYXNzIG9mIFVSSXMgb3Igbm90LiBJIHRyeSB0bw0KPiA+IGFyZ3Vl
IHRoYXQgVVJOcyBfc2hvdWxkXyBiZSBhIHN1YmNsYXNzIG9mIFVSSXMgZm9yIHRoZSBzaW1wbGUN
Cj4gPiByZWFzb24gdGhhdCBpdCBhbGxvd3MgbWUgdG8gdXNlIGEgVVJOIGluIGFsbCBwbGFjZXMg
d2hlcmUgYQ0KPiA+IFVSSSBpcyBleHBlY3RlZCwgZS4gZy4gYXMgYW4gWE1MIG5hbWVzcGFjZSBp
ZGVudGlmaWVyLCBvciBpbiBhDQo+ID4gU2VtV2ViL0xpbmtlZERhdGEgc2V0dGluZywgd2hlcmUg
aWRlbnRpZmllcnMgZm9yIGVudGl0aWVzIGFyZQ0KPiA+IHJlcXVlc3RlZCB0byBiZSBVUklzLiBU
aGlzIGlzIG5vdCBvbmx5IGEgY29uY2VybiBhYm91dA0KPiA+IGJyZWFraW5nIGJhY2t3YXJkIGNv
bXBhdGliaWxpdHksIGJ1dCBhbHNvIGEgbWFya2V0aW5nIGlzc3VlOg0KPiA+IE9uZSBvZiBvdXIg
c2VsbGluZyBwb2ludHMgd2hlbiB3ZSB0cnkgdG8gY29udmluY2UgcGVvcGxlIHRvDQo+ID4gdXNl
IFVSTnMgaXMgZXhhY3RseSB0aGUgcG9pbnQgdGhhdCB0aGV5IGFyZSBVUklzLCB0b28gYW5kIHRo
YXQNCj4gPiBhbGwgdGhlIHVzYWdlcyBtZW50aW9uZWQgYWJvdmUgYXJlIG9wZW4gdG8gdGhlbS4N
Cj4gDQo+IEZpcnN0LCBJIHRoaW5rICJhIFVSTiBjYW4gYmUgdXNlZCBpbiBhbGwgcGxhY2VzIHdo
ZXJlIGEgVVJJIGlzDQo+IGV4cGVjdGVkIiBpcywgb3BlcmF0aW9uYWxseSwgc29tZXRoaW5nIG9m
IGEgZmFudGFzeS4gIFRoZQ0KPiBwcm9ibGVtIGlzIHRoYXQgd2UgaGF2ZSBVUk5zIGZvciB3aGlj
aCAicmVzb2x1dGlvbiIgaXMNCj4gbWVhbmluZ2xlc3MgYW5kIHNvIGlzIGFueSAidXNlIiBvdGhl
ciB0aGFuICJvaywgdGhlIHN5bnRheCB3b3Jrcw0KPiBhbmQgbm90aGluZyB3aWxsIGJyZWFrIGlu
IHBhcnNpbmciICAodGhlIGxhdHRlciBhcmd1bWVudCB3b3VsZA0KPiBoYXZlIGJlZW4gc3Ryb25n
ZXIgaWYgd2UgaGFkIGFkb3B0ZWQgdGhlIHJlcXVpcmVtZW50IHRoYXQgVVJJcw0KPiBiZSBjbGVh
cmx5IGRlbGltaXRlZCwgb3IgYXQgbGVhc3QgY2xlYXJseSAoYW5kIHVuYW1iaWd1b3VzbHkgYW5k
DQo+IGNvbnNpc3RlbnRseSkgdGVybWluYXRlZCwgaW4gcnVubmluZyB0ZXh0KS4NCg0KVHJ1ZS4N
Cg0KPiBBcmd1YWJseSBhDQo+IHN0YXRlbWVudCBsaWtlICJhIFVSSSBjYW4gYmUgdXNlZCBhbnl3
aGVyZSBhIFVSSSBjYW4gYmUgdXNlZCIsDQo+IGhvd2V2ZXIgdGF1dG9sb2dpY2FsLXNvdW5kaW5n
LCBpcyBhIGZhbnRhc3kgdG9vLiAgVGhlIGRpZmZpY3VsdHkNCj4gaXMgdGhhdCB3ZSBkb24ndCBo
YXZlIGEgVVJJIHN5bnRheCBkZWZpbml0aW9uIHRoYXQgaXMgdWx0aW1hdGVseToNCj4gDQo+ICAg
IE1ldGhvZDogPHN0dWZmPiA8c2luZ2xlLXRlcm1pbmF0aW5nLWRlbGltaXRlcj4NCj4gDQo+IElu
c3RlYWQsIHdlIGhhdmUgYSBsb3Qgb2YgTWV0aG9kLWRlcGVuZGVudCBzdHVmZiB0aGF0IGFmZmVj
dHMNCj4gaG93IHRoZSByZXN0IG9mIHRoZSBVUkkgKHdoYXRldmVyIHRoYXQgbWVhbnMpIGlzIHBh
cnNlZCBhbmQNCj4gaW50ZXJwcmV0ZWQuDQoNClllcywgYnV0IHdpdGhvdXQgdGhlIG1ldGhvZC1k
ZXBlbmRlbnQgc3R1ZmYsIHdlIHdvdWxkbid0IG5lZWQgZGlmZmVyZW50IG1ldGhvZHMgYXQgYWxs
LCB3b3VsZCB3ZT8gVGhhdCBzYWlkLCBJIHN0YXJ0IHRvIHVuZGVyc3RhbmQgeW91ciBjb25jZXJu
cyBhYm91dCB0aGUgKG5vbi0pdXNlZnVsbmVzcyBvZiBhIGdlbmVyaWMgVVJJIHN5bnRheC4NCg0K
PiBJZiBzb21lIHByb2dyYW0gZG9lc24ndCB1bmRlcnN0YW5kIHRoZSBNZXRob2QgaW4NCj4gY29u
dGV4dCwgYWxsIGl0IGNhbiBkbyBpcyBwYXJzZSB0aGUgVVJJIGF3YXkgZnJvbSBvdGhlciB0ZXh0
DQo+IGFuZCwgSSBiZWxpZXZlIGluIHByaW5jaXBsZSwgbWlnaHQgbm90IGV2ZW4gYmUgYWJsZSB0
byBkbyB0aGF0Lg0KPiBLbm93aW5nIHRoYXQgaXQgY2FuIGJyZWFrIHRoZSBVUkkgaW50byBlbm91
Z2ggcGllY2VzIHRvIHBhc3MgdGhlDQo+IGNvbXBvbmVudHMgdG8gYSBnZW5lcmljIEFQSSByZWFs
bHkganVzdCBraWNrcyB0aGUgcHJvdmVyYmlhbCBjYW4NCj4gZG93biB0aGUgcm9hZCAtLSB0aGF0
IEFQSSBtdXN0IHN0aWxsIGhhdmUgbWV0aG9kLWRlcGVuZGVudA0KPiBhY3Rpb25zIHRvIG1ha2Ug
YW55IHVzZSBvZiB0aGUgbWF0ZXJpYWwgb3IgaXQgbmVlZHMgYSBnb29kIHdheQ0KPiB0byBiYWNr
IG91dCBhbmQgZGVsaXZlciBhIGZhaWx1cmUgbWVzc2FnZSB0byB0aGUgdXNlciAtLSBvbmUNCj4g
dGhhdCBzaG91bGQgcmVhbGx5IGJlIGJldHRlciB0aGFuICJIdWg/IiBidXQgb2Z0ZW4gaXNuJ3Qu
DQo+IA0KPiBBbGwgb2YgdGhhdCBzYWlkLCBpdCB3b3VsZCBiZSBwZXJmZWN0bHkgcmVhc29uYWJs
ZSB0byBub3QgZ28gYXMNCj4gZmFyIGFzICJVUk5zIGFyZSBub3QgVVJJcyIgYnV0IGluc3RlYWQg
cmlwIGFsbCBvZiB0aGUgc2VtYW50aWNzDQo+IGFuZCBtYXliZSBzb21lIG9mIHRoZSBzeW50YXgg
cmVzdHJpY3Rpb25zIG91dCBvZiAzOTg2LiAgIEFzIEkNCj4gc2FpZCBpbiBlYXJsaWVyIG5vdGVz
IGFuZCwgdG8gc29tZSBkZWdyZWUsIGluIHRoZSBkb2N1bWVudCwgaXQNCj4gd291bGQgYmUgYSBs
b3Qgb2Ygd29yayB0byBwaWNrIDM5ODYgYXBhcnQgYW5kIHdvdWxkIGJlIGhhcmQgdG8NCj4gZ2V0
IGNvbnNlbnN1cyBiZWNhdXNlIHRoYXQgc29ydCBvZiByZXZpc2lvbiB3b3VsZCByZXF1aXJlDQo+
IGFncmVlbWVudCBhY3Jvc3MgdGhlIHdob2xlIFVSSSBjb21tdW5pdHkuICBJJ20gbm90IHdpbGxp
bmcgdG8gZG8NCj4gdGhhdCB3b3JrIChldmVuIGlmIEkgaGFkIHRpbWUsIHdoaWNoIEkgZG9uJ3Qp
LCBpbiBwYXJ0IGJlY2F1c2UgSQ0KPiBzZWUgb3RoZXIgZGV2ZWxvcG1lbnRzIG1ha2luZyBpdCBp
cnJlbGV2YW50LiAgQW5kIEkgdGhpbmsgdGhhdA0KPiBob2xkaW5nIFVSTnMgaG9zdGFnZSB1bnRp
bCBpdCBpcyBkb25lIGd1YXJhbnRlZXMgYSBmb3JrIG9yDQo+IHdvcnNlLiAgIEJ1dCwgaWYgeW91
IHdhbnQgdG8gdGFrZSBpdCBvbiwgZ28gdG8gaXQuDQo+IA0KPiA+Li4uDQo+IA0KPiA+PiBIZXJl
LCBhcyBlbHNld2hlcmUgaW4gdGhpcyBub3RlLCB0aGUgcHJpbmNpcGxlcyBhYm92ZSBjYXVzZSBt
ZQ0KPiA+PiB0byB0YWtlIGEgcG9zaXRpb24gdmVyeSBkaWZmZXJlbnQgZnJvbSB3aGVyZSB5b3Ug
KGFuZCBMYXJzKQ0KPiA+PiBhcmUgZ29pbmcgLS0gbm90IGNvbnRyYWRpY3RvcnksIGJ1dCBvcnRo
b2dvbmFsLiAgQmVjYXVzZSBvZg0KPiA+PiB0aG9zZSBwcmluY2lwbGVzIGFuZCB0aGUgcXVlc3Rp
b24gb2YgdGhlIGxlZ2l0aW1hY3kgb2YgVVJOcw0KPiA+PiBhcyBhIGNvbnN0cnVjdGlvbiBzZXBh
cmF0ZSBmcm9tIFVSTHMgKG9yIFVSTHMgZ2VuZXJhbGl6ZWQNCj4gPj4gaW50byBVUklzKSwNCj4g
Pg0KPiA+IFRoaXMgc2VlbXMgdG8gYmUgdGhlIHBsYWNlIHdoZXJlIHdlIG5lZWQgdG8gZmluZCBh
IGNvbW1vbiB2aWV3DQo+ID4gb24gdGhpbmdzLiBNeSByZWFkaW5nIGlzIHRoYXQgVVJJcyAoYXMg
ZGVmaW5lZCBieSAzOTg2KSBhcmUNCj4gPiBfYWx3YXlzXyBpZGVudGlmaWVycyBhbmQgdGhhdCBf
c29tZV8gVVJJcyAoZGVwZW5kaW5nIG9uIHRoZWlyDQo+ID4gc2NoZW1lKSBhcmUgYWxzbyBsb2Nh
dG9ycy4gVG8gdGhlICJwdXJlIGlkZW50aWZpZXJzIiBJIGNvdW50DQo+ID4gZS4gZy4gZ2VvOiwg
eGNvbjogYW5kIGNyaWQ6IChhbmQgdXJuOiksIHdoaWxlIGUuIGcuIGh0dHA6LA0KPiA+IGZ0cDog
YW5kIHNtdHA6IHdvdWxkIGJlIGxvY2F0b3JzIGFzIHdlbGwuIFNvIGluIG15IHZpZXcsIHdlDQo+
ID4gY2Fubm90IGdlbmVyYWxpc2UgVVJMcyBpbnRvIFVSSXMsIHdoaWNoIHdvdWxkIGFsbG93IHVz
IHRvIGtlZXANCj4gPiBVUk5zIGFzIGEgc3ViY2xhc3Mgb2YgVVJJcy4NCj4gDQo+IEFzIEkndmUg
dHJpZWQgdG8gc2F5IGJlZm9yZSwgSSB0aGluayB0aGF0IGEgcGhpbG9zb3BoaWNhbCBkZWJhdGUN
Cj4gYWJvdXQgdGhlIHByZWNpc2UgcHJvcGVyIHVzYWdlIG9mIHRoZSB0ZXJtICJpZGVudGlmaWVy
IiBpcw0KPiBleHRyZW1lbHkgaW50ZXJlc3RpbmcgYnV0IGRvZXNuJ3QgbGVhZCB1cyBhbnl3aGVy
ZSBvbiB3aGljaA0KPiBhZ3JlZW1lbnQgaXMgbGlrZWx5IGluIHRoZSBmb3Jlc2VlYWJsZSBmdXR1
cmUuICBUaGF0IG1ha2VzIG9uZQ0KPiBpbXBvcnRhbnQgcXVlc3Rpb24gd2hldGhlciB3ZSBhcmUg
d2lsbGluZyB0byBkZWxheSBhbnkgcHJvZ3Jlc3MNCj4gb24gVVJOcyB1bnRpbCB3ZSBkbyBhZ3Jl
ZS4NCj4gDQo+IEhvd2V2ZXIsICJ3ZSBjYW5ub3QgZ2VuZXJhbGlzZSBVUkxzIGludG8gVVJJcywu
Li4iIGlzIGENCj4gc3RhdGVtZW50IHdpdGggd2hpY2ggSSd2ZSBjb21lIHRvIGFncmVlLiAgIFJG
QyAzOTg2IGlzIHByZWNpc2VseQ0KPiBhIGdlbmVyYWxpemF0aW9uIG9mIFVSTHMgaW50byBVUkku
ICBZZXQgYW5vdGhlciB2aWV3IG9mIGl0IGlzDQo+IHRoYXQgaXQgYXR0ZW1wdGVkIHRoZSBpbXBv
c3NpYmxlIChvciBjb250cmFkaWN0b3J5KSBhbmQgZmFpbGVkLg0KPiBTbyB3aGVyZSBkb2VzIHRo
YXQgbGVhdmUgdXM/DQoNCg0KPiANCj4gPg0KPiA+PiBJIGJlbGlldmUgdGhlIGRvY3VtZW50IGNp
dGVkIFsxXSBpcyBzaW1wbHkgaXJyZWxldmFudC4gICBJDQo+ID4+IHJlYWxseSB3YW50IHRvIHNl
ZSB1cyBkaXNjdXNzIGFuZCBldm9sdmUgVVJOcyBpbiBhIHdheSB0aGF0DQo+ID4+IHJlc3BvbmRz
IHRvIG5lZWRzIC0tYXMgY29uY3JldGUgYXMgcG9zc2libGUtLSBpZGVudGlmaWVkIGJ5DQo+ID4+
IGxlZ2l0aW1hdGUgY29tbXVuaXRpZXMsIG5vdCB3aGV0aGVyIHRoZSByZXN1bHRzIChvciB0aGlu
a2luZykNCj4gPi4uLg0KPiANCj4gPiBZZXMsIGl0IGlzIHN0aWxsIHZlcnkgb2J2aW91cyB0aGF0
IGZyYWdtZW50cyAoYW5kIHF1ZXJpZXMpDQo+ID4gY29tZSBmcm9tIGh0dHAuIFRoZSBxdWVzdGlv
biBpcyBpZiB3ZSBjYW4gZ2VuZXJhbGlzZSB0aGVtIHRvDQo+ID4gYmUgdXNlZCBpbiBVUk5zLCB0
b28uDQo+IA0KPiBJIHRoaW5rIHRoZSBxdWVzdGlvbiBpcyBhIGxpdHRsZSBkaWZmZXJlbnQuICBJ
J2QgbGlrZSB0byBzZWUgdXMNCj4gc3RhcnQgYnkgZWl0aGVyIGZpZ3VyaW5nIG91dCB3aGF0IGZ1
bmN0aW9uYWxpdHkgd2UgbmVlZCBhY3Jvc3MNCj4gdGhlIHdob2xlIGZhbWlseSBvZiBwb3RlbnRp
YWwgVVJOcywgYXQgbGVhc3QgdGVtcG9yYXJpbHkNCj4gYXZvaWRpbmcgdGhlIHRlcm1zICJmcmFn
bWVudCIgYW5kICJxdWVyeSIgYmVjYXVzZSB0aGV5IGNhcnJ5DQo+IGJvdGggc3ludGFjdGljIGFu
ZCBzZW1hbnRpYyBiYWdnYWdlIHdpdGggdGhlbSwgYW5kIG9ubHkgdGhlbg0KPiBhc2tpbmcgaG93
IGNsb3NlbHkgd2UgY2FuIGFkYXB0IHRob3NlIGFuc3dlcnMgdG8gdGhlIGdlbmVyYWwgVVJJDQo+
IGZyYW1ld29yay4gIE1heWJlIHRoaW5ncyBjb3VsZCBoYXZlIHdvcmtlZCBvdXQgZGlmZmVyZW50
bHksDQo+IGVzcGVjaWFsbHkgaWYgMzk4NiB3ZXJlIGJldHRlciBkZXNpZ25lZCBhbmQgd3JpdHRl
biwgYnV0LCB0b2RheSwNCj4gImdlbmVyYWxpc2UgdGhlbSB0bw0KPiA+IGJlIHVzZWQgaW4gVVJO
cyIgaGFzIHRvbyBtYW55IGFzcGVjdHMgb2YgYSBQcm9jcnVzdGVhbg0KPiBzb2x1dGlvbi4NCj4g
DQo+ID4uLi4NCj4gPj4gSSB3YW50IHRvIHN0YXkgd2l0aCAiaXJyZWxldmFudCIgYW5kIGF3YXkg
ZnJvbSBkaXN0cmFjdGlvbnMsDQo+ID4+IGJ1dCB0aGUgYWJvdmUgaGVscHMgc2hvdyB3aHkgdGhh
dCBwb3NpdGlvbiBpcyBpbXBvcnRhbnQ6IGlmDQo+ID4+IG9uZSBiZWxpZXZlcyB0aGF0IFVSTnMg
aGF2ZSB0byBiZSBzdGFibGUgaW5kZXBlbmRlbnQgb2Ygd2hhdA0KPiA+PiBoYXBwZW5zIHdpdGgg
bWV0aG9kLWRlcGVuZGVudCAiaWRlbnRpZmllcnMiIChvciAibG9jYXRvcnMiLA0KPiA+PiBldGMu
KSwgdGhlbiBJIHRoaW5rIHdlIGhhdmUgdG8gc2ltcGx5IGF2b2lkIGdldHRpbmcgZW50YW5nbGVk
DQo+ID4+IGJ5IHN0YXRlbWVudHMgYWJvdXQgaW5zdHJ1Y3Rpb25zIHRvIGJyb3dzZXJzIGJlY2F1
c2Ugd2UNCj4gPj4gY2Fubm90IHRvIGtub3cgd2hhdCBhICJicm93c2VyIiBpcyB3aXRoIHN1ZmZp
Y2llbnQgY2xhcml0eSwNCj4gPj4gYWJzdHJhY3Rpb24sIGFuZCBwZXJzaXN0ZW5jZS9zdGFiaWxp
dHkuDQo+ID4NCj4gPiBXZSBfY291bGRfIG1ha2Ugc3RhdGVtZW50cyBvZiBob3cgYSBzcGVjLWNv
bmZvcm1pbmcgdXNlciBhZ2VudA0KPiA+IGhhcyB0byBiZWhhdmUuDQo+IA0KPiBZZXMuICBCdXQg
dGhlIElFVEYgKGFzIGRpc3RpbmN0IGZyb20sIGUuZy4sIFczQykgZ2VuZXJhbGx5DQo+IGF2b2lk
cyBtYWtpbmcgc3RhdGVtZW50cyBhYm91dCB1c2VyIGFnZW50IGJlaGF2aW9yLiAgTW9yZQ0KPiBp
bXBvcnRhbnQsIGJlY2F1c2UsIHdoaWxlIGFsbCBVUkxzIG11c3QgYmUgcmVzb2x2YWJsZSBpbiBh
dA0KPiBsZWFzdCBzb21lIGdlbmVyYWwgc2Vuc2UsIHdlJ3ZlIHNlZW4gc2V2ZXJhbCBleGFtcGxl
cyBvZiBVUk5zDQo+IHRoYXQgYXJlIG5vdCByZXNvbHZhYmxlIG9yIGludGVuZGVkIHRvIGJlIHJl
c29sdmVkLiAgQSBzdGF0ZW1lbnQNCj4gYWJvdXQgdXNlciBhZ2VudCBjb25mb3JtaXR5IHRoYXQg
d291bGQgYmUgYnJvYWQgZW5vdWdoIHRvIGNvdmVyDQo+IGFsbCBvZiB0aG9zZSBjYXNlcyB3b3Vs
ZCBwcm9iYWJseSBub3QgYmUgdXNlZnVsLiAgT3IgcGVyaGFwcyBJDQo+IGRvbid0IHVuZGVyc3Rh
bmQgd2hhdCB5b3UgaGF2ZSBpbiBtaW5kLg0KDQpUaGlzIGRpc3RpbmN0aW9uIGJldHdlZW4gSUVU
RiBhbmQgVzNDIHdhc24ndCBjbGVhciB0byBtZS4gTXkgaW50ZW50aW9uIHdhcyByZWFsbHkgdG8g
c3BlY2lmeSB0aGUgYmVoYXZpb3Igb2YgYSBjb25mb3JtaW5nIHVzZXIgYWdlbnQvc2VydmljZS4g
SSBlbnZpc2lvbmVkIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YgImlmIGFuIGFnZW50IHNl
bmRzIGEgc2VydmljZSByZXF1ZXN0IHdpdGggcmVxdWVzdCBtZXRob2QgZm9vIHdpdGhvdXQgc3Bl
Y2lmeWluZyBvbmUgb2YgdGhlIHBhcmFtZXRlcnMgYmxhLCBmYXNlbCBvciBibHVwcCwgdGhlIHNl
cnZpY2UgTVVTVCBkaXNjYXJkIHRoZSByZXF1ZXN0IGFuZCBzZW5kIGFuIGFwcHJvcHJpYXRlIGVy
cm9yIG1lc3NhZ2UiLCBvciAiYSBjb25mb3JtaW5nIHVzZXIgYWdlbnQgU0hPVUxEIGRpc3BsYXkg
dGhlIFVSTiBpbiBpdHMgY2Fub25pY2FsIGZvcm0gKHdoYXRldmVyIHRoYXQgbWlnaHQgYmUuLi4p
Iiwgb3IgImEgdXNlciBhZ2VudCBNVVNUIHN0cmlwIHRoZSByYW1iYS16YW1iYSBwYXJ0IChha2Eg
ZnJhZ21lbnQgaWRlbnRpZmllcikgb2YgdGhlIFVSTiBiZWZvcmUgc2VuZGluZyBhIHNlcnZpY2Ug
cmVxdWVzdCBhbmQgTUFZIGRvIHNvbWV0aGluZyBmYW5jeSB3aXRoIHRoZSByYW1iYS16YW1iYSBh
ZnRlciBpdCBoYXMgcmVjZWl2ZWQgZGF0YSBmcm9tIHRoZSBzZXJ2ZXIiLg0KDQo+ID4uLi4NCj4g
PiBJIHRoaW5rIGl0IGhhcyBiZWVuIHNhaWQgb24gdGhpcyBsaXN0IGJlZm9yZSAoYW5kIG5vdyBJ
IHN0YXJ0DQo+ID4gdG8gdW5kZXJzdGFuZCB0aGF0Li4uKSB0aGF0IG9uZSBvZiB0aGUgZmxhd3Mg
aW4gMzk4NiBpcyB0aGF0DQo+ID4gaXQgaXMgbm90IG9ubHkgYWJvdXQgc3ludGF4LCBidXQgYWxz
byBhYm91dCBzZW1hbnRpY3MuIEl0DQo+ID4gd291bGQgaGF2ZSBiZWVuIG11Y2ggZWFzaWVyIGlm
IDM5ODYgaGFkIG9ubHkgc3BlY2lmaWVkIHRoYXQNCj4gPiBmcmFnbWVudHMgYXJlIGFsbG93ZWQg
YW5kIHdoZXJlIHRoZXkgZml0IGluIHRoZSBzeW50YXgsIGFuZA0KPiA+IGxlZnQgaXQgdG8gaW5k
aXZpZHVhbCBVUkkgc2NoZW1hcyB0byBkZWZpbmUgdGhlIHNlbWFudGljcy4gVGhlDQo+ID4gc2Ft
ZSBhcHBsaWVzIHRvIHF1ZXJpZXMuDQo+IA0KPiBZZXMsIHNlZSBhYm92ZS4NCg0KTW9yZSBiZWxv
dy4NCg0KPiA+IFsuLi5dDQo+ID4NCj4gPj4gPj4+IEluIHRoZSBhYm92ZSwgYSBTZXJ2aWNlUmVx
dWVzdCBpcywgYWdhaW4gY29uY2VwdHVhbGx5LCBhDQo+ID4+ID4+PiB0dXBsZSBvZg0KPiA+PiA+
Pj4NCj4gPj4gPj4+ICAgICBTZXJ2aWNlVHlwZSBDb21wYXJpc29uSW5kaWNhdG9yIFNlcnZpY2VU
YXJnZXQNCj4gPj4gPj4+IFJlZXF1ZXN0UGFyYW1ldGVycy4uLg0KPiA+PiA+Pj4NCj4gPj4gPj4+
IFNlcnZpY2VUeXBlIGlzIG5vbWluYWxseSBzb21lIHNvcnQgb2Yga2V5d29yZC4NCj4gPj4gPg0K
PiA+PiA+IE9LLiBSRkMgMjQ4MyBkZWZpbmVzIGEgaGFuZGZ1bCBvZiB0aGVzZSBrZXl3b3JkcyBh
bmQNCj4gPj4gPiBzZXJ2aWNlcywgYnV0IG5vdCBuZWFybHkgZW5vdWdoLg0KPiA+Pg0KPiA+PiBB
bm90aGVyIGV4YW1wbGUgb2Ygd2hhdCBJJ20gdHJ5aW5nIHRvIGF2b2lkLiAgSSBhbSBjZXJ0YWlu
DQo+ID4+IHlvdXIgc3RhdGVtZW50IGFib3ZlIGlzIHRydWUuICBJIGFtIGVxdWFsbHkgY2VydGFp
biB0aGUNCj4gPj4gdHJ5aW5nIHRvIGRlZmluZSAob3IgZXZlbiBhZGVxdWF0ZWx5IGNoYXJhY3Rl
cml6ZSkgdGhlIG90aGVycw0KPiA+PiB3aWxsIGJvZyB1cyBkb3duIGZvciBhIHZlcnkgbG9uZyB0
aW1lIGFuZCBsZWFkIHVzIHRvIFBsYW4gQw0KPiA+PiBvciBEIFsyXS4gIFNvIEknbSB0cnlpbmcg
dG8gcHVzaCB0aGF0IHByb2JsZW0gYXdheSBieSBtYWtpbmcNCj4gPj4gdGhvc2Ugc2VydmljZXMg
YW5kIGtleXdvcmRzIGEgcGVyLU5JRCBtYXR0ZXIuICBJZiBpdCB0dXJucw0KPiA+PiBvdXQgdGhh
dCB3ZSBjYW4gbGF0ZXIgbWFrZSBncm91cHMgb2YgTklEcyBpbnRvIGNhdGVnb3JpZXMNCj4gPj4g
dGhhdCBzaGFyZSBzb21lIHNldCBvZiBzZXJ2aWNlcyBhbmQga2V5d29yZHMsIHRoYXQgd291bGQg
YmUNCj4gPj4gZ3JlYXQuICBCdXQsIGlmIHdlIG1ha2UgZG9pbmcgc28sIG9yIGV2ZW4gcHJvdmlu
ZyB0aGF0IHdlIGNhbg0KPiA+PiBkbyBzbywgYSBjb25kaXRpb24gZm9yIFVSTnMsIHRoZW4gd2Ug
d2lsbCBiZSBiYWNrIHRvIHdoZXJlIHdlDQo+ID4+IHdlcmUgd2hlbiBJIGZpcnN0IGtpbGxlZCB0
aGUgVVJJIFdHLg0KPiA+DQo+ID4gRG9lcyB0aGlzIGltcGx5IHRoYXQgd2Ugc2hvdWxkIG5vdCB0
cnkgdG8gdXBkYXRlIDI0ODMgYXQgYWxsDQo+ID4gYnV0IGluc3RlYWQgbWFrZSB0aGUgc2Vydmlj
ZSBkZXNjcmlwdGlvbiAoa2V5d29yZHMgZXRjLikgcGFydA0KPiA+IG9mIHRoZSBOSUQgcmVnaXN0
cmF0aW9uIHByb2Nlc3M/DQo+IA0KPiBUd28gc2VwYXJhdGUgcXVlc3Rpb25zLiAgRmlyc3QsIDI0
ODMgKGFuZCB0aGUgcmVsZXZhbnQNCj4gREREUy1zcGVjaWZpYyBzcGVjcykgYXJlIG1vc3RseSBp
cnJlbGV2YW50IHRvIHRoaXMgZGlzY3Vzc2lvbg0KPiBhbmQgaGF2ZSBiZWVuIG92ZXJ0YWtlbiBi
eSBldmVudHMsIGVzcGVjaWFsbHkgdGhlIGV2ZW50IG9mDQo+IGluZGljYXRvci1zdHlsZSAobmV2
ZXIgcmVzb2x2ZWQpIFVSTnMuICBJIHByZXN1bWUgaXQgaXMgbm90IGFuDQo+IGFjY2lkZW50IHRo
YXQgd29yayBvbiB0aGVtIHdhcyBuZXZlciBwYXJ0IG9mIHRoZSBVUk5iaXMgY2hhcnRlci4NCg0K
SnVoYSB3aWxsIGtub3cgdGhpcyBiZXR0ZXIgdGhhbiBJIGRvLCBidXQgSSBoYXZlIHZhZ3VlIG1l
bW9yaWVzIHRoYXQgd2UgcHJldHR5IGVhcmx5IGluIHRoZSBwcm9jZXNzIHJlYWxpc2VkIHRoYXQg
aXQgd2FzIGEgbWlzdGFrZSBub3QgdG8gY29uc2lkZXIgMjQ4MyBhcyB3ZWxsLiBJZiB5b3UgbmVl
ZCBhIHJlZmVyZW5jZSBJIGNhbiBkaWcgdGhyb3VnaCBteSBtYWlsIGFyY2hpdmVzLg0KDQo+IEFu
ZCwgeWVzLCBJIHRoaW5rIGFueSBzZXJ2aWNlIGRlc2NyaXB0aW9ucyBoYXZlIHRvIGJlIHBhcnQg
b2YNCj4gdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLi4uIGFuZCB0aGF0IDM0MDYgYWxyZWFkeSBn
b2VzIGENCj4gc2lnbmlmaWNhbnQgZGlzdGFuY2UgaW4gdGhhdCBkaXJlY3Rpb24uDQoNCk9LLCB0
aGF0J3MgZmluZSB3aXRoIG1lLg0KDQo+ID4+ID4+PiBDb21wYXJpc29uSW5kaWNhdG9yIHRlbGxz
IHNvbWV0aGluZyB0cnlpbmcgdG8gY29tcGFyZSBhDQo+ID4+ID4+PiBwYWlyIG9mIFVSTnMgZm9y
IGlkZW50aXR5IHdoZXRoZXIgdGhhdCBwYXJ0aWN1bGFyDQo+ID4+ID4+PiBTZXJ2aWNlUmVxdWVz
dCBjb3VudHMgb3Igc2hvdWxkIGJlIGlnbm9yZWQuDQo+ID4uLi4NCj4gPj4gSXQgaXMgYSB0cmlj
ayB0byBhdm9pZCBoYXZpbmcgdG8gcmVzb2x2ZSB0aGUgcXVlc3Rpb24gb2YNCj4gPj4gd2hldGhl
ciBhIHBhcnRpY3VsYXIgU2VydmljZSBSZXF1ZXN0IC0tb3IgU2VydmljZSBSZXF1ZXN0cyBpbg0K
PiA+PiBnZW5lcmFsLS0gYXJlICJwYXJ0IG9mIHRoZSBOU1MiLiAgIEkgY2FsbGVkIGl0DQo+ID4+
ICJDb21wYXJpc29uSW5kaWNhdG9yIiBiZWNhdXNlIEkgYmVsaWV2ZSB0aGF0LCBhYnNlbnQgdGhl
DQo+ID4+IHF1ZXN0aW9uIG9mIGNvbXBhcmluZyBhIHBhaXIgb2YgVVJOcyBmb3IgZXF1YWxpdHks
IHRoZSAicGFydA0KPiA+PiBvZiB0aGUgTlNTIiBxdWVzdGlvbiBkb2Vzbid0IG5lZWQgYSBwcmVj
aXNlIGFuc3dlciBhbmQgbWlnaHQNCj4gPj4gYmUgYSBkaXN0cmFjdGlvbi4NCj4gPg0KPiA+IEkg
dGhpbmsgSSB1bmRlcnN0YW5kIHdoYXQgeW91IGFyZSBhaW1pbmcgYXQsIGJ1dCBkbyB5b3UgdGhp
bmsNCj4gPiB5b3UgY291bGQgcHJvdmlkZSBhbiBleGFtcGxlIG9yIHR3byBqdXN0IGZvciBjbGFy
aXR5PyAoTm8sIEkNCj4gPiB3b24ndCBuYWlsIHlvdSBkb3duIG9uIHN5bnRheC4uLikuDQo+IA0K
PiBGb3IgIkNvbXBhcmlzb25JbmRpY2F0b3IiLCBJJ20gd29ycmllZCBhYm91dCwgYW5kIHRyeWlu
ZyB0bw0KPiBldmFkZSwgdGhlIGFyZ3VtZW50IGFib3V0IHdoZXRoZXIgU2VydmljZSBSZXF1ZXN0
cyBhcmUsIG9yIGFyZQ0KPiBub3QsIGVub3VnaCBwYXJ0IG9mIHRoZSBVUk4gdG8gZWZmZWN0IHdo
ZXRoZXIgb3Igbm90IHR3bw0KPiBVUk4tc3RyaW5ncyBjb21wYXJlIGVxdWFsLiAgU28gKGFuZCBh
Z2FpbiB3aXRoIHRoZSB1bmRlcnN0YW5kaW5nDQo+IHRoYXQgdGhlcmUgYXJlIGxvdHMgb2Ygd2F5
cyB0byBkbyB3aXRoIHN5bnRheCBhbmQgZGVmYXVsdHMsDQo+IHN1cHBvc2Ugd2UgZGVmaW5lZCB0
d28gY2F0ZWdvcmllcyBvZiBTZXJ2aWNlIFJlcXVlc3RzLCBvbmUgb2YNCj4gd2hpY2ggd2FzIGNv
bnNpZGVyZWQgaW50ZWdyYWwgdG8gdGhlIFVSTiAoaS5lLiwgdGhhdCwgaWYgYQ0KPiBwYXJ0aWN1
bGFyIHJlcXVlc3QgYXBwZWFyZWQgaW4gb25lIFVSTi1zdHJpbmcgYnV0IG5vdCBhbm90aGVyLA0K
PiB0aGUgdHdvIFVSTnMgd291bGQgYmUgdHJlYXRlZCBhcyBub3QgZXF1YWwpIGFuZCBvbmUgdGhh
dCB3YXMNCj4gbm90Lg0KDQpDb3VsZCBhbiBleGFtcGxlIGJlIGEgcmVxdWVzdCBmb3IgcmVzb3Vy
Y2UgbWV0YWRhdGE/IFRoZSBtZXRhZGF0YSBpcyBub3QgdGhlIHJlc291cmNlLCBzbyB0aG9zZSBz
aG91bGQgbm90IGJlIGVxdWFsLg0KDQo+IE5vdywgc3VwcG9zZSAoSSBob3BlIHlvdSBjYW4gcmVu
ZGVyIFVURi04IGJlY2F1c2UsIGZvcg0KPiB0aGlzIGV4YW1wbGUsIEkgbmVlZCB0byBjaG9vc2Ug
ZGVsaW1pdGVycyB0aGF0IGFyZSBub3QNCj4gY29tcGxpY2F0ZWQgYnkgMzk4NiAtLSBpZiB5b3Ug
Y2Fubm90LCB0aGUgdHdvIGZ1bm55IGNoYXJhY3RlcnMNCj4gYmVsb3cgYXJlIFUrMjE5MSwgdXB3
YXJkcyBhcnJvdywgYW5kIFUrMjE5MywgZG93bndhcmRzIGFycm93LA0KPiByZXNwZWN0aXZlbHkp
IHRoYXQsIHJhdGhlciB0aGFuIHVzaW5nICI/IiB0byBpbnRyb2R1Y2UgYm90aA0KPiBjYXRlZ29y
aWVzIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgYWxsIFNlcnZpY2UgUmVxdWVzdHMgYXJlDQo+IHF1
ZXJpZXMsIHdlIGhhZA0KPiANCj4gICAg4oaRU2VydmljZVJlcXVlc3QNCj4gZGVub3RpbmcgdGhl
IGludGVncmFsIG9uZXMgYW5kDQo+ICAgIOKGk1NlcnZpY2VSZXF1c3QNCj4gZGVub3RpbmcgdGhl
IG5vbi1pbnRlZ3JhbCBvbmVzDQo+IA0KPiBUaGVuDQo+ICAgIHVybjp4eHg6c3RyaW5n4oaRZm9v
ICBhbmQgdXJuOnh4eDpzdHJpbmfihpFiYXIgd291bGQgY29tcGFyZQ0KPiAibm90IGVxdWFsIg0K
PiBidXQNCj4gICAgdXJuOnh4eDpzdHJpbmfihpNmb28gIGFuZCB1cm46eHh4OnN0cmluZ+KGk2Jh
ciB3b3VsZCBiZQ0KPiBjb25zaWRlcmVkIGVxdWFsIFVSTnMuDQo+IA0KPiBJZiBteSBpbnRlcnBy
ZXRhdGlvbiBvZiBKdWhhJ3MgY29tbWVudHMgaXMgY29ycmVjdCBhbmQgaGUgaXMNCj4gY29ycmVj
dCB0aGF0IHdlIHdvdWxkIG5ldmVyIG5lZWQgdGhlIGZpcnN0IGNhc2UgKCLihpEiKSB0aGFuDQo+
IHRoYXQgd291bGQgYmUgZmluZSAtLSB3ZSdkIGp1c3QgbmV2ZXIgc2VlIHRoYXQgZGVsaW1pdGVy
IGFuZA0KPiBldmVyeW9uZSB3b3VsZCBiZSBoYXBweS4gIEJ1dCBJIHdhbnQgdG8gYXZvaWQgZ2V0
dGluZyBhDQo+IGNvcnJlY3RuZXNzIHByb29mIG9uICJTZXJ2aWNlIFJlcXVlc3RzIGFyZSBuZXZl
ciB0byBiZQ0KPiBjb25zaWRlcmVkIHBhcnQgb2YgdGhlIE5TUyIgaW4gb3VyIGNyaXRpY2FsIHBh
dGggaWYgd2UgcG9zc2libHkNCj4gY2FuLiAgU29tZXRoaW5nIGxpa2UgdGhlIGFib3ZlIG1heSBi
ZSBhIHdheSB0byBtYWtlIHRoYXQNCj4gc2VwYXJhdGlvbi4NCg0KSSBhZ3JlZSB0aGF0IHdlIHNo
b3VsZCBrZWVwIHRoZSBzZW1hbnRpY3MgYXMgZmxleGlibGUgYXMgcG9zc2libGUuIFRoZSBkb3du
c2lkZSB3b3VsZCBiZSB0aGF0IHNvbWVvbmUgd2hvIGltcGxlbWVudHMgc2VydmljZXMgZm9yIHNl
dmVyYWwgTklEcyBoYXMgYW4gaW5jcmVhc2VkIGJ1cmRlbiBzaW5jZSB0aGV5IG5lZWQgdG8gY29u
c2lkZXIgbWFueSBkaWZmZXJlbnQgc2VydmljZSByZXF1ZXN0IHZvY2FidWxhcmllcy4gSWYgd2Ug
Y2FuIGFncmVlIG9uIGEgc3ludGF4IGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBidWlsZCBhIHBh
cnNlciB0aGF0IGV4dHJhY3RzIHRoZSBOSUQgYW5kIGNhbiBwYXNzIHRoZSBwYXJzZWQgc2Vydmlj
ZSByZXF1ZXN0cyB0byB0aGUgY29ycmVjdCBzZXJ2aWNlIHN0cmF0ZWd5LiAoQnV0IEkgc3RhcnQg
dG8gdGhpbmsgaW1wbGVtZW50YXRpb24gaGVyZS4uLikuDQoNCj4gPi4uLg0KPiA+PiBJbiB0aGUg
bGFuZ3VhZ2UgSSd2ZSB1c2VkLCB3aGF0IHlvdSBoYXZlIGp1c3Qgc2FpZCBpcyAiZm9yIGFsbA0K
PiA+PiBOSURzLCBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gc3BlY2lmeSB0aGUgU2VydmljZVRh
cmdldCBhcw0KPiA+PiBwYXJ0IG9mIHRoZSBkZWZpbml0aW9uLyByZWdpc3RyYXRpb24sIHRoZXJl
Ynkgbm90IHJlcXVpcmluZw0KPiA+PiBpdCB0byBhcHBlYXIgaW4gdGhlIFNlcnZpY2VSZXF1ZXN0
IGFzc29jaWF0ZWQgd2l0aCBhIFVSTiBhbmQNCj4gPj4gcHJvYmFibHkgcHJvaGliaXRpbmcgaXQg
dGhlcmUiLiAgICBJZiB0aGF0IGlzIHRydWUsIGl0IGlzDQo+ID4+IHdvbmRlcmZ1bC4gIEJ1dCBJ
J20gdHJ5aW5nIHRvIGF2b2lkIGEgcmVxdWlyZW1lbnQgdG8gcHJvdmUNCj4gPj4gc3VjaCBzdGF0
ZW1lbnRzIGFib3V0ICJhbGwgTklEcyIgcmF0aGVyIHRoYW4gcGFydGljdWxhciBOSURzDQo+ID4+
IG9yLCBlLmcuLCBOSURzIHRoYXQgbWlnaHQgc2Vuc2libHkgYmUgdXNlZCBpbiB0aGUgbGlicmFy
eQ0KPiA+PiBjb21tdW5pdHkuDQo+ID4NCj4gPiBSaWdodC4gVVJOcyBhcmUgdG9vIGRpdmVyc2Ug
dGhhdCB3ZSBjb3VsZCBzcGVjaWZ5IHNvbWV0aGluZw0KPiA+IGZvciBhbGwgb2YgdGhlbS4gQW5v
dGhlciBhcmd1bWVudCBmb3IgdGhlIE5JRCBsZXZlbCBvZg0KPiA+IHNwZWNpZmljYXRpb24uDQo+
IA0KPiBBbmQgYW5vdGhlciBhcmd1bWVudCBmb3IgY29uc2lkZXJpbmcgYW55IHdvcmsgYmFzZWQg
b24gUkZDIDI0ODMNCj4gb3IgdGhlIERERFMgd29yayB0byBiZSBhYm91dCB0ZWNobmlxdWVzIGF2
YWlsYWJsZSBmb3IgdXNlIGluDQo+IHNlbGVjdGVkIFVSTnMgKHdpdGggdGhlIHNlbGVjdGlvbiBv
Y2N1cnJpbmcgYXMgcGFydCBvZiBOSUQNCj4gc3BlY2lmaWNhdGlvbikgcmF0aGVyIHRoYW4gYXMg
Z2VuZXJpYyBVUk4gZnVuY3Rpb25zLg0KDQpZZXMsIGl0IHNlZW1zIHRoZSB0d28gb2YgdXMgYWdy
ZWUgb24gdGhhdC4gDQoNCj4gPi4uLg0KPiA+PiBTZWUgYWJvdmUgYW5kIG5vdGUgdGhhdCwganVz
dCBhcyBJJ20gbm90IHN1cmUgdGhhdCBhIGdlbmVyaWMNCj4gPj4gVVJOIGRlZmluaXRpb24gbmVl
ZHMgdG8ga25vdyAob3IgY2FuIGtub3cpIHdoYXQgYSAiYnJvd3NlciINCj4gPj4gaXMsIEknbSBu
b3QgY29uZmlkZW50LCBnZW5lcmljYWxseSwgd2hhdCBhICJVUk4gcmVzb2x2ZXIiIGlzDQo+ID4+
IChvdGhlciB0aGFuLCBsaWtlICJicm93c2VyIiwgbW9yZSBoYW5kd2F2aW5nKS4NCj4gPg0KPiA+
IE15IGRlZmluaXRpb24gaXMgdGhhdCBhIFVSTiByZXNvbHZlciBpcyBhbiBhcHBsaWNhdGlvbiB0
aGF0DQo+ID4gZ2l2ZW4gYSBVUk4gYW5kIGEgc2V0IG9mIHNlcnZpY2UgcmVxdWVzdHMgcmV0dXJu
cyB0aGUgb2JqZWN0LA0KPiA+IG1ldGFkYXRhIG9yIHdoYXRldmVyIHRoYXQgaXMgYXNzb2NpYXRl
ZCB3aXRoIHRoZSBVUk4gYXMNCj4gPiBzcGVjaWZpZWQgYnkgdGhlIHNlcnZpY2UgcmVxdWVzdHMu
DQo+IA0KPiBPaywgQWNjZXB0aW5nIHRoYXQgZGVmaW5pdGlvbiBmb3IgdGhlIG1vbWVudCwgd2hh
dCBoYXBwZW5zIHdoZW4NCj4gYSBVUk4gcmVzb2x2ZXIgaXMgZ2l2ZW4gYW4gaW5kaWNhdG9yLW9u
bHkgVVJOICh3aXRoIG9yIHdpdGhvdXQNCj4gc2VydmljZSByZXF1ZXN0cykuICBUaG9zZSBpbmRp
Y2F0b3JzIChzZWUgUGV0ZXIncyBYTVBQIGV4YW1wbGUpDQo+IGRvbid0IGhhdmUgIm9iamVjdHMs
IG1ldGFkYXRhLCBvciB3aGF0ZXZlciIsIHRoZXkganVzdCBleGlzdCBvcg0KPiBkb24ndC4gIEkg
aW1hZ2luZSB3ZSBjb3VsZCBjb21lIHVwIHdpdGggYW4gZWxhYm9yYXRlIGRlZmluaXRpb24NCj4g
dGhhdCB3b3VsZCBjYXVzZSB0aGVtIHRvIGhhdmUgdmFsdWVzLCBldmVuIGlmIHRoZSB2YWx1ZXMg
d2VyZQ0KPiBzZWxmLWlkZW50aXR5LCBidXQgSSdtIG5vdCB5ZXQgcGVyc3VhZGVkIHRoYXQgc3Vj
aCBrbHVkZ2VzIGFyZQ0KPiB3b3J0aCB0aGUgY29zdHMuDQoNCkkgZ3Vlc3MgdGhlIHJlc29sdmVy
IHdvdWxkIGhhdmUgc29tZSBkZWZhdWx0IGJlaGF2aW91ci4uLiBUaGUgd29yc3QgY2FzZSBiZWlu
ZyAiSSBkb24ndCBrbm93IGhvdyB0byBoYW5kbGUgYSBVUk4gb2YgdHlwZSB1cm46ZXhhbXBsZTpm
b28iLiBJIHRoaW5rIGl0J3MgY2xlYXIgYnkgbm93IHRoYXQgcmVzb2x2ZXJzIGFyZSBOSUQtc3Bl
Y2lmaWMuDQoNCj4gPi4uLg0KPiA+PiA+IFllcywgdGVybWlub2xvZ3kgY2FuIGJlIGEgUElUQSwg
YnV0IHRoYXQncyBub3RoaW5nIHdlIGNhbg0KPiA+PiA+IGNoYW5nZSAobW9kdWxvIHVwZGF0aW5n
IDM5ODYpLg0KPiA+Pg0KPiA+PiBPciBzZXBhcmF0aW5nIFVSTnMgZnJvbSAzOTg2IGFuZCB0aGVu
IGRlZmluaW5nIHdoYXRldmVyIGlzDQo+ID4+IG5lZWRlZCB0byBiZSBkZWZpbmVkIGZvciBVUk5z
IGluIGEgVVJOLWFwcHJvcHJpYXRlIHdheS4gIFRoYXQNCj4gPj4gaXMgZXhhY3RseSB3aGF0ICJQ
bGFuIEIiIFsyXSBhbmQgIlVSTnMgYXJlIG5vdCBVUklzIiBhcmUNCj4gPj4gYWJvdXQuDQo+ID4N
Cj4gPiBTaW5jZSAiVVJOcyBhcmUgbm90IFVSSXMiIHJlcXVlc3RzIGFuIHVwZGF0ZSBvZiAzOTg2
IGFueXdheSwNCj4gPiB3aHkgY2FuJ3Qgd2UgdHJ5IHRvIG1vdmUgdGhlIF9zZW1hbnRpY3NfIG9m
IGZyYWdtZW50IG91dCBvZiBpdA0KPiA+IGFuZCBpbnRvIHRoZSBodHRwIHNwZWNpZmljYXRpb24g
aW5zdGVhZD8NCj4gDQo+IEknZCBiZSBkZWxpZ2h0ZWQgdG8uICBCdXQgc2VlIHRoZSAibm8gdGlt
ZSIgY29tbWVudHMgYWJvdmUgYW5kDQo+IG5vdGUgdGhhdCB0aGUgaW50ZWdyaXR5IG9mIDM5ODYg
aXMgdW5kZXIgYXR0YWNrIGZyb20gdGhlIFVSTA0KPiBzaWRlIGFzIHdlbGwgYW5kIHRoYXQgd2Ug
d291bGQgZG8gb3Vyc2VsdmVzIG5vIGZhdm9ycyBieSB0cnlpbmcNCj4gdG8gY2hhbmdlIGl0IGlu
IGRpdmVyZ2VudCBkaXJlY3Rpb25zIGFuZCB3aXRob3V0IGNvb3JkaW5hdGlvbi4NCg0KSSB3YXNu
J3QgYXdhcmUgb2YgdGhhdC4gQ2FuIHlvdSBwcm92aWRlIGEgcG9pbnRlciB0byB0aGF0IGRpc2N1
c3Npb24/IElmIHRoZXJlIGlzIGNvbW1vbiBncm91bmQgcmVnYXJkaW5nIHRlcm1pbm9sb2d5LCBm
dXp6IChha2EgInF1ZXJ5IikgYW5kIHJhbWJhLXphbWJhIChha2EgImZyYWdtZW50IikgcGVyaGFw
cyB0aGVyZSBpcyBzb21ldGhpbmcgY29taW5nIHVwLg0KDQo+IFB1dCBkaWZmZXJlbnRseSwgSSBi
ZWxpZXZlIHRoYXQgdGVhcmluZyBkb3duIDM5ODYgYW5kIGNsYXJpZnlpbmcNCj4gaXRzIGJvdW5k
YXJpZXMgd291bGQsIGluIGEgbW9yZSBwZXJmZWN0IHdvcmxkLCBiZSBleGFjdGx5IHRoZQ0KPiBy
aWdodCB0aGluZyB0byBkby4gIEluIG91ciBwcmVzZW50IHdvcmxkLCBJJ2QgcmF0aGVyIGdldCB0
aGUgVVJODQo+IHNwZWNzIG1vdmluZyBmb3J3YXJkIGFuZCBmaW5pc2hlZC4NCg0KSXQncyByZWFs
bHkgU2N5bGxhIG9yIENoYXJ5YmRpcywgaXNuJ3QgaXQ/IFdlIGNhbiBlaXRoZXIgZm9yayBVUk5z
IGZyb20gVVJJcyBvciByaXNrIHRoYXQgVVJOcyBhcmUgZm9ya2VkIGludG8gc29tZXRoaW5nIGVs
c2UuIEkgcmVhbGx5IGRvbid0IGtub3cgd2hhdCdzIHdvcnNlLg0KDQpDaGVlcnMsDQoNCkxhcnMN
Cg0K