From masinter@adobe.com Tue Feb 12 07:34:36 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8997B21F8E94 for ; Tue, 12 Feb 2013 07:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQlEWMMea0Ue for ; Tue, 12 Feb 2013 07:34:35 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id DEDE521F8E8B for ; Tue, 12 Feb 2013 07:34:32 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKURphBd44sa9l0E4/+4g9qDPBW6AKPCCQ@postini.com; Tue, 12 Feb 2013 07:34:34 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1CFVO1v012930; Tue, 12 Feb 2013 07:31:24 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r1CFYQXL025394; Tue, 12 Feb 2013 07:34:26 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Tue, 12 Feb 2013 07:34:25 -0800 From: Larry Masinter To: Keith Moore , "urn@ietf.org" Date: Tue, 12 Feb 2013 07:34:24 -0800 Thread-Topic: [urn] I-D Action: draft-saintandre-urn-example-00 Thread-Index: Ac33jpF/0BgYw8pTQq65qP7iwoS7vwRpidbg Message-ID: References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> <50ED9B48.7020604@network-heretics.com> <50ED9DD9.5030303@gmx.de> <50EDA00C.6080401@network-heretics.com> <50FCC1E1.3040803@network-heretics.com> In-Reply-To: <50FCC1E1.3040803@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:34:36 -0000 > On 01/19/2013 11:27 AM, Larry Masinter wrote: > > For my part, the only way I can make peace with URNs is to take the > perspective that "persistence" is wishful thinking, that "resource" is a = myth, > and that the primary use for URNs is a way of importing into the space of= URIs > those identifiers that are maintained by other organizations (namely, the > "naming authority"). >=20 > Which of course has nothing to do with the purpose of URNs. http://www.ietf.org/rfc/rfc1737.txt documents the purpose of URNs. The fifth bullet of section 2 "support of existing legacy naming systems". So "nothing to do with" is false. My point was that such uses are the primary use for URNs, and that URN namespaces that are not imports of other naming systems aren't as useful. > > Of course, you should only use naming authorities who can offer a credi= ble > promise of persistence of the association of the name to the thing named,= but > each service makes its own guarantees. IETF offers that "STD 66" names > something, even if the document changes, and that "RFC 3986" names > something which is currently the same document. But that also what it nam= es > is somewhat independent of the format it's set in, or the location. > > > > This description of URNs doesn't require anyone to believe in Resources= or > that URNs Name them, or that they do so Uniformly. It explains _most_ of= the > URN namespaces. > No it doesn't. it's just a mostly-coincidental characteristic of some UR= Ns. which URN namespaces (besides uuid) does it not explain? > > The only problem is the darn urn:uuid: namespace, where "uuid" is not a= n > authority at all, and there's nowhere to turn to figure out who might hav= e > known at any point in time what was meant by it. I don't know what to do = with > urn:uuid except to declare it a mistake. > That might not be a bad idea, but not for the reason you cite. >=20 > To attempt to define what URNs are in terms of what you observe about > URNs is to attempt to destroy their utility. URNs are already defined, I'm not attempting to redefine them. I'm pointing out that the URN syntax and semantics is useful in some circum= stances and not in others. If you're not importing someone else's naming system, do= n't bother with the extra four characters "urn:", just make a new URL scheme.=20 From moore@network-heretics.com Tue Feb 12 07:41:27 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F5B21F8EE1 for ; Tue, 12 Feb 2013 07:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANnlNwM5ojIi for ; Tue, 12 Feb 2013 07:41:26 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 67AEF21F8EDB for ; Tue, 12 Feb 2013 07:41:26 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 710BF2070F; Tue, 12 Feb 2013 10:41:25 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 12 Feb 2013 10:41:25 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=uK4zd6hRilpTjWtQzw1NNC 0agSA=; b=ncLtkd66PaK2bLeDe2MIHwJHVPYNAKZX1u/H/pnQVZ1cifne1hTBo1 JQB/F1NX7yDNN/zAvncDW//vN6GyJnapuBYs3AZDGXVlyErz9gaboYQgyjq6NRVL v2UjZ023+QrerccpS/or0ZkWBEhpE5w+Q+UUbSzIRaKvZ9t6OEGws= X-Sasl-enc: zg057a88XGApma/X3lv3UMgiZM9UM+0uxQTpB53Ul/s2 1360683684 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 704714827D7; Tue, 12 Feb 2013 10:41:24 -0500 (EST) Message-ID: <511A629F.1080600@network-heretics.com> Date: Tue, 12 Feb 2013 10:41:19 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Larry Masinter References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> <50ED9B48.7020604@network-heretics.com> <50ED9DD9.5030303@gmx.de> <50EDA00C.6080401@network-heretics.com> <50FCC1E1.3040803@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:41:27 -0000 On 02/12/2013 10:34 AM, Larry Masinter wrote: >> On 01/19/2013 11:27 AM, Larry Masinter wrote: >>> For my part, the only way I can make peace with URNs is to take the >> perspective that "persistence" is wishful thinking, that "resource" is a myth, >> and that the primary use for URNs is a way of importing into the space of URIs >> those identifiers that are maintained by other organizations (namely, the >> "naming authority"). >> >> Which of course has nothing to do with the purpose of URNs. > http://www.ietf.org/rfc/rfc1737.txt documents the purpose of URNs. > The fifth bullet of section 2 "support of existing legacy naming systems". > So "nothing to do with" is false. My point was that such uses are the > primary use for URNs, and that URN namespaces that are not imports > of other naming systems aren't as useful. The purpose of URNs is and always was to provide location-independent, persistent names for network-accessible resources. Where legacy naming systems provided similar facilities, the URN namespace was designed to accommodate them. But this was not a "purpose" for URNs, it was merely a desirable trait. And there's no reason to believe that "URN namespaces that are not imports of other naming systems aren't as useful". >>> Of course, you should only use naming authorities who can offer a credible >> promise of persistence of the association of the name to the thing named, but >> each service makes its own guarantees. IETF offers that "STD 66" names >> something, even if the document changes, and that "RFC 3986" names >> something which is currently the same document. But that also what it names >> is somewhat independent of the format it's set in, or the location. >>> This description of URNs doesn't require anyone to believe in Resources or >> that URNs Name them, or that they do so Uniformly. It explains _most_ of the >> URN namespaces. >> No it doesn't. it's just a mostly-coincidental characteristic of some URNs. > which URN namespaces (besides uuid) does it not explain? URNs are not defined by the characteristics you observe about them. URNs are defined by the relevant RFCs. >>> The only problem is the darn urn:uuid: namespace, where "uuid" is not an >> authority at all, and there's nowhere to turn to figure out who might have >> known at any point in time what was meant by it. I don't know what to do with >> urn:uuid except to declare it a mistake. >> That might not be a bad idea, but not for the reason you cite. >> >> To attempt to define what URNs are in terms of what you observe about >> URNs is to attempt to destroy their utility. > URNs are already defined, I'm not attempting to redefine them. Yes, you are. > I'm pointing out that the URN syntax and semantics is useful in some circumstances > and not in others. If you're not importing someone else's naming system, don't bother > with the extra four characters "urn:", just make a new URL scheme. That's complete and utter BS. Keith From internet-drafts@ietf.org Tue Feb 19 19:13:54 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC4321F887F; Tue, 19 Feb 2013 19:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qs12sbPBM0wg; Tue, 19 Feb 2013 19:13:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C129B21F8815; Tue, 19 Feb 2013 19:13:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130220031352.30658.57187.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2013 19:13:52 -0800 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:13:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Uniform Resource Name (URN) Namespace Definition Mechani= sms Author(s) : Peter Saint-Andre Leslie Daigle Renato Iannella Patrick Faltstrom Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05.txt Pages : 16 Date : 2013-02-19 Abstract: This document supplements the Uniform Resource Name (URN) syntax specification by defining the concept of a URN namespace, as well as mechanisms for defining and registering such namespaces. This document obsoletes RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3406bis-urn-ns-reg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc3406bis-urn-ns-reg-= 05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Tue Feb 19 19:20:56 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F8121F88FD for ; Tue, 19 Feb 2013 19:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 851HUB99j1SX for ; Tue, 19 Feb 2013 19:20:55 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 52EDA21F88EA for ; Tue, 19 Feb 2013 19:20:55 -0800 (PST) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3F3FB4004E for ; Tue, 19 Feb 2013 20:28:21 -0700 (MST) Message-ID: <51244115.5050301@stpeter.im> Date: Tue, 19 Feb 2013 20:20:53 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: urn@ietf.org References: <20130220031352.30658.57187.idtracker@ietfa.amsl.com> In-Reply-To: <20130220031352.30658.57187.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:20:56 -0000 Just a bit of editorial cleanup, including better alignment with RFC 3986 and RFC 5226. Peter On 2/19/13 8:13 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. > > Title : Uniform Resource Name (URN) Namespace Definition Mechanisms > Author(s) : Peter Saint-Andre > Leslie Daigle > Renato Iannella > Patrick Faltstrom > Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05.txt > Pages : 16 > Date : 2013-02-19 > > Abstract: > This document supplements the Uniform Resource Name (URN) syntax > specification by defining the concept of a URN namespace, as well as > mechanisms for defining and registering such namespaces. This > document obsoletes RFC 3406. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3406bis-urn-ns-reg > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From stpeter@stpeter.im Tue Feb 19 20:13:06 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151D421F879D for ; Tue, 19 Feb 2013 20:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.082 X-Spam-Level: X-Spam-Status: No, score=-102.082 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, FRT_ADOBE2=2.455, GB_I_LETTER=-2, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc3ssC04aIHK for ; Tue, 19 Feb 2013 20:13:05 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0367221F86CC for ; Tue, 19 Feb 2013 20:13:05 -0800 (PST) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B3DEF4004E; Tue, 19 Feb 2013 21:20:30 -0700 (MST) Message-ID: <51244D4D.3030302@stpeter.im> Date: Tue, 19 Feb 2013 21:13:01 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] call for comments: an alternative 2141bis document X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 04:13:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Old thread alert! On 11/26/12 8:47 AM, Ted Hardie wrote: > On Sun, Nov 25, 2012 at 4:47 AM, Larry Masinter > wrote: >> I'm not sure how useful it is to "capture the answer to the >> question: will this identifier ever by reassigned in the >> normal course of business?" >> >> I think the question was "why bother with the extra four 'urn:' >> letters, rather than just invent a new scheme?" and it's as >> useful to say that about blah:stuff as it is about >> urn:blah:stuff, and if you are handed a URL of the form >> "urn:blah:stuff" where you know nothing about "blah", you have no >> more information than you would have given "blah:stuff". Larry, we know that in practice most URIs are not of the form "blah:stuff" but "blah:stuff.com/heres-the-stuff". I agree with Ted (below) that DNS domain names might change hands more frequently than URN issuers. > If you mean, could the group have made "This is guaranteed not to > change, for some value of guaranteed" part of the meta-data in the > registration, rather than something signaled in the URI string, > sure. But as I'm sure you remember, there were visions at the time > of using a different resolution service to find instances of the > thing-that-a-urn-represents; had that turned out to be a common > resolution mechanism, then having a common signal to use it makes > sense. That's not quite the language in RFC 2276, but I think the > presumption of an RDS was a driver for using a unique string. > > Is it worth changing now, and converting existing URNs? Certainly > not, as that would violate the principle they were built under. > Could you now build a URI that had the same characteristics as a > URN, but did not use the string? Yep. The IESG historically would > have asked you "why isn't this a URN?", but since we're making > registration highly permissive, I'm not sure that they would > really need an answer. Ted, with respect to permissiveness, do you mean registration of URI schemes or URN namespaces (or something else)? >> (blah = uuid & stuff cryptographically securely randomly >> generated or not). >> >> I think you will have trouble defining "reassigned" and "normal >> course of business"... >> >> During the normal course of business http://host/path always >> means >>>>> talk to the host named "host", using whatever protocol is >>>>> currently meant by "http", asking for "/path" <<<< >> >> You probably mean something else by "reassigned", but there's a >> devil in the details of what it means in operational terms that >> make sense. >> > > I mean "the registration authority, the laws of physics, or some > mathematical principle state that if I have associated *this* URN > with *that* resource, it will never be associated with a different > resource during the likely lifetime of our civilization". DNS > names are re-assigned far more frequently than that. Agreed. And to Larry's original point, RFC 2141 says only that URNs) are *intended* to serve as persistent, location-independent resource identifiers. It doesn't guarantee that those intentions will be achieved in reality. Here's my interpretation (which doesn't necessarily take into account the history of discussion on this topic because I wasn't involved back then and I lack the full context that Larry, Ted, Leslie, et al. possess): 1. Persistent doesn't mean permanent (since nothing is permanent), it only means long-lived (or longer-lived than a location-dependent identifier). 2. Location-independent means the resource is not tied to a particular path at a particular DNS domain name via a particular access method. IMHO, persistence and location-independence are closely intertwined. I also think that it's good to have identifiers that are closer to being persistent and location-independent (or farther from being ephemeral and location-dependent), and I think that URNs as defined in the existing specs fit the bill. All we're trying to do here is modernize the definitions a bit to bring them in line with RFC 3986, RFC 5226, etc. Larry, do you have proposed changes to the text that would clarify the status of URNs in your mind? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJE1NAAoJEOoGpJErxa2pNSoP/RJgsEs2dukr940ZBpU6tCR0 Hr/Xb7M4M7LrWQPV5lhFx5sEIQFBai/+Q/GhHOKkkyIeRrbR1D2sO/1GFyW93lqX hOHJgWEq3vhPTkHBWj+38J3ndokLBXi/lVoYrD8rk6jC6VXszXBkPXsf4pmKTjFN sQH+QV+2pZ70k/b/ZjLmyKVfYUrJJ0WEkvyRqUGaQYCKoZHG7OOzBrDG7sS7XEUC GzHKPuoVVFdFiqeH9wE4Hz3fb+fgAEOGY2UNnM/Z4ZHnG+DB0qzID3nXARHWpGGh FlGlzk1RY9Lwqp+mEzgWK7rl/3Fm39nWckrHQGDxeJWK+klD8n12CSfNNNubombR j1YORDqsiVXtQ9EsZgQPVqZ9WvSTjYeYWB0HDpi8in6gniHAyE90Pox6hgnIVSY1 IyRIBfWJE+QNhlpCltR8/nYif48KcDcV4bkJgW6gQnAUC6XO/u22/bZQZS2eKENz G1ccNkh981VGlnrGtS1nqP9MzGOwyvFjOYSrNkwBqGVG486wbUSmiOCfGe/hZRh4 0XnIGkerFTUeHLF98ED+ZoRmcQGBxn+5y9hz+wauAUIlW6/LRh3K6YfQQUewpHW9 pWnaALOqAG0jaIBqUXKi2P05d5UbD5H6So1teoKgkkivRIT7SXsKNg/mNy8nDxCN yuQ627UL2DerIs1x5AHx =zJ13 -----END PGP SIGNATURE----- From moore@network-heretics.com Tue Feb 19 21:43:26 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C7D21F86FC for ; Tue, 19 Feb 2013 21:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAbS02IBHaek for ; Tue, 19 Feb 2013 21:43:24 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 78B8F21F86FB for ; Tue, 19 Feb 2013 21:43:24 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C63E720E83; Wed, 20 Feb 2013 00:43:23 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 20 Feb 2013 00:43:23 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=UYNrwIhPOiSJQi0jCa18Ir 8yXvA=; b=aZPhGZjxFTEL25b00LhsNIUvVXkIyDriCpsNvAbr1Xnkv1HKR8h3kr Z71dnDHZVQwszChjNPNpOjsjcb0HU3ulssE3UsqnClYUeNLES7CM2glwtTKQdL5h IDGYFlcGOEVF6SilDweHZspzxzm0yWAyij2qb3yjXvwHns9lbva4c= X-Sasl-enc: S6JrbEN9eJUkM9atcJYRTZuuSKWYB7mFaxecGoscMArB 1361339003 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id AFC0A482635; Wed, 20 Feb 2013 00:43:22 -0500 (EST) Message-ID: <51246277.1010604@network-heretics.com> Date: Wed, 20 Feb 2013 00:43:19 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Peter Saint-Andre References: <51244D4D.3030302@stpeter.im> In-Reply-To: <51244D4D.3030302@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] call for comments: an alternative 2141bis document X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 05:43:26 -0000 On 02/19/2013 11:13 PM, Peter Saint-Andre wrote: > > Agreed. > > And to Larry's original point, RFC 2141 says only that URNs) are > *intended* to serve as persistent, location-independent resource > identifiers. It doesn't guarantee that those intentions will be > achieved in reality. > > Here's my interpretation (which doesn't necessarily take into account > the history of discussion on this topic because I wasn't involved back > then and I lack the full context that Larry, Ted, Leslie, et al. possess): > > 1. Persistent doesn't mean permanent (since nothing is permanent), it > only means long-lived (or longer-lived than a location-dependent > identifier). Actually the binding between a URN and the resource, once assigned, was indeed intended to be permanent. That doesn't mean that the resource is permanently accessible (or ever accessible). And it was always understood that the resource could change (in the sense of being replaced with a later version of the same thing). But the URN should never be reassigned to a resource that is inconsistent with the original binding. > 2. Location-independent means the resource is not tied to a particular > path at a particular DNS domain name via a particular access method. It means all of that and more. For example, it also means that the meaning of the URN is the same from every location in the network. > IMHO, persistence and location-independence are closely intertwined. Yes, location-independence is a necessary condition for persistence. > I also think that it's good to have identifiers that are closer to > being persistent and location-independent (or farther from being > ephemeral and location-dependent), and I think that URNs as defined in > the existing specs fit the bill. All we're trying to do here is > modernize the definitions a bit to bring them in line with RFC 3986, > RFC 5226, etc. Of course I realize that no protocol specification can force any particular URN to be either persistent or location-independent forever. But that's not a justification to revise the URN specifications to dilute the intent of URNs. Keith From stpeter@stpeter.im Wed Feb 20 19:51:13 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B9121F8899 for ; Wed, 20 Feb 2013 19:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lttv4AtFfM4F for ; Wed, 20 Feb 2013 19:51:12 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B6DFB21F8BE0 for ; Wed, 20 Feb 2013 19:51:11 -0800 (PST) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CA395403CD; Wed, 20 Feb 2013 20:58:40 -0700 (MST) Message-ID: <512599AB.3040303@stpeter.im> Date: Wed, 20 Feb 2013 20:51:07 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Keith Moore References: <51244D4D.3030302@stpeter.im> <51246277.1010604@network-heretics.com> In-Reply-To: <51246277.1010604@network-heretics.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] call for comments: an alternative 2141bis document X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 03:51:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/19/13 10:43 PM, Keith Moore wrote: > On 02/19/2013 11:13 PM, Peter Saint-Andre wrote: >> >> Agreed. >> >> And to Larry's original point, RFC 2141 says only that URNs) are >> *intended* to serve as persistent, location-independent resource >> identifiers. It doesn't guarantee that those intentions will be >> achieved in reality. >> >> Here's my interpretation (which doesn't necessarily take into >> account the history of discussion on this topic because I wasn't >> involved back then and I lack the full context that Larry, Ted, >> Leslie, et al. possess): >> >> 1. Persistent doesn't mean permanent (since nothing is >> permanent), it only means long-lived (or longer-lived than a >> location-dependent identifier). > Actually the binding between a URN and the resource, once assigned, > was indeed intended to be permanent. That doesn't mean that the > resource is permanently accessible (or ever accessible). And it > was always understood that the resource could change (in the sense > of being replaced with a later version of the same thing). But > the URN should never be reassigned to a resource that is > inconsistent with the original binding. > >> 2. Location-independent means the resource is not tied to a >> particular path at a particular DNS domain name via a particular >> access method. > > It means all of that and more. For example, it also means that > the meaning of the URN is the same from every location in the > network. >> IMHO, persistence and location-independence are closely >> intertwined. > > Yes, location-independence is a necessary condition for > persistence. >> I also think that it's good to have identifiers that are closer >> to being persistent and location-independent (or farther from >> being ephemeral and location-dependent), and I think that URNs as >> defined in the existing specs fit the bill. All we're trying to >> do here is modernize the definitions a bit to bring them in line >> with RFC 3986, RFC 5226, etc. > > Of course I realize that no protocol specification can force any > particular URN to be either persistent or location-independent > forever. But that's not a justification to revise the URN > specifications to dilute the intent of URNs. Agreed on all points. I'm not yet sure how best to capture some of this in the spec, but I'll give it some thought and try to return with some proposed text. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJZmrAAoJEOoGpJErxa2paE4P/RrX8uvlFOLGThbM/zZCIFD2 zEi9nNlozFY0+YLEFnqhcQUTxszVDxpyOuDcfjk6zmfZXvGGx4BVdNnG30nCy74e JXCKPiHaoq4ibn0KyS+SPPSxqgqF4iqGX2kPfYY0yxXCW4VEUP9utnDCNaedYPzh 8pn5NRnM1sGoBzbHQBTqHoyEAzMMf9U8FpP3JRPVbtf6a3PBoJwmF99sDStuaYAD MMJLEc3kPINBu8wOgE5aLDFiwOfYbeulJqeD/JUwHeT5CN3JoLysUn2dX+CjS3st 6NAZpGbiJ/onMUeSbN+CDFU+d2jsEKbsTGA8C1M1tXfKWHiwBOVKntyt3DWcNu2e H2JfnDhMpA0panmqDoe02nR3kGdm6+h+7jYaJ5mbBUY+CGxJ4kc4gqlHCbYU7Hh0 pLGlzib//Q/iWFjW3pA8i9FmqxAswFjNZphXdnIAmKnJfa6lmEETbW+GyPI4+9yi yovtMsNWf0g/FlxSzNr7YPfYX2a2fOF+uWx4QaHcrFRfPsBZMU55oORvguK7Q2Ux YenSkV0DKIwcRqX15Mbo34ECGKp/JSNcaFq8aHFZQIXGw9x/NXviwcn26KEbaT3Q qbMptMrP+TJ6/eWxb3rkXkLcqruxga2LiNdE2b0MNr90V41Si9VSQFzZzt+TiHUu V66anAq2jLB6oefeUg/o =mfiT -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Feb 20 20:49:21 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F92221E808F for ; Wed, 20 Feb 2013 20:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ-FPOUXLWPP for ; Wed, 20 Feb 2013 20:49:20 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E68C921F8DD1 for ; Wed, 20 Feb 2013 20:49:19 -0800 (PST) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 36C4B403CD for ; Wed, 20 Feb 2013 21:56:49 -0700 (MST) Message-ID: <5125A74A.4030301@stpeter.im> Date: Wed, 20 Feb 2013 21:49:14 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "urn@ietf.org" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [urn] query component in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:49:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the interest of moving forward with rfc2141bis and with my document editor hat on, I've been reviewing list discussions and earlier document versions so that we can be clear about open issues. Because the fragment identifier issue is quite large and has received a lot of discussion, I've decided to focus first on the issue of query components in URNs. Juha Hakala mentioned the topic in late 2010: https://www.ietf.org/mail-archive/web/urn/current/msg01485.html "From the PersID point of view, both and are vitally important. We support the idea of reserving for the transfer of service parameters as a part of the resolution process." In March 2011, Juha again mentioned query components: https://www.ietf.org/mail-archive/web/urn/current/msg01507.html "As regards the URN syntax, the key issue - at least from my point of view - that should be discussed more widely is the usage of and in the way suggested in RFC2141bis. The reason why it is vital to make firm decisions concerning these features is that there are projects that intend to use both of them, and must have explicit permission and guidelines for doing that." Martin Duerst pointed out that nothing is really stopping us from allowing query components: https://www.ietf.org/mail-archive/web/urn/current/msg01510.html "That's quite different from the query part; if the urn spec wants to allow a "?" and some following stuff, it can do so, and it can put on the syntactic restrictions (as long as they are within the bounds of the URI spec) and semantic restrictions the WG deems appropriate." Although I don't claim to fully understand the proposed use of query components in URNs, it appears to be something that could be supported in, say, an HTTP-based resolution service. Thus a URN of urn:isbn:978-951-1-25645-8 could be resolved over HTTP: http://resolver.example.com/urn:isbn:978-951-1-25645-8?param=value However, that would not necessitate adding query components to URNs themselves. This appears to be consistent with something that Juha sent in August of 2011: https://www.ietf.org/mail-archive/web/urn/current/msg01574.html "The reason why URN:ISBN namespace does not allow fragments has to do with ISBN syntax. This is OK: http://urn.fi/URN:ISBN:978-952-10-7060-0 but I am not allowed to add anything to the namespace specific string even if the media type in which this book is published would allow that. Of course, adding would be OK since it would not be part of the identifier. " And: https://www.ietf.org/mail-archive/web/urn/current/msg01582.html "According to the RFC2141bis, fragment ID - if we allow its use in the URN syntax - will be part of the identifier. An identifier which consists of and ISBN and a fragment no longer identifies the book as a whole but a component part of it. Whereas ISBN with still identifies the book as a whole; the role of the is to specify the resolution service the user wants." The issue arose again in December of 2011: https://www.ietf.org/mail-archive/web/urn/current/msg01665.html "No, I was just emphasizing the point that if we piggyback service parameters in they will not be part of the URN itself. Whenever there are fundamental changes in technology, the URN itself remains the same, but the service parameters may be encoded differently." Confusingly (at least to me), in March of 2012 Juha made the following statement: https://www.ietf.org/mail-archive/web/urn/current/msg01735.html "As an aside, rfc3187bis is still out of date in the sense that it assumes (erroneously) that the is part of the NSS. If this were so, you could not use in the ISBN namespace since the ISBN standard does not allow the users to add anything to the ISBN string. But a construct where ISBN forms the NSS and and may be added to it, gives us free hands. I shall revise the I-D in this respect in the near future. Such revision requires also discussions with the International ISBN Agency, since via usage URN:ISBN gains functionality which is not available in the ISBN itself. " Notwithstanding that statement, Section 2.3 of draft-ietf-urnbis-rfc2141bis-urn-03 contained the following text: The part MUST NOT be present in any *assigned* URN. A part can only be added to an assigned URN and appear in a URI *reference* [RFC3986] to a URN that is intended to be used with URN resolution services, and, in the spirit of the general specification of this part in RFC 3986, its purpose is restricted to indicate the requested URN resolution service and particular service aspects of the intended resolution response, e.g., the kind of metadata or content sought that are bound to a given object identified by the basic, assigned URN. I draw two conclusions: 1. A query component would not be needed to provide a persistent, location-independent identifer for, say, an ISBN resource like 978-951-1-25645-8. 2. Aside from a possibly ambiguous statement from Juha, no one has proposed that we modify the URN syntax to allow query components in URNs. Unless someone objects, I shall consider this issue closed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJadKAAoJEOoGpJErxa2pbC0P/A5QqNb365I5oz+gskNLr0dV 5vq4zBawxgRDUG8jf67l4ZuMeF6aMXOpSlHoJN3VbXt6nfwPgW4w221MSVJM0Dna 4rT9xviSZEjEPxpjkIPrwskSesfTkBcC/C1uH1pGnyLOcC1c0xerBUCyo3vcQUAB de4+iC1JNhQjF7jGCC4WP2jPfpk9AvP70mZrcvd1bNmMJmdgczONIAT5PaAj0xQO WK5glcKwCNvB34IrGU/WJuJpaJJ8yYBSd5OFH76D/cI27yf/I+v5sZANQDfXFMpI rb1yZMDWk1xvuawUgshP0dyCVdGDcSmIQnNOLURbHMDqXqidC5rstid87vdpq+O+ zlW3ubvLYJjhIBhTLqiD6LpuImzxzJMtx0/r5Tb1f2D2iuDIZ0boO/7+gfXH7pZ3 pj2CjWc+DPNOz075kDUxoCJ4QUyMA6kNenvcCh5bkW1FIypu95sMic8NeqWJs/KE wyLbQxYjkNwO0EyiC2M6ItmqmxHFrWXaAVGzyMrLeNAQIyqpi7moBZJtfTrPQAGe 7K08txf/W232IIqJ6M67g2vuLgmAg4X7oIj5JxQAmnluOOvDYJyRa2tpl+zxWxIh Tdx2ImQFZkAsgseL0dcAUtvOmTryIHdQ2mnHGdelDoRgxe/5FyoJ8e+4IjFfThKF r5NtgfCu+AqRQyuO2O8z =43Sg -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Feb 20 21:13:28 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E30621F841D for ; Wed, 20 Feb 2013 21:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlZ4NOSOcYj2 for ; Wed, 20 Feb 2013 21:13:27 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C1EA121E809C for ; Wed, 20 Feb 2013 21:13:27 -0800 (PST) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 573A8403CD; Wed, 20 Feb 2013 22:20:57 -0700 (MST) Message-ID: <5125ACF2.2010205@stpeter.im> Date: Wed, 20 Feb 2013 22:13:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Juha Hakala References: <50D40B6F.9050200@helsinki.fi> In-Reply-To: <50D40B6F.9050200@helsinki.fi> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Transition of 2141bis and 3406bis X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 05:13:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Juha, my apologies for the delayed reply. One question inline about query components. On 12/21/12 12:10 AM, Juha Hakala wrote: > > On 27.11.2012 22:37, Andrew Newton wrote: >> It should be noted that these new documents are not the final >> output of this working group but are simply a new basis for the >> development of the milestones we must achieve, and they will be >> based on consensus within this working group and the IETF in >> accordance with IETF practices. > > I hope the WG will succeed in this task, and wish it would have > been possible to find consensus on how to use fragment and query. > Since this did not seem likely, the Finnish ISO TC 46 shadow > committee decided in its meeting 2012-12-10 to start the > development of a national URN syntax standard. The standard will be > bilingual (English and Finnish) and it will be based on the latest > 2141bis version Alfred Hoenes wrote. Our intention is to keep the > document downward compatible with whatever the URNbis WG will come > up with. Could you explain a bit more clearly the intended usage of query components in URNs? As far as I have been able to determine, no one has proposed to include query components in URNs themselves (e.g., "urn:isbn:978-951-1-25645-8?param=value"), only in URIs (mostly HTTP URIs) that encapsulate such a URN for resolution purposes and then append a query component to the end of the URI (say, "http://resolver.example.com/urn:isbn:978-951-1-25645-8?param=value"). Does the Finnish ISO TC 46 shadow committee plan to proceed along the URI path, or do they plan to include query components in URNs themselves? Could you also explain (perhaps in a separate thread) the intended use of the fragment identifier, as well as any other discrepancies between the shadow committee's approach and 2141bis and 3406bis as they stand today? Many thanks, Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJazyAAoJEOoGpJErxa2p+9IQAKeLUaovxAC6J1kmYFO6wYOi MMM+3ywObqB64iz2AgHVt0hq2fWO+B1GvlDWmEAiQZcQkDHICYkqSawyJrYqKU8O ljP7+19VlqbfvzOFuNJvo6FbnrVBTo3bcT0yKqqTt8EpI0qD7DE7yo8D1FfbOj1V 27Q5ydkK5tl2dagzkNYlgFj2cNRwluFCZvtSd0RZI/MrOd0IxD5GXZ1g4gOjRi9Q ZQkvQ0BliFaxbPGmJjtfIV9e2KotpPfRBjSf8Q+p9ETTt/3VMEHaa+VubMQeYy9N df/pJtAZMQAzrl+6zVgY3CR+LTUIX8zdUJ6DMs8wBSKhH3CgUz1rppKB7cAUulsB ZXPvl1oTstyYZHrbkicKed5MUA0yw5MZMYkRygcCWZx8wejM5RfXjVRMKHdDiTPO kH3s53hpk8+yyvfMkzWI8KIjErzW+ZJfW4Jq4SVgDcn/jLf0pB7Q3bAQCW4nw7J4 oSTsFyPB+BJYy3cW+CSbbW9DzgmUyUtJcsEs/I9WyWr3ILNFiN+/1dC3pvS1A+N9 GCGZ7iDm7E2r8uLbiEkmjiEvOP5ngbfmIdfEn/Z4anmytWMFv4+DJ5d+jTuEeHbV jyHc40eFGEGfTKMVJHFU8koZ4Lc/tf1figiWvvMmnIVECT3ttJke+kIf4vo8wW/+ dfZU65edw2k1eBmeKkwA =5mpd -----END PGP SIGNATURE----- From juha.hakala@helsinki.fi Wed Feb 20 23:05:49 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6585D21F8E05 for ; Wed, 20 Feb 2013 23:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhHijTrvybJx for ; Wed, 20 Feb 2013 23:05:48 -0800 (PST) Received: from smtp-rs2.it.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2D02B21F8E01 for ; Wed, 20 Feb 2013 23:05:46 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id r1L75hcp007779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Feb 2013 09:05:44 +0200 Message-ID: <5125C747.2030205@helsinki.fi> Date: Thu, 21 Feb 2013 09:05:43 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Peter Saint-Andre References: <50D40B6F.9050200@helsinki.fi> <5125ACF2.2010205@stpeter.im> In-Reply-To: <5125ACF2.2010205@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Transition of 2141bis and 3406bis X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 07:05:49 -0000 Hello Peter; all, See the answers below. On 21.2.2013 7:13, Peter Saint-Andre wrote: > Could you explain a bit more clearly the intended usage of query > components in URNs? As far as I have been able to determine, no one > has proposed to include query components in URNs themselves (e.g., > "urn:isbn:978-951-1-25645-8?param=value"), only in URIs (mostly HTTP > URIs) that encapsulate such a URN for resolution purposes and then > append a query component to the end of the URI (say, > "http://resolver.example.com/urn:isbn:978-951-1-25645-8?param=value"). > Does the Finnish ISO TC 46 shadow committee plan to proceed along the > URI path, or do they plan to include query components in URNs themselves? The plan is to continue the work started in URNBIS by Alfred Hoenes and others. That is, query components will not be a part of the URN (namespace specific string). They will always be added only after the URN has been assigned (by the publisher or somebody else), by e.g. the user requesting a resolution service, such as URI to URL as specified in RFC 2483. Typical use cases include a user who wants metadata about a book before e.g. purchasing or borrowing it; a user who wants to see the copyright statement of a video; a user who wants to see all the available variant versions (e.g. PDF, EPUB 3, OOXML and so on) of the article she wants to read; a user who wants to check with the help of preservation metadata what kind of differences there are in the look and feel between the oldest and subsequent versions of a still image. Since long term preservation of digital resources will be primarily based on migration, in due time there will be n versions available for each resource that has been available long enough (please remember that the time scale the national libraries are talking about is centuries, not decades). In this complex environment the digital archivists in national libraries, national archives etc. will need persistent identifiers and services provided by URN resolution. Being able to use query to ask for these services looks like a preferred way to move on. There are several reasons why query components cannot be part of the URN. From the formal point of view, most standard identifier systems do not allow adding anything to namespace specific string. From practical point of view, services depend on the technical infrastructure and will change over time. For instance, the list of services in RFC 2483 is insufficient and some of the services (especially URI to URC and URI to URCs) need service parameters; in the case of the above mentioned services, a user must be able to specify his metadata format preference. There is no way to specify a priori all the different query elements that can be attached to a URN. There are many ways in which service requests can be passed to the URN resolution service which will process them. IMHO the most convenient one is the query, now that RFC 3986 allows it. When the first set of URN RFCs was developed, this was not an option and workaround was developed; alas, DDDS as specified in RFC3401 etc. has never really become popular. In order to prevent proliferation of local query specifications, it is necessary to create a (global / public) registry which specifies the services and their parameters. Such registry would also provide a simple means for adding new services and service parameters; trying to nail them down in an RFC (as in RFC 2483) would only lead to constant need for updating that RFC when new kind of services emerge in the Internet / Web. So our plan is - if query is not incorporated in the official IETF URN syntax - to extend the IETF specification, and lay basis for a Finnish registry for URN resolution services. Of course we would prefer to have query (and fragment) included in the official IETF URN syntax. IMHO, f the aim is to align URNs with RFC 3986, incorporating both query and fragment usage into the URN syntax should be the URNBIS aim as well. > > Could you also explain (perhaps in a separate thread) the intended use > of the fragment identifier, as well as any other discrepancies between > the shadow committee's approach and 2141bis and 3406bis as they stand > today? Will do that. All the best, Juha > > Many thanks, > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRJazyAAoJEOoGpJErxa2p+9IQAKeLUaovxAC6J1kmYFO6wYOi > MMM+3ywObqB64iz2AgHVt0hq2fWO+B1GvlDWmEAiQZcQkDHICYkqSawyJrYqKU8O > ljP7+19VlqbfvzOFuNJvo6FbnrVBTo3bcT0yKqqTt8EpI0qD7DE7yo8D1FfbOj1V > 27Q5ydkK5tl2dagzkNYlgFj2cNRwluFCZvtSd0RZI/MrOd0IxD5GXZ1g4gOjRi9Q > ZQkvQ0BliFaxbPGmJjtfIV9e2KotpPfRBjSf8Q+p9ETTt/3VMEHaa+VubMQeYy9N > df/pJtAZMQAzrl+6zVgY3CR+LTUIX8zdUJ6DMs8wBSKhH3CgUz1rppKB7cAUulsB > ZXPvl1oTstyYZHrbkicKed5MUA0yw5MZMYkRygcCWZx8wejM5RfXjVRMKHdDiTPO > kH3s53hpk8+yyvfMkzWI8KIjErzW+ZJfW4Jq4SVgDcn/jLf0pB7Q3bAQCW4nw7J4 > oSTsFyPB+BJYy3cW+CSbbW9DzgmUyUtJcsEs/I9WyWr3ILNFiN+/1dC3pvS1A+N9 > GCGZ7iDm7E2r8uLbiEkmjiEvOP5ngbfmIdfEn/Z4anmytWMFv4+DJ5d+jTuEeHbV > jyHc40eFGEGfTKMVJHFU8koZ4Lc/tf1figiWvvMmnIVECT3ttJke+kIf4vo8wW/+ > dfZU65edw2k1eBmeKkwA > =5mpd > -----END PGP SIGNATURE----- -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From juha.hakala@helsinki.fi Thu Feb 21 03:36:34 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7321F8DA2 for ; Thu, 21 Feb 2013 03:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYV9s2P-92h6 for ; Thu, 21 Feb 2013 03:36:33 -0800 (PST) Received: from smtp-rs2.it.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) by ietfa.amsl.com (Postfix) with ESMTP id C04B821F8CED for ; Thu, 21 Feb 2013 03:36:30 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id r1LBaSS7003771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Feb 2013 13:36:29 +0200 Message-ID: <512606BC.7020902@helsinki.fi> Date: Thu, 21 Feb 2013 13:36:28 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "urn@ietf.org" , Peter Saint-Andre Content-Type: multipart/alternative; boundary="------------060301030606030704000506" Subject: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 11:36:34 -0000 This is a multi-part message in MIME format. --------------060301030606030704000506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello Peter; all, Concerning this: > Could you also explain (perhaps in a separate thread) the intended use > of the fragment identifier? It took a while before the bibliographic community got a sufficient grasp= of how fragment can best be used in the URN context. Initially we though= t that fragment should be part of the URN namespace specific string, but = we realized soon that that would complicate things a lot. Since many (mos= t, probably) standard namespaces do not allow add-ons to identifier strin= gs, this: Ex. 1http://urn.fi/URN:ISBN:978-952-10-7670-1 would have been possible, but not this (NOTE: this is only an example) Ex. 2http://urn.fi/URN:ISBN:978-952-10-7670-1#chapter2 Moreover, adding a fragment to an existing URN would in this case have be= en an act of identifier assignment, which in some namespaces is a managed= process, so too few people would have been allowed to use fragments with= URNs. Eventually Alfred Hoenes, myself and others concluded that the best solut= ion is to separate identification & URN assignment from fragment assignme= nt, that is, not to include fragment in the NSS. Which means that fragmen= ts can be added to the URN by anybody, any time after the URN has been as= signed and the document made available (via URN resolution) in the Intern= et. Then a typical use case is a scientist who wants to cite a structured (an= d identified) resource. For instance, citation to chapter 2 of the book w= ith ISBN978-952-10-7670-1 co= uld now be done with the HTTP URI in Example 2 above. Of course, using fr= agment is only possible if the URN is actionable, supports resolution to = the resource and the file format of that resource supports fragment in th= e spirit of RFC 3986. There are a lot of if's here, but this infrastructu= re is maintained by a national library / archive, service is likely to pe= rsist for quite some time. As an aside, standard guidelines for citing & referencing are out of date= =2E When PIDs are not assigned to start with, people have to use URLs whe= n citing networked resources. In some cases URLs are used even if there i= s a resolvable PID. Most of us have probably seen 5 -10 year old document= s in which most URL links in the reference list are already dead. This wi= ll make it very difficult to confirm that citing and referencing has been= made correctly, or that the cited document has ever even existed. It is = important to improve the situation by using PIDs such as URNs and DOIs, a= nd by providing guidelines on how to use them in citing & referencing. When fragment usage was last discussed on the list, the IETF community di= sapproved of the idea (if I remember correctly) on the basis that URNs wi= ll not be bound to a single manifestation of a resource, such as a PDF ve= rsion of a book. When the file format changes, the probability that the f= ragment no longer works is too close for comfort to 1. There are two responses to this. The obvious one is that if the fragment = is not part of the URN itself (but just tells the browser a location wher= e to go within the identified resource) the URN will nevertheless still b= e valid, and the user will get a modernized version of the resource. The = other one, with which the bibliographic community did not get anywhere, w= as that there are namespaces where identifiers must be assigned separatel= y for each manifestation of a resource. ISBN is an example of this, and a= lthough some publishers do misuse the system, the vast majority of ISBNs = have been correctly assigned - which means that we have a good reason to = believe that fragments would work fine longer than the browsers are able = to cope with the ancient file formats. Guaranteeing access to original ve= rsions of resources, or digital archaeology, may well keep the memory ins= titutions busy in the future... There may of course exist namespaces where fragments cannot be used. Ther= e are identifier systems for immaterial works (libraries do make a differ= ence between the original english version of "Hamlet"; its expressions in= other languages, and physical manifestations of these). There are identi= fiers for names, collections, metadata elements, and so on. These identif= iers do not have URN namespace registrations yet, but such registrations = can be made in the future. Therefore namespace registrations should say w= hether fragment usage is applicable at least in theory. In the same way, = they could provide examples of resolution services that can be supported.= Even if the IETF URN syntax specification would not say anything about th= e usage of fragment, the Finnish standard will. Given that RFC 3986 speci= fies fragment usage and all popular browsers support this functionality, = it is more or less certain that people start using fragments with URNs (e= xpressed as HTTP URIs) when e.g. citing documents. If guidelines for doin= g this are given in RFCs or other standards, it will be easier to co-ordi= nate and perhaps even foster this process, and to renew for instance ISO = 690, the standard for bibliographic referencing (http://en.wikipedia.org/= wiki/ISO_690). Best regards, Juha --=20 Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 =20 --------------060301030606030704000506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Hello Peter; all,

Concerning this:

Could you also explain (perhaps in a separate thread) the intended use
of the fragment identifier?
It took a while before the bibliographic community got a sufficient grasp of how fragment can best be used in the URN context. Initially we thought that fragment should be part of the URN namespace specific string, but we realized soon that that would complicate things a lot. Since many (most, probably) standard namespaces do not allow add-ons to identifier strings, this:

 Ex. 1 http://urn.fi/URN:ISBN:978-952-10-7670-1

would have been possible, but not this (NOTE: this is only an example)

Ex. 2  http://urn.fi/URN:ISBN:978-952-10-7670-1#chapter2

Moreover, adding a fragment to an existing URN would in this case have been an act of identifier assignment, which in some namespaces is a managed process, so too few people would have been allowed to use fragments with URNs. 

Eventually Alfred Hoenes, myself and others concluded that the best solution is to separate identification & URN assignment from fragment assignment, that is, not to include fragment in the NSS. Which means that fragments can be added to the URN by anybody, any time after the URN has been assigned and the document made available (via URN resolution) in the Internet. 

Then a typical use case is a scientist who wants to cite a structured (and identified) resource. For instance, citation to chapter 2 of the book with ISBN 978-952-10-7670-1 could now be done with the HTTP URI in Example 2 above. Of course, using fragment is only possible if the URN is actionable, supports resolution to the resource and the file format of that resource supports fragment in the spirit of RFC 3986. There are a lot of if's here, but this infrastructure is maintained by a national library / archive, service is likely to persist for quite some time. 

As an aside, standard guidelines for citing & referencing are out of date. When PIDs are not assigned to start with, people have to use URLs when citing networked resources. In some cases URLs are used even if there is a resolvable PID. Most of us have probably seen 5 -10 year old documents in which most URL links in the reference list are already dead. This will make it very difficult to confirm that citing and referencing has been made correctly, or that the cited document has ever even existed. It is important to improve the situation by using PIDs such as URNs and DOIs, and by providing guidelines on how to use them in citing & referencing. 

When fragment usage was last discussed on the list, the IETF community disapproved of the idea (if I remember correctly) on the basis that URNs will not be bound to a single manifestation of a resource, such as a PDF version of a book. When the file format changes, the probability that the fragment no longer works is too close for comfort to 1. 

There are two responses to this. The obvious one is that if the fragment is not part of the URN itself (but just tells the browser a location where to go within the identified resource) the URN will nevertheless still be valid, and the user will get a modernized version of the resource. The other one, with which the bibliographic community did not get anywhere, was that there are namespaces where identifiers must be assigned separately for each manifestation of a resource. ISBN is an example of this, and although some publishers do misuse the system, the vast majority of ISBNs have been correctly assigned - which means that we have a good reason to believe that fragments would work fine longer than the browsers are able to cope with the ancient file formats. Guaranteeing access to original versions of resources, or digital archaeology, may well keep the memory institutions busy in the future...

There may of course exist namespaces where fragments cannot be used. There are identifier systems for immaterial works (libraries do make a difference between the original english version of "Hamlet"; its expressions in other languages, and physical manifestations of these). There are identifiers for names, collections, metadata elements, and so on. These identifiers do not have URN namespace registrations yet, but such registrations can be made in the future. Therefore namespace registrations should say whether fragment usage is applicable at least in theory. In the same way, they could provide examples of resolution services that can be supported.  

Even if the IETF URN syntax specification would not say anything about the usage of fragment, the Finnish standard will. Given that RFC 3986 specifies fragment usage and all popular browsers support this functionality, it is more or less certain that people start using fragments with URNs (expressed as HTTP URIs) when e.g. citing documents. If guidelines for doing this are given in RFCs or other standards, it will be easier to co-ordinate and perhaps even foster this process, and to renew for instance ISO 690, the standard for bibliographic referencing (http://en.wikipedia.org/wiki/ISO_690). 

Best regards,

Juha

-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland 
 P.O.Box 15 (Unioninkatu 36, room 503)
 FIN-00014 Helsinki University
 tel +358 9 191 44293
--------------060301030606030704000506-- From jonathan.rees@gmail.com Thu Feb 21 05:56:34 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84FE21F8AD8 for ; Thu, 21 Feb 2013 05:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIPHxjCSLIo2 for ; Thu, 21 Feb 2013 05:56:31 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id C06D021F841C for ; Thu, 21 Feb 2013 05:56:19 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so7518812wge.22 for ; Thu, 21 Feb 2013 05:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2VVOomGSESeKEUDoqxh+JglpFt6LEjxpZrAk4ms/fRo=; b=rDxDWi2y7P9OdmrKhTBoB1MnOElgjU09PItl79gwMPaX8Jhr0qlEEeeTlkqRHY8ka3 Xqv60TTf5/t7b7zAGqyD1fqftfEfTG3rrMhKsroLPh8Xr7e80hKh2Pc1W4NuHOMzeMOl e6+C1l9cLuHfkudy5/FGraC1Lx7ylmYlDFE5+M08hdChzeEuG5bf06RtRoEWJtdDXTDc kT45Ngc0ATJ1LRFk9CEm6W0k/+vNnQgQKYJSsCuZSbXZJweBCKjxvty7yjW1pq8YRKGd 2VGsMP1iZfv1CwT1c7rpC9WM3HX6LQ2sWWIoAdOz7XCSaHpl06VP2Kn23pLIpE+GmDJz giAA== MIME-Version: 1.0 X-Received: by 10.180.8.197 with SMTP id t5mr41640116wia.27.1361454978891; Thu, 21 Feb 2013 05:56:18 -0800 (PST) Sender: jonathan.rees@gmail.com Received: by 10.216.114.200 with HTTP; Thu, 21 Feb 2013 05:56:18 -0800 (PST) In-Reply-To: <512606BC.7020902@helsinki.fi> References: <512606BC.7020902@helsinki.fi> Date: Thu, 21 Feb 2013 08:56:18 -0500 X-Google-Sender-Auth: QghKVBt_GoQU8_WXUJXHapCiaN4 Message-ID: From: Jonathan A Rees To: Juha Hakala Content-Type: multipart/alternative; boundary=f46d0442824065007f04d63c70f5 Cc: "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 13:56:34 -0000 --f46d0442824065007f04d63c70f5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2013 at 6:36 AM, Juha Hakala wrote= : > Hello Peter; all, > > When fragment usage was last discussed on the list, the IETF community di= sapproved of the idea (if I remember correctly) on the basis that URNs will= not be bound to a single manifestation of a resource, such as a PDF versio= n of a book. When the file format changes, the probability that the fragmen= t no longer works is too close for comfort to 1. > > That is not my recollection. The problem with defining fragment ids in th= e urn: registration is that fragment id semantics comes from RFC 3986 and simply cannot be changed or overridden by any URI scheme registration. Quoth 3986: Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications. Jonathan --f46d0442824065007f04d63c70f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 21, 2013 at 6:36 AM, Juha Ha= kala <juha.hakala@helsinki.fi> wrote:
=20 =20 =20 
Hello Peter; all,

When fragment usage was last discussed on the list, the IETF community disa=
pproved of the idea (if I remember correctly) on the basis that URNs will n=
ot be bound to a single manifestation of a resource, such as a PDF version =
of a book. When the file format changes, the probability that the fragment =
no longer works is too close for comfort to 1.
That is not my recollection. The problem with defin= ing fragment ids in the urn: registration is that fragment id semantics com= es from RFC 3986 and simply cannot be changed or overridden by any URI sche= me registration. Quoth 3986:
   Fragment i=
dentifier semantics are independent of the
   URI scheme and thus cannot be redefined by scheme specifications.
<= /div>
Jonathan

--f46d0442824065007f04d63c70f5-- From jehakala@mappi.helsinki.fi Thu Feb 21 06:52:46 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F1F21F8DFB for ; Thu, 21 Feb 2013 06:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv4M-hkX5U19 for ; Thu, 21 Feb 2013 06:52:45 -0800 (PST) Received: from smtp-rs2.it.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) by ietfa.amsl.com (Postfix) with ESMTP id DD93821F8DC9 for ; Thu, 21 Feb 2013 06:52:34 -0800 (PST) Received: from localhost (webmail-5.mappi.helsinki.fi [128.214.20.189]) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id r1LEqVG4030755; Thu, 21 Feb 2013 16:52:31 +0200 Received: from a88-114-110-201.elisa-laajakaista.fi (a88-114-110-201.elisa-laajakaista.fi [88.114.110.201]) by webmail.helsinki.fi (Horde Framework) with HTTP; Thu, 21 Feb 2013 16:52:31 +0200 Date: Thu, 21 Feb 2013 16:52:31 +0200 Message-ID: <20130221165231.Horde.u5Xz5_PLrvIpUNgzZbmThw4.jehakala@webmail.helsinki.fi> From: jehakala@mappi.helsinki.fi To: Jonathan A Rees References: <512606BC.7020902@helsinki.fi> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:52:46 -0000 Hello, As I said, our conclusion has been that fragment is not part of the URN (NSS). Therefore the fragment semantics comes from RFC 3986 and nowhere else. Note however that we should not talk about fragment identifiers; fragment is just something that is attached to the identifier as a guideline to the browser to take the user into a given location within the resource. If it were not possible to use fragment with URN, we might have two URIs (one URN and one URL) both resolving to the same resource (location), but it would only be OK to use fragment with the URL, although the fragment string would be exactly the same in both cases. I doubt this was the intention of RFC 3986. In practice, people will attach fragments to URNs (when they are expressed as HTTP URIs). For these Internet users, this will be like using fragments with URLs. It is important to support them by explaining the rules of the game for them in RFC 2141. Juha Quoting Jonathan A Rees : > On Thu, Feb 21, 2013 at 6:36 AM, Juha Hakala wrote: > >> Hello Peter; all, >> >> When fragment usage was last discussed on the list, the IETF >> community disapproved of the idea (if I remember correctly) on the >> basis that URNs will not be bound to a single manifestation of a >> resource, such as a PDF version of a book. When the file format >> changes, the probability that the fragment no longer works is too >> close for comfort to 1. >> >> That is not my recollection. The problem with defining fragment ids in the > urn: registration is that fragment id semantics comes from RFC 3986 and > simply cannot be changed or overridden by any URI scheme registration. > Quoth 3986: > > Fragment identifier semantics are independent of the > URI scheme and thus cannot be redefined by scheme specifications. > > Jonathan From andy@hxr.us Thu Feb 21 07:34:25 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF89F21F89B5 for ; Thu, 21 Feb 2013 07:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp7opinGJ6Ay for ; Thu, 21 Feb 2013 07:34:24 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id E635A21F8E7A for ; Thu, 21 Feb 2013 07:34:23 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id kl14so4772981pab.4 for ; Thu, 21 Feb 2013 07:34:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KE8RDYpFTEW0jpVWEYrag2/H4V+SWRqxQHWt0mGOCUI=; b=gtAlirSnE+o8UZPSpV6dLwNlacO4Rjcn6f3p1FoXzr3GeqyEutZhFk6q4qS5pcGDai 2XhLgrzcRtcFYvsUmWtrc/UTNoORXa20/xz/2tp101XJNvzCcf2hUPkf40s0YDi+WNXL p/8JmXlv9+3Q2ola1YFD3Z47NDwMeuBgtPULou7DpQwaA/XzK2uBuhpy+LKSqi3DQFr+ cejlOjHz0lERxPW3BsMBNXbbZMGa1rsUddTMm2hQHLXDOj2+ixfM3J2S8x9FADhl/E6o hdv1/7AKzQZBIuIAx+GIwFw89g+qutpeXEbEwp4jXD7V4KkSgEKLp+of4Kkp1Yx/qpPw yzbg== MIME-Version: 1.0 X-Received: by 10.68.129.9 with SMTP id ns9mr55849752pbb.16.1361460863718; Thu, 21 Feb 2013 07:34:23 -0800 (PST) Received: by 10.66.139.163 with HTTP; Thu, 21 Feb 2013 07:34:22 -0800 (PST) X-Originating-IP: [192.149.252.228] In-Reply-To: <5125C747.2030205@helsinki.fi> References: <50D40B6F.9050200@helsinki.fi> <5125ACF2.2010205@stpeter.im> <5125C747.2030205@helsinki.fi> Date: Thu, 21 Feb 2013 10:34:22 -0500 Message-ID: From: Andrew Newton To: Juha Hakala Content-Type: multipart/alternative; boundary=047d7b15afdb286c7e04d63dcf1e X-Gm-Message-State: ALoCoQmofM+ec4HdF6U524Sxlwxk04dpXvyPiGwaOD+6tRBZ3sypTHkx6VMddVphOCqLKePlIzZG Cc: "urn@ietf.org" Subject: Re: [urn] Transition of 2141bis and 3406bis X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:34:25 -0000 --047d7b15afdb286c7e04d63dcf1e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 21, 2013 at 2:05 AM, Juha Hakala wrote: > There are many ways in which service requests can be passed to the URN > resolution service which will process them. IMHO the most convenient one is > the query, now that RFC 3986 allows it. When the first set of URN RFCs was > developed, this was not an option and workaround was developed; alas, DDDS > as specified in RFC3401 etc. has never really become popular. I know we've had a lot of conversations about fragments, but I don't think adding query components has been discussed much here. Are there any specific objection to adding query to the URN syntax? -andy --047d7b15afdb286c7e04d63dcf1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Feb 21, 2013 at 2:05 AM, Juha Hakala <juha.hakala@helsinki.= fi> wrote:
There are many ways in which service request= s can be passed to the URN resolution service which will process them. IMHO= the most convenient one is the query, now that RFC 3986 allows it. When th= e first set of URN RFCs was developed, this was not an option and workaroun= d was developed; alas, DDDS as specified in RFC3401 etc. has never really b= ecome popular.

I know we've had a lot of conversations about fragments, but = I don't think adding query components has been discussed much here. Are= there any specific objection to adding query to the URN syntax?

-andy
--047d7b15afdb286c7e04d63dcf1e-- From ted.ietf@gmail.com Thu Feb 21 14:06:35 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D81A21F8E92 for ; Thu, 21 Feb 2013 14:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8kFNpwOrhJs for ; Thu, 21 Feb 2013 14:06:35 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1D41A21F8E79 for ; Thu, 21 Feb 2013 14:06:35 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k10so23378iea.19 for ; Thu, 21 Feb 2013 14:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=m86FutkQyWkx4EAgnmCQ61V2CsUGbP1ivlQsAZGcp5c=; b=uyt4ZUT0SVTlEy6LfTAV8ZoEJZmb/YqQGvuPYLcl5PTo9Me3hzOk6nAXEbJEQK/DYP XrrJ5DbXTpwNKKp2X+Yjv/BT+qA9pQFboQFfX7g6C+uwFYsLgeg+O5Gw10G4ItB8BM0W zdwtg9JrMuTscXfKxnlVKBhnahNWGir1bgfCaNHRtpecWU5AWMbG+KbSB7lZM1wCSxmN 0XAZ80cbXhh385efAmuGPpIjslm+c5Ma+L6pVNtsmVXfbQaNhj8nnJqgov1+olUpypzx NEIP2heYmrTi5ZcI24KArt8ISSaWlrAx3lek3FyPsZ36oRUVhS7vX+fwCA17G+gkd3ue ieaQ== MIME-Version: 1.0 X-Received: by 10.50.88.199 with SMTP id bi7mr13081979igb.70.1361484394753; Thu, 21 Feb 2013 14:06:34 -0800 (PST) Received: by 10.43.135.202 with HTTP; Thu, 21 Feb 2013 14:06:34 -0800 (PST) In-Reply-To: <51244D4D.3030302@stpeter.im> References: <51244D4D.3030302@stpeter.im> Date: Thu, 21 Feb 2013 14:06:34 -0800 Message-ID: From: Ted Hardie To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "urn@ietf.org" Subject: Re: [urn] call for comments: an alternative 2141bis document X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:06:35 -0000 On Tue, Feb 19, 2013 at 8:13 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Old thread alert! > > Ted, with respect to permissiveness, do you mean registration of URI > schemes or URN namespaces (or something else)? > I think my main point is that we now see the registration process differently. We want people to notify the community that they are using a particular scheme, so that we can avoid collision; to maximize that, we're minimize other sorts of review (including pushback like "this should be a URN"). Anyone can make the same claims about a new URI scheme as are made for a URN under that approach. Ted From stpeter@stpeter.im Thu Feb 21 18:52:00 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2243421F89C0 for ; Thu, 21 Feb 2013 18:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpRxJB1R-1gz for ; Thu, 21 Feb 2013 18:51:59 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C9C0E21F89B9 for ; Thu, 21 Feb 2013 18:51:58 -0800 (PST) Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DDB264060C; Thu, 21 Feb 2013 19:59:30 -0700 (MST) Message-ID: <5126DD44.30407@stpeter.im> Date: Thu, 21 Feb 2013 19:51:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Juha Hakala References: <50D40B6F.9050200@helsinki.fi> <5125ACF2.2010205@stpeter.im> <5125C747.2030205@helsinki.fi> In-Reply-To: <5125C747.2030205@helsinki.fi> X-Enigmail-Version: 1.5 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Transition of 2141bis and 3406bis X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 02:52:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/21/13 12:05 AM, Juha Hakala wrote: > Hello Peter; all, > > See the answers below. > > On 21.2.2013 7:13, Peter Saint-Andre wrote: >> Could you explain a bit more clearly the intended usage of query >> components in URNs? As far as I have been able to determine, no >> one has proposed to include query components in URNs themselves >> (e.g., "urn:isbn:978-951-1-25645-8?param=value"), only in URIs >> (mostly HTTP URIs) that encapsulate such a URN for resolution >> purposes and then append a query component to the end of the URI >> (say, >> "http://resolver.example.com/urn:isbn:978-951-1-25645-8?param=value"). >> >> Does the Finnish ISO TC 46 shadow committee plan to proceed along the >> URI path, or do they plan to include query components in URNs >> themselves? > The plan is to continue the work started in URNBIS by Alfred Hoenes > and others. That is, query components will not be a part of the > URN (namespace specific string). They will always be added only > after the URN has been assigned (by the publisher or somebody > else), by e.g. the user requesting a resolution service, such as > URI to URL as specified in RFC 2483. > > Typical use cases include a user who wants metadata about a book > before e.g. purchasing or borrowing it; a user who wants to see the > copyright statement of a video; a user who wants to see all the > available variant versions (e.g. PDF, EPUB 3, OOXML and so on) of > the article she wants to read; a user who wants to check with the > help of preservation metadata what kind of differences there are in > the look and feel between the oldest and subsequent versions of a > still image. Since long term preservation of digital resources will > be primarily based on migration, in due time there will be n > versions available for each resource that has been available long > enough (please remember that the time scale the national libraries > are talking about is centuries, not decades). In this complex > environment the digital archivists in national libraries, national > archives etc. will need persistent identifiers and services > provided by URN resolution. Being able to use query to ask for > these services looks like a preferred way to move on. > > There are several reasons why query components cannot be part of > the URN. From the formal point of view, most standard identifier > systems do not allow adding anything to namespace specific string. > From practical point of view, services depend on the technical > infrastructure and will change over time. For instance, the list of > services in RFC 2483 is insufficient and some of the services > (especially URI to URC and URI to URCs) need service parameters; in > the case of the above mentioned services, a user must be able to > specify his metadata format preference. There is no way to specify > a priori all the different query elements that can be attached to a > URN. > > There are many ways in which service requests can be passed to the > URN resolution service which will process them. IMHO the most > convenient one is the query, now that RFC 3986 allows it. When the > first set of URN RFCs was developed, this was not an option and > workaround was developed; alas, DDDS as specified in RFC3401 etc. > has never really become popular. In order to prevent proliferation > of local query specifications, it is necessary to create a (global > / public) registry which specifies the services and their > parameters. Such registry would also provide a simple means for > adding new services and service parameters; trying to nail them > down in an RFC (as in RFC 2483) would only lead to constant need > for updating that RFC when new kind of services emerge in the > Internet / Web. > > So our plan is - if query is not incorporated in the official IETF > URN syntax - to extend the IETF specification, and lay basis for a > Finnish registry for URN resolution services. Of course we would > prefer to have query (and fragment) included in the official IETF > URN syntax. IMHO, f the aim is to align URNs with RFC 3986, > incorporating both query and fragment usage into the URN syntax > should be the URNBIS aim as well. Juha, I am confused. First you say that "There are several reasons why query components cannot be part of the URN." Then you say that service parameters will be passed to URN resolution services using query components. Do you propose that service parameters will be passed by appending them to the URN but not as part of the URN itself? Do you have examples of what that would look like? My impression from your earlier messages was that the parameters would be passed in the query component of a URI, such as: http://resolver.example.com/urn:isbn:some-number?param=value But in that case the query component is not part of the URN, it is part of the URI. And if that's what you are proposing, then URNs still don't have query components. If I'm missing something here, please do tell. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJt1DAAoJEOoGpJErxa2p1CkP/2EJmD/6Dfn57fMnn/BPrqiX 2liceW+k9e9VZlhj4RRVxMk1wenDQDxq91mJL2j5OpPYF85A8g6J+gxXiEOCzFSi MyM+uCNpfwqESdxIpqPZf9WVttWKuG+j/SHG7QypOhy3WXGCrDE/7ndoPxv5nV5Z tdMvcw6wdQe1EFRIyPuq55EnkaFDz47l1y0Jgi596EIUczvb49DaOjCPdY2QvNBs 5NDTGGMKcBUmtqbYWzZrY7EqVwnTcIRs/2x/nLrdPIBtQDZQdst22rvjHLD26byS IeLRkS3Rz5fNfzeEE8/Js4aYEB4UgfVdE54vJ0x4PszZoGsUGw0djHFnwSTFgo3S QFJgbtGdrLOWKmcnrNicWn8svawAxT6YkzgmnPueHsk1pGlO5+AGd7g7MPmuDu/2 pGnlShfgiDrUFtqLJpNmQ3IPSUrR/qN+DldNGs0tMqtY6frQV0CHUNPAW4DsSsel hiWa2OsgpA0MBueWnIzmRHGu67jgk4fPFSnp9bP7uh1hkJoWwdey0Ra8MtXCUkVv EIKdbvo67tEdEeaTMmHtBuNAlhuqKJyyJ0xurY6+cEIq3RXWZpPmNOjFwp+s50HO 6/LEgQjc+/5AwlJZhWuKaZ0cIdO5/0CeUjHlS4MsbvzRu/5Ps5s6ApfajD91ODyp xsSvLK6+uumWKvdBK1pa =lmbZ -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Feb 21 19:37:11 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C947821E8054 for ; Thu, 21 Feb 2013 19:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UZUv6Wy3KYG for ; Thu, 21 Feb 2013 19:37:06 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 029CA21E803D for ; Thu, 21 Feb 2013 19:37:06 -0800 (PST) Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 773A54060C; Thu, 21 Feb 2013 20:44:38 -0700 (MST) Message-ID: <5126E7D6.6050301@stpeter.im> Date: Thu, 21 Feb 2013 20:36:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Juha Hakala References: <512606BC.7020902@helsinki.fi> In-Reply-To: <512606BC.7020902@helsinki.fi> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:37:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/21/13 4:36 AM, Juha Hakala wrote: > Hello Peter; all, > > Concerning this: >> Could you also explain (perhaps in a separate thread) the >> intended use of the fragment identifier? > It took a while before the bibliographic community got a > sufficient grasp of how fragment can best be used in the URN > context. Initially we thought that fragment should be part of the > URN namespace specific string, but we realized soon that that would > complicate things a lot. Since many (most, probably) standard > namespaces do not allow add-ons to identifier strings, this: > > Ex. 1http://urn.fi/URN:ISBN:978-952-10-7670-1 > > would have been possible, but not this (NOTE: this is only an > example) > > Ex. 2http://urn.fi/URN:ISBN:978-952-10-7670-1#chapter2 > > Moreover, adding a fragment to an existing URN would in this case > have been an act of identifier assignment, which in some namespaces > is a managed process, so too few people would have been allowed to > use fragments with URNs. > > Eventually Alfred Hoenes, myself and others concluded that the > best solution is to separate identification & URN assignment from > fragment assignment, that is, not to include fragment in the NSS. > Which means that fragments can be added to the URN by anybody, any > time after the URN has been assigned and the document made > available (via URN resolution) in the Internet. Hi Juha, this model sounds similar to what you described for the query component: the fragment can be "added to the URN". I'm not sure what that means. When you add a query component or a fragment identifier to the URN, is that now a different URN (which wasn't assigned by the minting organization or in accordance with the minting algorithm)? Or is "a URN with some additional data appended" and therefore not really a URN anymore? Or is actually a URI (such as an HTTP URI) whose path is the URN itself as just a string of characters embedded in the broader URI? Still confused, Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJufWAAoJEOoGpJErxa2pijYP/1Fq0JUQmr4r3oZg7rumqYB8 Y37kB4Um6e1/D/AYyMuebICyWU3dIIO5RckEr5Di+n15xMk3zREsIbbdvFWeKlIh /hX1LFPLEbqqlvG85GqSC9T2RA0uJE1mtX2NuJPoij6OkxfsPfzaiTI3eDbujTpA 4BUjiV3w53JHvwnAvkGZn/zwbzxColQayMAW4Mq2ivsnY8Xm+mCPPiIz8poiLekL fW0yCJl68wRfFM1hfs3w/NPMgphoMkmaX7F8FZScFH8WZjuz+/6tlcwbss9m79iL jTYQ/W4QlwD7KaxKtnhi3bKwaofEtaiPlW/Z3+VDrHGHxxjxh09kciluQ/zIIRsl 7F05ujTM+hWV2KnohOnrcWq7qEA2M0XXCFfuN7rOxtjefSu8o2RPTuF8Bjvr1Yh5 gUxvXuBf1SIyOvzcsDDkMBw7/9zC2JmWfF3UiKBXurSbjrdJPQ6KjF9pQ2fTrai0 04os0sCMNNuqbUI3aL5zUZCibS4RNQRgjywGnkpnnp8YW7Txm3nYmsdBXP1CUfEt xy6gvdPfBDFSnBpBIROZ5Cz3HbLoD/waXM4HaNUgv2b8h4crXTnmy5Goq8gU+nBY fRC/lB8XCHFy3a5JRW61PXNey8O7J2zsi/ifcPocw7y5yi/GvGDOIVOMzR3wgGy4 9p+yG1IDbBxifHOy77j/ =Zpj0 -----END PGP SIGNATURE----- From duerst@it.aoyama.ac.jp Thu Feb 21 20:11:08 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243EA21E804B for ; Thu, 21 Feb 2013 20:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.326 X-Spam-Level: X-Spam-Status: No, score=-106.326 tagged_above=-999 required=5 tests=[AWL=-2.536, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hki06oPLgIpl for ; Thu, 21 Feb 2013 20:11:01 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 448E221E803D for ; Thu, 21 Feb 2013 20:11:00 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r1M4At2u009779 for ; Fri, 22 Feb 2013 13:10:56 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2ae8_94cc_daa77f16_7ca5_11e2_900e_001d096c5782; Fri, 22 Feb 2013 13:10:54 +0900 Received: from [IPv6:::1] ([133.2.210.1]:60943) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 22 Feb 2013 13:10:56 +0900 Message-ID: <5126EFC7.6080201@it.aoyama.ac.jp> Date: Fri, 22 Feb 2013 13:10:47 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> In-Reply-To: <5126E7D6.6050301@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 04:11:08 -0000 On 2013/02/22 12:36, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/21/13 4:36 AM, Juha Hakala wrote: >> Eventually Alfred Hoenes, myself and others concluded that the >> best solution is to separate identification& URN assignment from >> fragment assignment, that is, not to include fragment in the NSS. >> Which means that fragments can be added to the URN by anybody, any >> time after the URN has been assigned and the document made >> available (via URN resolution) in the Internet. > > Hi Juha, this model sounds similar to what you described for the query > component: the fragment can be "added to the URN". I'm not sure what > that means. When you add a query component or a fragment identifier to > the URN, is that now a different URN (which wasn't assigned by the > minting organization or in accordance with the minting algorithm)? Or > is "a URN with some additional data appended" and therefore not really > a URN anymore? Or is actually a URI (such as an HTTP URI) whose path > is the URN itself as just a string of characters embedded in the > broader URI? This is different for the query part and for the fragment part. The fragment part is independent of the scheme. The query part is not. You will see that in Appendix A of RFC 3986 (http://tools.ietf.org/html/rfc3986#appendix-A). There, URI is defined as including an (optional) fragment part, but absolute-URI is defined excluding the fragment part. Same in RFC 3987 for IRIs. So in terms of terminology, it might be possible to call an URN without a fragment part an absolute URN (in places where such a distinction is necessary). For fragments, the conclusion that Juha explains above is how it was intended for all URIs from the start, and how RFC 3986 is written. It may have taken some time for the URN community to arrive at this point, but it's a very good conclusion, because it's what works best with the rest of the infrastructure. Regards, Martin. From juha.hakala@helsinki.fi Thu Feb 21 22:57:17 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62AF21F8F36 for ; Thu, 21 Feb 2013 22:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcovSMp9gBu6 for ; Thu, 21 Feb 2013 22:57:17 -0800 (PST) Received: from smtp-rs2.it.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) by ietfa.amsl.com (Postfix) with ESMTP id CCFEC21F8F35 for ; Thu, 21 Feb 2013 22:57:15 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id r1M6vBMe031654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 08:57:14 +0200 Message-ID: <512716C6.4090308@helsinki.fi> Date: Fri, 22 Feb 2013 08:57:10 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Peter Saint-Andre References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> In-Reply-To: <5126E7D6.6050301@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:57:17 -0000 Hi, On 22.2.2013 5:36, Peter Saint-Andre wrote: > Hi Juha, this model sounds similar to what you described for the query > component: the fragment can be "added to the URN". I'm not sure what > that means. When you add a query component or a fragment identifier to > the URN, is that now a different URN (which wasn't assigned by the > minting organization or in accordance with the minting algorithm)? Or > is "a URN with some additional data appended" and therefore not really > a URN anymore? Or is actually a URI (such as an HTTP URI) whose path > is the URN itself as just a string of characters embedded in the > broader URI? Despite the addition of fragment and query the URN itself remains the same, even though the HTTP URI changes. "Added to the URN" means that neither query nor fragment are part of the URN, or more specifically, its namespace specific string. When something is identified, more or less formally, the NSS is and must always be sufficient for that, and RFC 2141 does not provide any functionality beyond that. Full alignment with RFC 3986 would in this interpretation mean that once a resource has been identified with a URN, anybody can add a fragment to the URN in order to pinpoint a location within the resource (for the browsers to act upon), or a query to demand a service from the URN resolver. Syntactically and semantically this interpretation should match the one in RFC 3986. Note that fragments do not identify anything since they are not part of the NSS. IMHO, since we must use RFC 3986 as the starting point it is not even appropriate to say that in the URN context fragment actually identifies something. So Peter's term "fragment identifier" above is not proper language :-). One reason why we should clarify the usage of fragment and query in the URN context is that there is a need to explain which fragment + query combinations make sense. In principle, it is only possible to use fragment when the resource itself is requested. In practice, there may be namespaces or service environments in which the situation is or will be more complicated than that. Juha -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From moore@network-heretics.com Sat Feb 23 19:58:16 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEED21F8F4A for ; Sat, 23 Feb 2013 19:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ+amKNN2sd5 for ; Sat, 23 Feb 2013 19:58:15 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id C836B21F8DEF for ; Sat, 23 Feb 2013 19:58:15 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AF776206F8; Sat, 23 Feb 2013 22:58:14 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 23 Feb 2013 22:58:14 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Kiay25ZTfKbetotKkjtBBx nhLu8=; b=gqIxFBOkYLr++tIKz3kHSayXraJ/Oh2q4rlRBfAh4o2TKZoN7D0b5Q fZU3ni1xIq8fYjtrtsiiFQVjaFeeWZi+ztzv+gAjrebxGhmZOm30Zr26BMRfnZOv aGm4GuPhYtxK4Veith4zDlMMHe6WvTNY9hl3DQt5QqSHgxQMsq6+Y= X-Sasl-enc: LJAGVAdKbXmcUN7tJcrf0ZH3eAuyJKWjCGQjQCQXlgD9 1361678294 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0007348260E; Sat, 23 Feb 2013 22:58:13 -0500 (EST) Message-ID: <51298FD3.9030405@network-heretics.com> Date: Sat, 23 Feb 2013 22:58:11 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Peter Saint-Andre References: <5125A74A.4030301@stpeter.im> In-Reply-To: <5125A74A.4030301@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] query component in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 03:58:16 -0000 On 02/20/2013 11:49 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In the interest of moving forward with rfc2141bis and with my document > editor hat on, I've been reviewing list discussions and earlier > document versions so that we can be clear about open issues. > > Because the fragment identifier issue is quite large and has received > a lot of discussion, I've decided to focus first on the issue of query > components in URNs. > > Juha Hakala mentioned the topic in late 2010: > > https://www.ietf.org/mail-archive/web/urn/current/msg01485.html > > "From the PersID point of view, both and are > vitally important. We support the idea of reserving for the > transfer of service parameters as a part of the resolution process." Why should query semantics for URNs be different than for other URIs? i.e. Why isn't a query on a URN semantically equivalent to the same query on the underlying resource? Similarly, why isn't a fragment on a URN semantically equivalent to the same fragment of the underlying resource? (granted, fragments are problematic for any kind of resource that can map to different formats with different ways of specifying fragments, but that's no worse for URNs than for any other kind of URI for which content-negotiation comes into play) I don't think it makes sense to overload URN query and fragment semantics to mean different things than they mean for other URIs. Keith From juha.hakala@helsinki.fi Mon Feb 25 01:19:07 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4601D21F91F7 for ; Mon, 25 Feb 2013 01:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5F8KsldxhHU for ; Mon, 25 Feb 2013 01:19:05 -0800 (PST) Received: from smtp-rs2.it.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA9821F914D for ; Mon, 25 Feb 2013 01:19:00 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id r1P9IvMn029551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 25 Feb 2013 11:18:58 +0200 Message-ID: <512B2C81.3090901@helsinki.fi> Date: Mon, 25 Feb 2013 11:18:57 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: urn@ietf.org References: <5125A74A.4030301@stpeter.im> <51298FD3.9030405@network-heretics.com> In-Reply-To: <51298FD3.9030405@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] query component in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 09:19:07 -0000 Hello, On 24.2.2013 5:58, Keith Moore wrote: > > Why should query semantics for URNs be different than for other URIs? Query semantics for URN will be richer than for other URIs due to extra functionality supported by resolution services. Queries specific to the URN will be processed by the appropriate URN resolution service, which will not pass them on as such. Instead they will be mapped to the form supported by the appropriate target system. For instance, if the requested service is I2C (URI to URC), the resolution service would map the URN into a search statement encoded as HTTP URI. The exact syntax of the search will depend on search / retrieval protocol used. Let us assume that a user wants metadata related to a book he's interested in. The client he's using would assemble a URN in the format URN:ISBN: plus a query indicating that the user wants resource description in Dublin Core format. Choosing the OPAC of the Library of Congress OPAC as the target, the URN resolver would map the URN sent by the client system into a HTTP URI like this: http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dc.identifier &maximumRecords=1&recordSchema=dc For any recent book in English there are literally hundreds of relatively complex HTTP URIs (targeting various library OPACs, union catalogues etc.) which could produce the same result. But from the user's point of view, the syntactically simple URN and complex HTTP URIs it can be mapped to are semantically equivalent. Please note that the HTTP URI above is based on the SRU protocol (http://www.loc.gov/standards/sru/), which became an OASIS standard a couple of weeks back. Many library systems support (also) other query protocols which encode the queries as HTTP URIs (while some protocols, like Z39.50, do not). But although reasonably stable, these query URIs are not intended to be "cool" (whatever that means) and keeping them cool would be a real pain in the neck. However, in URN resolvers it should be possible to keep track on changing database addresses, protocols & protocol versions, etc. Therefore URN query may provide the library community a means of providing persistent links to resources, in spite of our ever evolving service infrastructure in which it would be very hard or impossible to keep the URIs "cool". Specifying in the URN-related RFCs a subset of queries which will be processed by the URN resolvers should not prevent the usage of other kind of queries which the resolution service will just pass on to the appropriate target system (as a part of appropriate HTTP URI). > i.e. Why isn't a query on a URN semantically equivalent to the same > query on the underlying resource? > > Similarly, why isn't a fragment on a URN semantically equivalent to > the same fragment of the underlying resource? Unless I have missed something, fragment on a URN is semantically equivalent to the fragment of the underlying resource. Fragment on a URN only specifies a location within the identified resource; it does not identify any part of that resource. Best regards, Juha > (granted, fragments are problematic for any kind of resource that can > map to different formats with different ways of specifying fragments, > but that's no worse for URNs than for any other kind of URI for which > content-negotiation comes into play) > > I don't think it makes sense to overload URN query and fragment > semantics to mean different things than they mean for other URIs. > > Keith > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From moore@network-heretics.com Mon Feb 25 06:41:00 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861F921F939A for ; Mon, 25 Feb 2013 06:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beMZAAi0ogvr for ; Mon, 25 Feb 2013 06:40:59 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 881B621F9398 for ; Mon, 25 Feb 2013 06:40:59 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D86ED20C22; Mon, 25 Feb 2013 09:40:58 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 25 Feb 2013 09:40:58 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=BaC2Y3pFJlph5bG7cV9xUo Tz1Lw=; b=GM4ZhpVqAtBNMB8F6vLAqGqbTsSckPnyHSi7vSilK7OpziunPKd0sP fqrJTHSBJjUsVATmjeNCPAMj6JNqV3ftnrpTbW285eVxqNdUP3GtOsKugZk5uPHW 3qt/uGemLcfAED3US0cFh+Kbqva7BaJqlPcZCQF7HAn7A5vLdtShc= X-Sasl-enc: Tg3yAyySnoX1QkPH9H9qkLn/HfgWQRat4q44Ay8nHNh0 1361803258 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 36A5848277C; Mon, 25 Feb 2013 09:40:58 -0500 (EST) Message-ID: <512B77F9.6060908@network-heretics.com> Date: Mon, 25 Feb 2013 09:40:57 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Juha Hakala References: <5125A74A.4030301@stpeter.im> <51298FD3.9030405@network-heretics.com> <512B2C81.3090901@helsinki.fi> In-Reply-To: <512B2C81.3090901@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] query component in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:41:00 -0000 On 02/25/2013 04:18 AM, Juha Hakala wrote: > Hello, > > On 24.2.2013 5:58, Keith Moore wrote: >> >> Why should query semantics for URNs be different than for other URIs? > > Query semantics for URN will be richer than for other URIs due to > extra functionality supported by resolution services. Queries specific > to the URN will be processed by the appropriate URN resolution > service, which will not pass them on as such. Instead they will be > mapped to the form supported by the appropriate target system. Uh, no. The entire space of URI queries is specific to the target system. In general, any resource (not just those named by URNs) is potentially able to have different services requested from it. That the URI syntax doesn't support a way to ask for each service is perhaps unfortunate, but for better or worse, that's the way it was designed. Making the URI syntax work differently for URNs than the way it works for other resource names is not a good idea. Keith From julian.reschke@gmx.de Tue Feb 26 08:01:23 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B1921F8901 for ; Tue, 26 Feb 2013 08:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.773 X-Spam-Level: X-Spam-Status: No, score=-104.773 tagged_above=-999 required=5 tests=[AWL=-2.174, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e690-ZiJQ0Ng for ; Tue, 26 Feb 2013 08:01:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 490D721F8921 for ; Tue, 26 Feb 2013 08:01:16 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M7nFW-1V5LJ33kPY-00vQCR for ; Tue, 26 Feb 2013 17:01:13 +0100 Received: (qmail invoked by alias); 26 Feb 2013 16:01:13 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 26 Feb 2013 17:01:13 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18m4e9KfIMmDVOJetb3ghdJentyvN8c4PseA4u4Tz hITOzYDaeSp0/U Message-ID: <512CDC48.9070703@gmx.de> Date: Tue, 26 Feb 2013 17:01:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Juha Hakala References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> <512716C6.4090308@helsinki.fi> In-Reply-To: <512716C6.4090308@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:01:23 -0000 On 2013-02-22 07:57, Juha Hakala wrote: > Hi, > > On 22.2.2013 5:36, Peter Saint-Andre wrote: >> Hi Juha, this model sounds similar to what you described for the query >> component: the fragment can be "added to the URN". I'm not sure what >> that means. When you add a query component or a fragment identifier to >> the URN, is that now a different URN (which wasn't assigned by the >> minting organization or in accordance with the minting algorithm)? Or >> is "a URN with some additional data appended" and therefore not really >> a URN anymore? Or is actually a URI (such as an HTTP URI) whose path >> is the URN itself as just a string of characters embedded in the >> broader URI? > > Despite the addition of fragment and query the URN itself remains the > same, even though the HTTP URI changes. > ... Well, it's a different string, thus a different URN. > ... Best regards, Julian From stpeter@stpeter.im Tue Feb 26 09:10:27 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC00E21F89E1 for ; Tue, 26 Feb 2013 09:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXDX3Vbodc34 for ; Tue, 26 Feb 2013 09:10:26 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D382921F86FA for ; Tue, 26 Feb 2013 09:10:26 -0800 (PST) Received: from [10.0.0.2] (unknown [24.9.182.250]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DEBD14004E; Tue, 26 Feb 2013 10:18:13 -0700 (MST) Message-ID: <512CEC80.8020702@stpeter.im> Date: Tue, 26 Feb 2013 10:10:24 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Julian Reschke References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> <512716C6.4090308@helsinki.fi> <512CDC48.9070703@gmx.de> In-Reply-To: <512CDC48.9070703@gmx.de> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 17:10:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/26/13 9:01 AM, Julian Reschke wrote: > On 2013-02-22 07:57, Juha Hakala wrote: >> Hi, >> >> On 22.2.2013 5:36, Peter Saint-Andre wrote: >>> Hi Juha, this model sounds similar to what you described for >>> the query component: the fragment can be "added to the URN". >>> I'm not sure what that means. When you add a query component or >>> a fragment identifier to the URN, is that now a different URN >>> (which wasn't assigned by the minting organization or in >>> accordance with the minting algorithm)? Or is "a URN with some >>> additional data appended" and therefore not really a URN >>> anymore? Or is actually a URI (such as an HTTP URI) whose path >>> is the URN itself as just a string of characters embedded in >>> the broader URI? >> >> Despite the addition of fragment and query the URN itself remains >> the same, even though the HTTP URI changes. ... > > Well, it's a different string, thus a different URN. Correct. As Martin suggested, one might refer to the organizationally-assigned or algorithmically-determined URN as an "absolute URN", but that doesn't change the fact that absolute+query or absolute+fragment is still a different URN. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLOx/AAoJEOoGpJErxa2p9aMQAKoZUm0Uq0Sa0xQ23TsmKqhL i7C4PKkYJ8dpjKWJ65SVFTKn1jCr+td2oR+qNMny7MqGm58GTcmmkYmTPlCx39I8 UhpAXw3jL9HXScLpdUCGtV3IPPuiMVT+FLHfqVdXm/sbew/ICe9KwDVmCYKEve0y fMzlW3PdQPPjncBjTFdHsPpmAVS/gn7NZ4sX7hD8q2bMn3Cym+bSjRRK8L4k/it8 h+xGPOXi6waOE4EfZJcL2Sme+4u5uN98aSE6lBxa1J1J9L8ZzNU7z1hhdrv+iztH 1yT1QaS2jEj5uN7V8dhI6LkRf3yy883j8WKyBs4BvLYQG++C+hboQgyAuh/O7+O5 LmHQtsLPQWjsNoawa2lceAs+MNcLVH3+PPkT6jJ3rxPDITYay/d/0Byr6SAPYs6Y mfiWg5w+1A69KSEu+n9nJnpPyqoUZBjJ8YfiiwIr1F/Ft1NjFD2+vpTKGFsj06Ry 0xwZH5WMinlpMhXLnztKvWBgx/9d0RbLlxsYNvzw7+v1NM0dMmaAWfmr90g1Xiyq h4t6RIaYRxkYsmEx3AEWDGw7jtV+rgUtI3Jf1qn8iS6R/BmIWYpyiKvuwVRu1Lke apGp7nFROuv7g2AntWPi7Ur8av6TfZijllcmKSwhxAVHeKj5JU+BHz+BeZvlN5js UbAwq+ORA7UFM8MtGlnR =EMFB -----END PGP SIGNATURE----- From jehakala@mappi.helsinki.fi Tue Feb 26 11:26:39 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CCE21F86C5 for ; Tue, 26 Feb 2013 11:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8hhVe6avnkg for ; Tue, 26 Feb 2013 11:26:34 -0800 (PST) Received: from smtp-rs2.it.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) by ietfa.amsl.com (Postfix) with ESMTP id C365D21F87CC for ; Tue, 26 Feb 2013 11:26:31 -0800 (PST) Received: from localhost (webmail-5.mappi.helsinki.fi [128.214.20.189]) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id r1QJQLPx025847; Tue, 26 Feb 2013 21:26:21 +0200 Received: from a88-114-110-201.elisa-laajakaista.fi (a88-114-110-201.elisa-laajakaista.fi [88.114.110.201]) by webmail.helsinki.fi (Horde Framework) with HTTP; Tue, 26 Feb 2013 21:26:21 +0200 Date: Tue, 26 Feb 2013 21:26:21 +0200 Message-ID: <20130226212621.Horde.y3L08bLxxMiNJYU7FS9abA1.jehakala@webmail.helsinki.fi> From: jehakala@mappi.helsinki.fi To: Peter Saint-Andre References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> <512716C6.4090308@helsinki.fi> <512CDC48.9070703@gmx.de> <512CEC80.8020702@stpeter.im> In-Reply-To: <512CEC80.8020702@stpeter.im> User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:26:39 -0000 Hello, Quoting Peter Saint-Andre : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/26/13 9:01 AM, Julian Reschke wrote: >> On 2013-02-22 07:57, Juha Hakala wrote: >>> Despite the addition of fragment and query the URN itself remains >>> the same, even though the HTTP URI changes. ... >> >> Well, it's a different string, thus a different URN. > > Correct. As Martin suggested, one might refer to the > organizationally-assigned or algorithmically-determined URN as an > "absolute URN", but that doesn't change the fact that absolute+query > or absolute+fragment is still a different URN. It is a different string, thus a different URI, as dictated by RFC 3986. But it is the same URN, since fragment is not part of the Namespace specific string, as specified by the Alfred Hoenes' version of the URN syntax, or any other syntax specification which approves the current idea that fragment is not part of the NSS. And we know already that incorporating the fragment into NSS would cause a lot of avoidable trouble (for instance, many namespaces could not use fragment at all). Of course this whole point is entirely theoretical. If IETF cannot live with the idea that URN and URN + fragment still identify the same thing and are in that sense the same URN, we can extend the syntax so that after NSS one can add fragment and / or query into the URN string itself. Then, but only then, URN and URN + fragment are different. Different in which way exactly should of course be discussed, and whatever we do with the chapter dealing with semantic equivalence in the URN syntax document. the text has to be drafted rather carefully so as to make it very clear to everyone what URNs identify. It is a bit alarming that even in this WG we tend to have diverse views on things - which may lead to dead ends that would have been avoidable. It is important that IETF does develop URN syntax which is fully aligned with RFC 3986. Since there are no generally accepted guidelines on how to use fragment or query, people have been inventive. For instance in the Clarin project, "@" is used to indicate fragment (or part, as they call it). So a Handle 11858/1234@test=a will be resolved to http://clarin.eu?test=a But no other application but the Clarin Handle server will be able to process these Clarin Handles; all other systems out there would be perplexed by it. One might think of few reasons why creating this kind of URIs can be risky. Juha > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRLOx/AAoJEOoGpJErxa2p9aMQAKoZUm0Uq0Sa0xQ23TsmKqhL > i7C4PKkYJ8dpjKWJ65SVFTKn1jCr+td2oR+qNMny7MqGm58GTcmmkYmTPlCx39I8 > UhpAXw3jL9HXScLpdUCGtV3IPPuiMVT+FLHfqVdXm/sbew/ICe9KwDVmCYKEve0y > fMzlW3PdQPPjncBjTFdHsPpmAVS/gn7NZ4sX7hD8q2bMn3Cym+bSjRRK8L4k/it8 > h+xGPOXi6waOE4EfZJcL2Sme+4u5uN98aSE6lBxa1J1J9L8ZzNU7z1hhdrv+iztH > 1yT1QaS2jEj5uN7V8dhI6LkRf3yy883j8WKyBs4BvLYQG++C+hboQgyAuh/O7+O5 > LmHQtsLPQWjsNoawa2lceAs+MNcLVH3+PPkT6jJ3rxPDITYay/d/0Byr6SAPYs6Y > mfiWg5w+1A69KSEu+n9nJnpPyqoUZBjJ8YfiiwIr1F/Ft1NjFD2+vpTKGFsj06Ry > 0xwZH5WMinlpMhXLnztKvWBgx/9d0RbLlxsYNvzw7+v1NM0dMmaAWfmr90g1Xiyq > h4t6RIaYRxkYsmEx3AEWDGw7jtV+rgUtI3Jf1qn8iS6R/BmIWYpyiKvuwVRu1Lke > apGp7nFROuv7g2AntWPi7Ur8av6TfZijllcmKSwhxAVHeKj5JU+BHz+BeZvlN5js > UbAwq+ORA7UFM8MtGlnR > =EMFB > -----END PGP SIGNATURE----- From julian.reschke@gmx.de Tue Feb 26 11:53:38 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E19121F8727 for ; Tue, 26 Feb 2013 11:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.923 X-Spam-Level: X-Spam-Status: No, score=-105.923 tagged_above=-999 required=5 tests=[AWL=-3.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm+E4Nx6785U for ; Tue, 26 Feb 2013 11:53:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id C67F421F871D for ; Tue, 26 Feb 2013 11:53:23 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lbx7K-1UZtyB05Aa-00jGVH for ; Tue, 26 Feb 2013 20:53:23 +0100 Received: (qmail invoked by alias); 26 Feb 2013 19:53:22 -0000 Received: from p5DD97B44.dip.t-dialin.net (EHLO [192.168.1.102]) [93.217.123.68] by mail.gmx.net (mp012) with SMTP; 26 Feb 2013 20:53:22 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+H7vQ4uReHRgvD6nLr6TJP2rmaVPkVYMiW3S4a8i 8e/kwqcQOspYK4 Message-ID: <512D12B0.4050304@gmx.de> Date: Tue, 26 Feb 2013 20:53:20 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: jehakala@mappi.helsinki.fi References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> <512716C6.4090308@helsinki.fi> <512CDC48.9070703@gmx.de> <512CEC80.8020702@stpeter.im> <20130226212621.Horde.y3L08bLxxMiNJYU7FS9abA1.jehakala@webmail.helsinki.fi> In-Reply-To: <20130226212621.Horde.y3L08bLxxMiNJYU7FS9abA1.jehakala@webmail.helsinki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:53:38 -0000 On 2013-02-26 20:26, jehakala@mappi.helsinki.fi wrote: > Hello, > > Quoting Peter Saint-Andre : > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 2/26/13 9:01 AM, Julian Reschke wrote: >>> On 2013-02-22 07:57, Juha Hakala wrote: > >>>> Despite the addition of fragment and query the URN itself remains >>>> the same, even though the HTTP URI changes. ... >>> >>> Well, it's a different string, thus a different URN. >> >> Correct. As Martin suggested, one might refer to the >> organizationally-assigned or algorithmically-determined URN as an >> "absolute URN", but that doesn't change the fact that absolute+query >> or absolute+fragment is still a different URN. > > It is a different string, thus a different URI, as dictated by RFC 3986. > > But it is the same URN, since fragment is not part of the Namespace > specific string, as specified by the Alfred Hoenes' version of the URN > syntax, or any other syntax specification which approves the current > idea that fragment is not part of the NSS. And we know already that > incorporating the fragment into NSS would cause a lot of avoidable > trouble (for instance, many namespaces could not use fragment at all). I was actually talking about the query part; sorry for the confusion. It's up to the URN or NIS syntax to describe what the query part means, and how it applies to different namespaces. But in *general*, adding a query part to a URI changes the resource being identified. Best regards, Julian From juha.hakala@helsinki.fi Tue Feb 26 23:03:26 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E908B21F853D for ; Tue, 26 Feb 2013 23:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKpa6oM--cSY for ; Tue, 26 Feb 2013 23:03:25 -0800 (PST) Received: from smtp-rs2.it.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) by ietfa.amsl.com (Postfix) with ESMTP id 940C821F8534 for ; Tue, 26 Feb 2013 23:03:23 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id r1R73KWT025572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Feb 2013 09:03:20 +0200 Message-ID: <512DAFB8.7070704@helsinki.fi> Date: Wed, 27 Feb 2013 09:03:20 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Julian Reschke References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> <512716C6.4090308@helsinki.fi> <512CDC48.9070703@gmx.de> <512CEC80.8020702@stpeter.im> <20130226212621.Horde.y3L08bLxxMiNJYU7FS9abA1.jehakala@webmail.helsinki.fi> <512D12B0.4050304@gmx.de> In-Reply-To: <512D12B0.4050304@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: jehakala@mappi.helsinki.fi, "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 07:03:27 -0000 Hello, On 26.2.2013 21:53, Julian Reschke wrote: > >> It is a different string, thus a different URI, as dictated by RFC 3986. >> >> But it is the same URN, since fragment is not part of the Namespace >> specific string, as specified by the Alfred Hoenes' version of the URN >> syntax, or any other syntax specification which approves the current >> idea that fragment is not part of the NSS. And we know already that >> incorporating the fragment into NSS would cause a lot of avoidable >> trouble (for instance, many namespaces could not use fragment at all). > > I was actually talking about the query part; sorry for the confusion. > > It's up to the URN or NIS syntax to describe what the query part > means, and how it applies to different namespaces. But in *general*, > adding a query part to a URI changes the resource being identified. You have to be careful with the word "identify" in the URN context. From the URN point of view, the resource identified does not change when a query is added, if queries are used to facilitate the services specified in RFC 2483. All these services are related to one and only one identified resource. A user can request for instance the resource itself, metadata about it, its current URL or URLs, and so forth. In practice, HTTP URIs (locations) the URN resolves to and the things that are being retrieved change, but the resource identified by the (location independent) URN does not. I suppose it will not be possible to prevent URN implementers from constructing systems in which query is used to enable identification of multiple resources using the "absolute" URN as the starting point. But if the URN syntax says that the query is not part of the namespace specific string, then such an URN implementation is violating the syntax specification. And IANA should not approve namespace registration requests which use query in such non-standard way. If query were made part of the namespace specific string, we might end up discussing whether a resource can be identified both by its absolute URN and the absolute URN + query indicating URI to resource service. Or, if a metadata record describing a resource can be identified by the URN of the resource + query indicating URI to URC service. It might be a good idea to avoid such a debate. All the best, Juha > > > Best regards, Julian -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From L.Svensson@dnb.de Wed Feb 27 00:37:51 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEE621F85EE for ; Wed, 27 Feb 2013 00:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw9ZaVeqvJco for ; Wed, 27 Feb 2013 00:37:50 -0800 (PST) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2387721F85FD for ; Wed, 27 Feb 2013 00:37:49 -0800 (PST) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 079B6C1E34; Wed, 27 Feb 2013 09:36:25 +0100 (CET) From: "Svensson, Lars" To: Juha Hakala , Julian Reschke Thread-Topic: [urn] URN fragments Thread-Index: AQHOFEQvb/Brr29raE+r4pMD+ef6CZiMdQSAgAAHigCAALsyAIAAJrvg Date: Wed, 27 Feb 2013 08:37:46 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA403A537@dnbf-ex1.AD.DDB.DE> References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> <512716C6.4090308@helsinki.fi> <512CDC48.9070703@gmx.de> <512CEC80.8020702@stpeter.im> <20130226212621.Horde.y3L08bLxxMiNJYU7FS9abA1.jehakala@webmail.helsinki.fi> <512D12B0.4050304@gmx.de> <512DAFB8.7070704@helsinki.fi> In-Reply-To: <512DAFB8.7070704@helsinki.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] URN fragments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 08:37:51 -0000 Juha, Julian, all, On February 27, 2013, 08:03, Juha wrote=20 > On 26.2.2013 21:53, Julian Reschke wrote: > > > >> It is a different string, thus a different URI, as dictated by RFC > 3986. > >> > >> But it is the same URN, since fragment is not part of the Namespace > >> specific string, as specified by the Alfred Hoenes' version of the > >> URN syntax, or any other syntax specification which approves the > >> current idea that fragment is not part of the NSS. And we know > >> already that incorporating the fragment into NSS would cause a lot > of > >> avoidable trouble (for instance, many namespaces could not use > fragment at all). > > > > I was actually talking about the query part; sorry for the confusion. > > > > It's up to the URN or NIS syntax to describe what the query part > > means, and how it applies to different namespaces. But in *general*, > > adding a query part to a URI changes the resource being identified. >=20 > You have to be careful with the word "identify" in the URN context. >=20 > From the URN point of view, the resource identified does not change > when a query is added, if queries are used to facilitate the services > specified in RFC 2483. All these services are related to one and only > one identified resource. A user can request for instance the resource > itself, metadata about it, its current URL or URLs, and so forth. In > practice, HTTP URIs (locations) the URN resolves to and the things that > are being retrieved change, but the resource identified by the > (location > independent) URN does not. I think this depends on your urn namespace. In my opinion, we need to diffe= r between queries that "operate on the urn itself" (in lack of a better des= cription) and queries aimed at passing information to resolution services. = As to the question if the query is part of the urn or not, my reading of rf= c 3986 =A73.4 is that it _is_ part of the urn [[ The query component is indicated by the first question mark ("?") character= and terminated by a number sign ("#") character or by the end of the URI.]= ] If the query component ends at the end of the URI, it must be part of it. Regarding the difference between queries in the context of the urn itself a= nd in the context of resolution services, I made up a case to illustrate my= point (thereby deliberately moving away from urn:nbn and urn:isbn). In order to ensure that we can always identify integers in a location-indep= endent way, we have registered the urn namespace 'int'. The NSS is defined = as eight hexadecimal digits. Examples would be urn:int:0000000F ; urn:int:A= 0001234 . By doing this, we have unique names for those numbers and nothing= more. 1) Now we want to define other representations (decimal, octal, binary) of = those hex numbers, and we do that by adding query parts to the urn. Example= : urn:int:0000000F?base=3D10 would identify 15 (decimal). In this case addi= ng the query does not change the resource (the integer remains the same, th= e query merely changes its representation). In this case we have two differ= ent URIs identifying the same thing (the number 15 =3D 0x0F =3D 00001111 = =3D .) 2) We also want to be able to identify the next and the previous integer an= d we do that through the relations "next" and "previous". As an example: ur= n:int:0000000F?rel=3Dnext would identify the same as urn:int:00000010. In t= his case the query part turns urn:int:000000F into another resource identif= ying something else (the number 16 =3D 0x10 =3D 00010000 =3D . ). In the second case, the query part modifies the resource itself. You could = say that the query "belongs to the urn". In the first case, the query part modifies the representation of the resour= ce. This should (in my opinion) be handled by a resolution service. In this discussion we need to differ between queries in the context of the = urns themselves and queries in the context of resolution services. Those ar= e in my opinion not the same. I hope this helps. All the best, Lars ***Lesen. H=F6ren. Wissen. Deutsche Nationalbibliothek*** ***Reading. Listening. Understanding. German National Library*** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de