From moore@network-heretics.com Tue Sep 3 07:18:32 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 2B1E821E80B9 for ; Tue, 3 Sep 2013 07:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY0HbOZ8Oluk for ; Tue, 3 Sep 2013 07:18:27 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9482821E814E for ; Tue, 3 Sep 2013 07:18:27 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 17213206D4; Tue, 3 Sep 2013 10:18:26 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 03 Sep 2013 10:18:26 -0400 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=WwC05jvs7xQgWTU3xqL9my QjJFA=; b=OTYAB45jD/fJ9zTM/5kD1h+aOIYp11drcM+pVNHDj5iRDFRZBCcB4y rfER3pKODTFYeBE2Jn5NUyFCUdV259n7JelnWGLzsxdDifY9DSQSYB9cSkTZRium gG6wBvQxL7yknacQyj/xaLY2XXgUR8Mx3OF2hnjCd3fhukRMC9fso= X-Sasl-enc: WLOUt8ooBeUlqxYOcJD5dv8eqv1ieXjiKEb1qelactyW 1378217905 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2505868017A; Tue, 3 Sep 2013 10:18:25 -0400 (EDT) Message-ID: <5225EF9D.2000703@network-heretics.com> Date: Tue, 03 Sep 2013 10:18:05 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Juha Hakala References: <24637769D123E644A105A0AF0E1F92EFA4374E72@dnbf-ex1.AD.DDB.DE> <521031EF.8010504@network-heretics.com> <5210E8D2.3000200@network-heretics.com> <52110C52.8080507@network-heretics.com> <521DD6D5.3070504@helsinki.fi> In-Reply-To: <521DD6D5.3070504@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Allowing "/" in the NSS (was Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Tue, 03 Sep 2013 14:18:32 -0000 I recommend that "/" be reserved to communicate options to resolution services, so that "?" and "#" do not get overloaded for this purpose. Keith On 08/28/2013 06:54 AM, Juha Hakala wrote: > Hello, > > There are two persistent identifiers (Handle and DOI) which always > require "/" in the identifier string. > > Many identifier systems do in theory allow the use of slash, tilde or > ampersand. In practice, they seem to be seldom used. For instance, I > have never seen an NBN which would have contained anything else but > just ASCII characters. > > Nobody has required that it should be possible to use "~" and "&" > without percent encoding. The change to the RFC 2141 NSS charset was > done mainly to simplify the specification and because we saw no > problem in doing that. Now that a good argument against allowing their > use un-encoded has emerged, we can return to the original policy, and > require percent encoding of these characters. This should not be a > problem, since there does not seem to be a strong use case for > allowing them. > > If there were plans to register a URN namespace to Handle and DOI, we > should analyze the pros and cons of allowing "/". Since the Handle / > DOI community is not planning to rely on URN resolution we can, for > the time being, stick to the current policy as regards "/". > > All the best, > > Juha > > On 18.8.2013 21:02, Keith Moore wrote: >> On 08/18/2013 01:34 PM, John C Klensin wrote: >>> >>> --On Sunday, 18 August, 2013 11:31 -0400 Keith Moore >>> wrote: >>> >>>> ... >>>>> p.s. That doesn't stop me from agreeing that keeping "/" out >>>>> of NSSs is a good idea (and, indeed, from wondering whether >>>>> we are really sure that allowing "~" and "&" is necessary. >>>> I also wonder whether allowing tilde and ampersand are good >>>> ideas. To me that looks like an incompatible change that could >>>> potentially harm interoperability for existing URNs. >>> In general, relaxing a previous restriction has no serious ill >>> effects, at least if those restrictions were followed. >> >> The principle danger that I see is if there are existing systems that >> convert some other kind of identifiers to URNs, and they currently >> percent-encode tildes and ampersands, either for the purpose of >> coining new URNs or resolving existing identifiers as URNs. If >> those converters change their behavior to stop encoding tildes and >> ampersands, lookups of old URNs that were converted with an old >> converter will fail. If some of those converters change their >> behavior and others don't, behavior will be inconsistent between >> different implementations. >> >> So I think we need strong justification to remove existing >> restrictions on characters permitted in URN syntax. And in light of >> the scenarios described above, a desire to be able to convert >> existing identifiers to URNs without percent-encoding some of the >> characters in those identifiers might actually be a good reason to >> not change those restrictions. >> >> Keith >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From moore@network-heretics.com Tue Sep 3 07:26:55 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 3721021E815E for ; Tue, 3 Sep 2013 07:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssVrWuY-p0ZW for ; Tue, 3 Sep 2013 07:26:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6A021E8160 for ; Tue, 3 Sep 2013 07:26:50 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1F0FA226EE; Tue, 3 Sep 2013 10:26:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 03 Sep 2013 10:26:48 -0400 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=vaw2V3cWAfYg6Wuqt3dS90 htvCg=; b=JXNHzsgsm7Jtu6XygUipyRKfq46rMvLhLaANh5puClNzhcr/5ipHkY cpH4WZ1+rEQmHqBf7Ugy6NIslH6ZmMvt0rRTd81FOIYXDUWVBExFcVFI7VpUWj7N 2deUwq+o4I97YFyA4XhetcDqYqSwPhApgl9HblNtIvGRr9m6J6vTI= X-Sasl-enc: yc1Dkhyo6ZlWXJZCj0XMN6dH1shAtHpoRswzCEDm7udx 1378218406 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 16CC7C00E94; Tue, 3 Sep 2013 10:26:45 -0400 (EDT) Message-ID: <5225F192.3030109@network-heretics.com> Date: Tue, 03 Sep 2013 10:26:26 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Juha Hakala References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> In-Reply-To: <521DE0E9.6070001@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Tue, 03 Sep 2013 14:26:55 -0000 On 08/28/2013 07:37 AM, Juha Hakala wrote: > Hello, > > > On 20.8.2013 1:52, Keith Moore wrote: >> On 08/19/2013 05:54 PM, Peter Saint-Andre wrote: >>>>> As I understand it, so far the only use case envisioned for query >>>>> components (and perhaps also fragment identifier components) is >>>>> exactly >>>>> that of passing additional information to a URN resolution >>>>> service. So I >>>>> agree with John that people who really want this feature will ignore >>>>> whatever the spec might say. > Yes, it is my intention to specify in rfc2483bis a query syntax for > sending resolution service related requests to URN resolvers. If we do > not provide such a syntax, there will be a lot of mutually > incompatible local solutions for how to use query in this manner, even > if rfc2141bis tries to forbid or disencourage the use of query. It is essential that any syntax used to pass queries to resolvers be different than the syntax used to pass queries to the resources named by URNs. "?" is already in wide use to pass queries to resources named by URLs, and it would be very confusing if "?" had a different purpose for use with URNs. (e.g. passing queries to resolution services) > > Alfred Hoenes and myself have started the query specification in > rfc2141bis-urn-03. Our idea was to use the service names from RFC > 2483, and to complement them with service related parameters; for > instance, having just I2C (URI to URC) is not sufficient in the > situation where there are multiple metadata formats. >>> Correction: they will ignore any hard prohibition on using query >>> components and fragment identifier components in that way. > Yes, it would be very difficult to convince the URN users why they > should not use query, especially when other persistent identifiers are > using them already. It will be very difficult to convince users to use "?" differently for URNs than they are accustomed to using it for HTTP URLs. > >> The most that the standard can do is explain to people why this is a bad >> idea. But that's easy to do. If people want to build resolution >> servers that break URNs, I don't pretend that we can stop them. > The most that the standard can do is to help people in using query in > a useful manner. I don't think that it is our task to tell people why > they should not do something that is allowed elsewhere. "?" is used elsewhere to pass queries to named resources. Why should people not use "?" to pass queries to resources named URNs? There is an apparent conflict between different uses of "?". The HTTP usage of "?" is very common and there is a lot of mindshare behind it. > And we should not write standards in such a way that the users cannot > utilize features such as query which are likely to be useful for them. > > As an aside, this is not the first time there is a need to use query > to pass service requests. Information retrieval systems use SRU > protocol (http://www.loc.gov/standards/sru/) for sending queries to > remote systems like this: > > http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaur&maximumRecords=1&recordSchema=dc > > > In comparison, the planned use of query in the URN context should be > relatively simple. But the URN resolvers may need to get smarter. For > instance, if I want a resource description instead of the resource > itself, the URN resolver may need to extract the required data > elements from the URN query into an SRU searchRetrieve URL (if the > target system prefers SRU to URN queries). I don't think that makes any sense at all, as it either (a) prevents users from passing queries to end resources, or (b) forces both end resources and resolvers to know which queries apply to them. There seems to be a serious disconnect here. Keith From moore@network-heretics.com Tue Sep 3 07:30: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 9637021E8152 for ; Tue, 3 Sep 2013 07:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3oivvrUxYOV for ; Tue, 3 Sep 2013 07:30:11 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 75B9B21E80B9 for ; Tue, 3 Sep 2013 07:30:11 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8416921E7D; Tue, 3 Sep 2013 10:30:10 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 03 Sep 2013 10:30:10 -0400 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=7bqr0g0PaNjaiMrN3ENUf6 WAUkY=; b=T0NJklzF6oabtAV5PELNv3g29ULJ9eKfF8xQ2m06G9fL3+uDaCZdTI zKnFhgSSu0Tlq+bDADzDoyXmVc6GmQNvlmXWqYDYV6s+dX2ddWAGDxLNl8jJeeCh 3U4t4Xmyt9w6YX1cPBvP6qT53ZrgweuI7W+8RJ2OPvfd7pyCBooa4= X-Sasl-enc: GuJznWozRMfHL5Mu5d5SNzbT3OAUFhtH8Y8C5RR+mAOs 1378218609 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 705BCC00E80; Tue, 3 Sep 2013 10:30:09 -0400 (EDT) Message-ID: <5225F25D.9090306@network-heretics.com> Date: Tue, 03 Sep 2013 10:29:49 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Svensson, Lars" References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Tue, 03 Sep 2013 14:30:17 -0000 On 08/28/2013 10:12 AM, Svensson, Lars wrote: > Yes, and the question (to me) still is if the query attached to the urn is to be applied to the resource identified by that urn or if it is supposed to pass information on to a (http-based) resolution service. This is precisely the question, and it seems to me that the answer that makes more sense is that the "?" syntax is only used to pass information to the resource identified to the URN. Any queries passed to the resolution service should use a different syntax. Keith From L.Svensson@dnb.de Tue Sep 3 08:49:10 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 ACDAC21E8177 for ; Tue, 3 Sep 2013 08:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrGqas9qHWwy for ; Tue, 3 Sep 2013 08:49:05 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8C84B21E8174 for ; Tue, 3 Sep 2013 08:49:05 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 010477EE71; Tue, 3 Sep 2013 17:45:17 +0200 (CEST) From: "Svensson, Lars" To: Keith Moore Thread-Topic: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt Thread-Index: AQHOo+MDVOnPQJ1D10yTQtKcbtrQ+ZmqpXAwgAlVWYCAADZswA== Date: Tue, 3 Sep 2013 15:49:02 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA437A43A@dnbf-ex1.AD.DDB.DE> References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> <5225F25D.9090306@network-heretics.com> In-Reply-To: <5225F25D.9090306@network-heretics.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.26] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Tue, 03 Sep 2013 15:49:10 -0000 On 3. September 2013 16:30 Keith Moore wrote > On 08/28/2013 10:12 AM, Svensson, Lars wrote: > > Yes, and the question (to me) still is if the query attached to the urn= is to be > > applied to the resource identified by that urn or if it is supposed to = pass > > information on to a (http-based) resolution service. > This is precisely the question, and it seems to me that the answer that m= akes > more sense is that the "?" syntax is only used to pass information to the > resource identified to the URN. >=20 > Any queries passed to the resolution service should use a different synta= x. Is this what you want to use the "/" for? If so, we need to be very sure th= at there are no existing urns with that character in them. Lars From moore@network-heretics.com Tue Sep 3 09:03:52 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 81DBE21F9C55 for ; Tue, 3 Sep 2013 09:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ixz4ZGVgc4of for ; Tue, 3 Sep 2013 09:03:47 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 69AD621F9C05 for ; Tue, 3 Sep 2013 09:03:47 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 02D3C21284; Tue, 3 Sep 2013 12:03:44 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 03 Sep 2013 12:03:46 -0400 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=Qe09up8fvTXJXAtAJl+Wiw 0Xy4Y=; b=oYSOpunLnYu8XzVfEKqOD5dsINo+KtMa9UBXrclkxzIrkmp9xbi4L/ chXYR6FeHLZZ7YAHudPIxvCuo8ttdh9MOMdJiWqz1DR9P6lp/4xyosuypOCPfaOS HQY3ygvYsq8X9ZljLPNxF7zcZh6LrsH1EjDP5Qv621Lw+32ZNXdms= X-Sasl-enc: U/zy776pjcQ1BCKZDS+tgz2RmxBSOhwHPXGvUS1kR63K 1378224224 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BECFF6804F6; Tue, 3 Sep 2013 12:03:43 -0400 (EDT) Message-ID: <5226084B.3030908@network-heretics.com> Date: Tue, 03 Sep 2013 12:03:23 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Svensson, Lars" References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> <5225F25D.9090306@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A43A@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA437A43A@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Tue, 03 Sep 2013 16:03:52 -0000 On 09/03/2013 11:49 AM, Svensson, Lars wrote: > On 3. September 2013 16:30 Keith Moore wrote >> On 08/28/2013 10:12 AM, Svensson, Lars wrote: >>> Yes, and the question (to me) still is if the query attached to the urn is to be >>> applied to the resource identified by that urn or if it is supposed to pass >>> information on to a (http-based) resolution service. >> This is precisely the question, and it seems to me that the answer that makes >> more sense is that the "?" syntax is only used to pass information to the >> resource identified to the URN. >> >> Any queries passed to the resolution service should use a different syntax. > Is this what you want to use the "/" for? If so, we need to be very sure that there are no existing urns with that character in them. "/" is about the only character left that we could use for that purpose. But since "/" was reserved in 2141, no existing URNs should be using it. Keith From L.Svensson@dnb.de Tue Sep 3 09:10:05 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 3077421E8177 for ; Tue, 3 Sep 2013 09:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWybBGwDvzAQ for ; Tue, 3 Sep 2013 09:10:00 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id D2B1321F9D31 for ; Tue, 3 Sep 2013 09:09:59 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 165BD7EDF5; Tue, 3 Sep 2013 18:06:07 +0200 (CEST) From: "Svensson, Lars" To: Keith Moore Thread-Topic: AW: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt Thread-Index: AQHOqL8zJ5q1M29DBkq4pmUvCSWNopm0LRHA Date: Tue, 3 Sep 2013 16:09:52 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA437A4AA@dnbf-ex1.AD.DDB.DE> References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> <5225F25D.9090306@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A43A@dnbf-ex1.AD.DDB.DE> <5226084B.3030908@network-heretics.com> In-Reply-To: <5226084B.3030908@network-heretics.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.26] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Tue, 03 Sep 2013 16:10:05 -0000 On 3. September 2013 18:03 Keith Moore wrote: > An: Svensson, Lars > Cc: Juha Hakala; urn@ietf.org > Betreff: Re: AW: [urn] Working Group Last Call of draft-ietf-urnbis-rfc21= 41bis- > urn-06.txt >=20 > On 09/03/2013 11:49 AM, Svensson, Lars wrote: > > On 3. September 2013 16:30 Keith Moore wrote > >> On 08/28/2013 10:12 AM, Svensson, Lars wrote: > >>> Yes, and the question (to me) still is if the query attached to the > >>> urn is to be applied to the resource identified by that urn or if it > >>> is supposed to pass information on to a (http-based) resolution servi= ce. > >> This is precisely the question, and it seems to me that the answer > >> that makes more sense is that the "?" syntax is only used to pass > >> information to the resource identified to the URN. > >> > >> Any queries passed to the resolution service should use a different > syntax. > > Is this what you want to use the "/" for? If so, we need to be very sur= e that > there are no existing urns with that character in them. >=20 > "/" is about the only character left that we could use for that purpose. >=20 > But since "/" was reserved in 2141, no existing URNs should be using it. The operative word being "should". RFC 2141 =A7 2.3.2 explicitly says "Name= space developers SHOULD NOT use these characters in unencoded form, but rat= her use the appropriate %-encoding for each character." It wasn't explicitl= y forbidden. Lars From moore@network-heretics.com Tue Sep 3 09:21: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 499B821E8189 for ; Tue, 3 Sep 2013 09:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G9CEyX5g0Gp for ; Tue, 3 Sep 2013 09:20:54 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id DA7BF21E81A2 for ; Tue, 3 Sep 2013 09:20:39 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id EDF2C21BF8; Tue, 3 Sep 2013 12:20:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 03 Sep 2013 12:20:38 -0400 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=ZKzAU7UslzAX9hqLqZ9bno R2YFk=; b=LbSQ/SA7CqfcmFMwCxDcoJzCYC4wWw1ctxyVK4mPhhWHnKv+LgkBSG vB0IoVD/mFPIVQQApTpR8zpesBOC8fU3FsOehz7qzPpJWklg9kiop45QG4NUJyEc BL3YZJfu7Dojp4CZmAeMO2TlZL6nbC+9UN0EeZbea+yIwSmvEEOVY= X-Sasl-enc: EBsSy8SAxBPqZZtEfCigiOf9k4Blr+Xvn4ZgdZ1O345i 1378225238 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 12D0DC00E80; Tue, 3 Sep 2013 12:20:37 -0400 (EDT) Message-ID: <52260C42.50206@network-heretics.com> Date: Tue, 03 Sep 2013 12:20:18 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Svensson, Lars" References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> <5225F25D.9090306@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A43A@dnbf-ex1.AD.DDB.DE> <5226084B.3030908@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A4AA@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA437A4AA@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Tue, 03 Sep 2013 16:21:06 -0000 >>> Is this [queries passed to a resolution service] what you want to use the "/" for? If so, we need to be very sure that >> there are no existing urns with that character in them. >> >> "/" is about the only character left that we could use for that purpose. >> >> But since "/" was reserved in 2141, no existing URNs should be using it. > The operative word being "should". RFC 2141 § 2.3.2 explicitly says "Namespace developers SHOULD NOT use these characters in unencoded form, but rather use the appropriate %-encoding for each character." It wasn't explicitly forbidden. Ok, valid point. But I suspect it still works better than "?" Note that even if there are some URNs that use "/", it might be possible to define a "resolution service parameter" syntax that would make it possible for resolution services to reliably distinguish such parameters from "/"s in existing URNs. For instance, if parameters passed to resolution services had to be of the form /[A-Za-z][A-a-z0-9]*=[A-Za-z0-9]+ but none of the existing URNs used "=" after "/", the resolution service would know the difference. Keith p.s. is it necessary to poll each of the URN namespace operators to learn to what extent "/" is being used? Should that poll also ask about other reserved characters? From stpeter@stpeter.im Tue Sep 3 20:04: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 7B34221E80E3 for ; Tue, 3 Sep 2013 20:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk+RmEBV3U1O for ; Tue, 3 Sep 2013 20:04:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A88C921E8141 for ; Tue, 3 Sep 2013 20:04:11 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E387841517; Tue, 3 Sep 2013 21:08:12 -0600 (MDT) Message-ID: <5226A326.909@stpeter.im> Date: Tue, 03 Sep 2013 21:04:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John C Klensin References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 03:04:17 -0000 On 8/30/13 7:45 AM, John C Klensin wrote: > > > --On Friday, August 30, 2013 15:58 +0300 Juha Hakala > wrote: > >> If we have a valid case for using query to provide guidance to >> the browser or other user agent, or if we think that such >> cases may arise in the future, we may add a parameter into the >> query which indicates that the service request and parameters >> related to it (if any) should be met by the user agent and >> that the URN resolver may just ignore the query. >> >> For instance, something like >> >> URN:ISBN:978-952-60-5254-0?agent=user&search=someword >> >> would do, assuming that the user agent knows what to do with >> it. But my gut feeling is that there is a lot to do to define >> just the URN resolution services and their parameters. If we >> start listing also user agent resolution service >> functionality, we'll have plenty of additional stuff to deal >> with. An easy way to solve this is to reserve agent=user for >> user agent related services (default being agent=resolver) and >> leave the specification of these services to the future >> implementers. > > This seems to me to be a good idea. It preserves the ability to > expand things in the future in directions we can only vaguely > anticipate today (and that some of us find controversial at > best) without committing ourselves to those extensions in the > future or requiring that the details be sorted out now. > > Would it be appropriate to incorporate text into 2141bis and/or > 3406bis that explicitly reserves "agent" as a query keyword and > specifies "agent=resolver" as the default case? Personally I'd prefer to avoid reserving key-value pairs for the query component... Peter From stpeter@stpeter.im Tue Sep 3 20:16:57 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 6326021F9A17 for ; Tue, 3 Sep 2013 20:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKScv6ruepIe for ; Tue, 3 Sep 2013 20:16:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 377CC21F9611 for ; Tue, 3 Sep 2013 20:16:48 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 14EFB41517; Tue, 3 Sep 2013 21:20:51 -0600 (MDT) Message-ID: <5226A61D.2030506@stpeter.im> Date: Tue, 03 Sep 2013 21:16:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Keith Moore References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <5225F192.3030109@network-heretics.com> In-Reply-To: <5225F192.3030109@network-heretics.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 03:16:57 -0000 On 9/3/13 8:26 AM, Keith Moore wrote: > On 08/28/2013 07:37 AM, Juha Hakala wrote: >> Hello, >> >> >> On 20.8.2013 1:52, Keith Moore wrote: >>> On 08/19/2013 05:54 PM, Peter Saint-Andre wrote: >>>>>> As I understand it, so far the only use case envisioned for query >>>>>> components (and perhaps also fragment identifier components) is >>>>>> exactly >>>>>> that of passing additional information to a URN resolution >>>>>> service. So I >>>>>> agree with John that people who really want this feature will ignore >>>>>> whatever the spec might say. >> Yes, it is my intention to specify in rfc2483bis a query syntax for >> sending resolution service related requests to URN resolvers. If we do >> not provide such a syntax, there will be a lot of mutually >> incompatible local solutions for how to use query in this manner, even >> if rfc2141bis tries to forbid or disencourage the use of query. > > It is essential that any syntax used to pass queries to resolvers be > different than the syntax used to pass queries to the resources named by > URNs. "?" is already in wide use to pass queries to resources named by > URLs, and it would be very confusing if "?" had a different purpose for > use with URNs. (e.g. passing queries to resolution services) > >> >> Alfred Hoenes and myself have started the query specification in >> rfc2141bis-urn-03. Our idea was to use the service names from RFC >> 2483, and to complement them with service related parameters; for >> instance, having just I2C (URI to URC) is not sufficient in the >> situation where there are multiple metadata formats. >>>> Correction: they will ignore any hard prohibition on using query >>>> components and fragment identifier components in that way. >> Yes, it would be very difficult to convince the URN users why they >> should not use query, especially when other persistent identifiers are >> using them already. > > It will be very difficult to convince users to use "?" differently for > URNs than they are accustomed to using it for HTTP URLs. > >> >>> The most that the standard can do is explain to people why this is a bad >>> idea. But that's easy to do. If people want to build resolution >>> servers that break URNs, I don't pretend that we can stop them. >> The most that the standard can do is to help people in using query in >> a useful manner. I don't think that it is our task to tell people why >> they should not do something that is allowed elsewhere. > > "?" is used elsewhere to pass queries to named resources. Why should > people not use "?" to pass queries to resources named URNs? > > There is an apparent conflict between different uses of "?". The HTTP > usage of "?" is very common and there is a lot of mindshare behind it. > >> And we should not write standards in such a way that the users cannot >> utilize features such as query which are likely to be useful for them. >> >> As an aside, this is not the first time there is a need to use query >> to pass service requests. Information retrieval systems use SRU >> protocol (http://www.loc.gov/standards/sru/) for sending queries to >> remote systems like this: >> >> http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaur&maximumRecords=1&recordSchema=dc >> >> >> In comparison, the planned use of query in the URN context should be >> relatively simple. But the URN resolvers may need to get smarter. For >> instance, if I want a resource description instead of the resource >> itself, the URN resolver may need to extract the required data >> elements from the URN query into an SRU searchRetrieve URL (if the >> target system prefers SRU to URN queries). > > I don't think that makes any sense at all, as it either (a) prevents > users from passing queries to end resources, Do we have any examples of passing a query to the sorts of resources that are identified by URNs? > or (b) forces both end > resources and resolvers to know which queries apply to them. Agreed, that strikes me as a dangerous path to go down. Peter -- Peter Saint-Andre https://stpeter.im/ From john-ietf@jck.com Tue Sep 3 20:22:18 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 4AC3B21F9A19 for ; Tue, 3 Sep 2013 20:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU-GUULOMvaQ for ; Tue, 3 Sep 2013 20:22:02 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB4621F9675 for ; Tue, 3 Sep 2013 20:22:02 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VH3fI-0008lS-0O; Tue, 03 Sep 2013 23:21:56 -0400 Date: Tue, 03 Sep 2013 23:21:50 -0400 From: John C Klensin To: Peter Saint-Andre Message-ID: <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> In-Reply-To: <5226A326.909@stpeter.im> References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 03:22:18 -0000 --On Tuesday, September 03, 2013 21:04 -0600 Peter Saint-Andre wrote: >> Would it be appropriate to incorporate text into 2141bis >> and/or 3406bis that explicitly reserves "agent" as a query >> keyword and specifies "agent=resolver" as the default case? > > Personally I'd prefer to avoid reserving key-value pairs for > the query component... Personally, I would too. Personally, I'd prefer that URIs were better defined and that some of the underlying issues identified in Juha's comments were a part of the basic structure so that tricks with key-value pairs were unnecessary. I would also like all URN types to be registered and for all of their designers, registries and assigners of identifying strings, and resolver system operators to have the same understanding of "persistence" and "permanence". I'd also like a pony :-) Since I'm unlikely to get any of the things on that list, the idea of a single reserved key-value pair seemed like a reasonable suggestion. john From moore@network-heretics.com Tue Sep 3 20:30:29 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 2274411E815F for ; Tue, 3 Sep 2013 20:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDHJMntXhDoY for ; Tue, 3 Sep 2013 20:30:24 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0587611E80D1 for ; Tue, 3 Sep 2013 20:30:23 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B872D222F5; Tue, 3 Sep 2013 23:30:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 03 Sep 2013 23:30:22 -0400 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=KYfJXKb+bsR7UronfXSCNj nw0Gg=; b=l05cPv/lulfBefpjpcgZVoKhEdeZdRDvdzHCVdQ+FE9IugsfBWB3aM 4tmOvUchlA77j4k05k6hX0z84QL2VsIHxG3qlnNGnCQCd/fdzW7vHDVOyq3YyFOD FcNguKzwGCUWr/nFRFYNAQmNuD16rGjencECFNU/NVCUPld6Tdfos= X-Sasl-enc: TCS9Ouo8couW+XeUKmucZozBXvevGO2pdv0OOH4bigXT 1378265421 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 630CB6800D6; Tue, 3 Sep 2013 23:30:21 -0400 (EDT) Message-ID: <5226A938.1070909@network-heretics.com> Date: Tue, 03 Sep 2013 23:30:00 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Saint-Andre References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <5225F192.3030109@network-heretics.com> <5226A61D.2030506@stpeter.im> In-Reply-To: <5226A61D.2030506@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 03:30:29 -0000 On 09/03/2013 11:16 PM, Peter Saint-Andre wrote: >>> In comparison, the planned use of query in the URN context should be >>> >> relatively simple. But the URN resolvers may need to get smarter. For >>> >> instance, if I want a resource description instead of the resource >>> >> itself, the URN resolver may need to extract the required data >>> >> elements from the URN query into an SRU searchRetrieve URL (if the >>> >> target system prefers SRU to URN queries). >> > >> > I don't think that makes any sense at all, as it either (a) prevents >> > users from passing queries to end resources, > Do we have any examples of passing a query to the sorts of resources > that are identified by URNs? What are "the sorts of resources that are identified by URNs"? I thought URNs were supposed to be usable with anything, including (but certainly not limited to) resources that can be named (less persistently) with ordinary URLs and are accessible via HTTP or other protocols that support queries. Keith From L.Svensson@dnb.de Wed Sep 4 07:24: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 45D0521E80B7 for ; Wed, 4 Sep 2013 07:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAWcPJNuvjpO for ; Wed, 4 Sep 2013 07:23:55 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF1421F9DF3 for ; Wed, 4 Sep 2013 07:23:53 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id F3D477EEBB; Wed, 4 Sep 2013 16:20:01 +0200 (CEST) From: "Svensson, Lars" To: Keith Moore Thread-Topic: AW: AW: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt Thread-Index: AQHOqL8zJ5q1M29DBkq4pmUvCSWNopm0LRHA///i3gCAAZIfMA== Date: Wed, 4 Sep 2013 14:23:48 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA437B9E1@dnbf-ex1.AD.DDB.DE> References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> <5225F25D.9090306@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A43A@dnbf-ex1.AD.DDB.DE> <5226084B.3030908@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A4AA@dnbf-ex1.AD.DDB.DE> <52260C42.50206@network-heretics.com> In-Reply-To: <52260C42.50206@network-heretics.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.35] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 14:24:00 -0000 On 3. September 2013 18:20 Keith Moore wrote =20 > p.s. is it necessary to poll each of the URN namespace operators to > learn to what extent "/" is being used? Should that poll also ask > about other reserved characters? That might be a good idea, both for "/" and the other reserved characters. As an aside, I am slightly concerned with the silence from urn implementers= from outside of the library domain. I fear that we might end up with a sol= ution that could work well for one _some_ namespaces (nbn, isbn, issn, etc.= ) and not work at all for others. But we cannot force them. /Lars From michael@refactored-networks.com Wed Sep 4 07:34:53 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 054EC21E80C9 for ; Wed, 4 Sep 2013 07:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRIC0NhCu6JM for ; Wed, 4 Sep 2013 07:34:48 -0700 (PDT) Received: from smtp-out-2.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 67AE721E80BE for ; Wed, 4 Sep 2013 07:34:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D45913900B8; Wed, 4 Sep 2013 09:34:45 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojzprih1B_9p; Wed, 4 Sep 2013 09:34:45 -0500 (CDT) Received: from smtp-out-2.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B39AA3900B4; Wed, 4 Sep 2013 09:34:45 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9F8503900BF; Wed, 4 Sep 2013 09:34:45 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MDEaBrbcbJMo; Wed, 4 Sep 2013 09:34:45 -0500 (CDT) Received: from [192.168.0.103] (50-199-114-66-static.hfc.comcastbusiness.net [50.199.114.66]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 3557D3900B4; Wed, 4 Sep 2013 09:34:45 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Mealling In-Reply-To: Date: Wed, 4 Sep 2013 10:34:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <884F357A-5AB2-4625-B513-62BDD517C399@refactored-networks.com> References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> <5225F25D.9090306@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A43A@dnbf-ex1.AD.DDB.DE> <5226084B.3030908@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A4AA@dnbf-ex1.AD.DDB.DE> <52260C42.50206@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437B9E1@dnbf-ex1.AD.DDB.DE> To: "Svensson, Lars" X-Mailer: Apple Mail (2.1508) Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 14:34:53 -0000 I helped write or consulted on several of the existed URN registrations = and by and large the other communities use URNs as we all originally = expected: opaque strings to the outside world and meaning only within = their systems. I would say almost half had no intention of trying to use = things like query strings or fragment ids. Since they were being used in = non-browser, non-HTTP oriented systems those concepts were alien and = probably incompatible. Especially the ones related to hierarchy. I think its instructive for people involved in these discussions to go = look at some of the existing registrations and see how and why they're = being used. MOST of the registrations are not library related and even = less are meant to be used in browsers by humans: http://www.ietf.org/assignments/urn-namespaces/urn-namespaces.txt -MM Michael Mealling Co-Founder Pipefish.com +1-678-640-6884 @mmealling Schedule a meeting: http://meetme.so/michaelmealling On Sep 4, 2013, at 10:23 AM, "Svensson, Lars" wrote: > On 3. September 2013 18:20 Keith Moore wrote >=20 >> p.s. is it necessary to poll each of the URN namespace operators to >> learn to what extent "/" is being used? Should that poll also ask >> about other reserved characters? >=20 > That might be a good idea, both for "/" and the other reserved = characters. >=20 > As an aside, I am slightly concerned with the silence from urn = implementers from outside of the library domain. I fear that we might = end up with a solution that could work well for one _some_ namespaces = (nbn, isbn, issn, etc.) and not work at all for others. But we cannot = force them. >=20 > /Lars > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From stpeter@stpeter.im Wed Sep 4 07:39:43 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 7C7C821F9E02 for ; Wed, 4 Sep 2013 07:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqwNZJIgvGza for ; Wed, 4 Sep 2013 07:39:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9950821E80B7 for ; Wed, 4 Sep 2013 07:39:37 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 81FA4415E0; Wed, 4 Sep 2013 08:43:40 -0600 (MDT) Message-ID: <52274624.2050206@stpeter.im> Date: Wed, 04 Sep 2013 08:39:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Mealling References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> <5225F25D.9090306@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A43A@dnbf-ex1.AD.DDB.DE> <5226084B.3030908@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A4AA@dnbf-ex1.AD.DDB.DE> <52260C42.50206@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437B9E1@dnbf-ex1.AD.DDB.DE> <884F357A-5AB2-4625-B513-62BDD517C399@refactored-networks.com> In-Reply-To: <884F357A-5AB2-4625-B513-62BDD517C399@refactored-networks.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 14:39:43 -0000 On 9/4/13 8:34 AM, Michael Mealling wrote: > I helped write or consulted on several of the existed URN > registrations and by and large the other communities use URNs as we > all originally expected: opaque strings to the outside world and > meaning only within their systems. I would say almost half had no > intention of trying to use things like query strings or fragment ids. > Since they were being used in non-browser, non-HTTP oriented systems > those concepts were alien and probably incompatible. Especially the > ones related to hierarchy. > > I think its instructive for people involved in these discussions to > go look at some of the existing registrations and see how and why > they're being used. MOST of the registrations are not library related > and even less are meant to be used in browsers by humans: > > http://www.ietf.org/assignments/urn-namespaces/urn-namespaces.txt Agreed. Many or most of the namespace operators I shepherded through the NID registration process as an AD were issuing XML namespaces. In terms of numbers of NIDs, use by libraries, publishers, and the like are in the minority. However, I think the bibliographic and museum communities have issued far more URNs than all the others combined. Peter -- Peter Saint-Andre https://stpeter.im/ From moore@network-heretics.com Wed Sep 4 07:45:52 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 B109711E812E for ; Wed, 4 Sep 2013 07:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o39n-soWOag for ; Wed, 4 Sep 2013 07:45:44 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 30BC611E80ED for ; Wed, 4 Sep 2013 07:45:44 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BE39D2160C; Wed, 4 Sep 2013 10:45:35 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 04 Sep 2013 10:45:35 -0400 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=QZKDd7dnIDWLT47cYksAlV D/7n4=; b=pCJhdtr1ehCnwmHKX7YPvuDKit+EO+oXtrdgo0ivUHxc2qixthDCel qp0uLozeGYJ/1cozNStPXu64Xzz7K2mSPhbiz37L6jf7/MqStWYqygo+WCnbeDkR bhBPADlEtuWqF4r+WbEkZ2l6KhBH2WjVN4Rzey85zX5rAvi2jL2z0= X-Sasl-enc: 5bsObqIMEcu6egMxEY3xdeb5QkFSeYU8gA11lopX9A/9 1378305935 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D3EA96800BF; Wed, 4 Sep 2013 10:45:34 -0400 (EDT) Message-ID: <52274777.9070901@network-heretics.com> Date: Wed, 04 Sep 2013 10:45:11 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: John C Klensin References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> In-Reply-To: <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 14:45:53 -0000 On 09/03/2013 11:21 PM, John C Klensin wrote: > > --On Tuesday, September 03, 2013 21:04 -0600 Peter Saint-Andre > wrote: > >>> Would it be appropriate to incorporate text into 2141bis >>> and/or 3406bis that explicitly reserves "agent" as a query >>> keyword and specifies "agent=resolver" as the default case? >> Personally I'd prefer to avoid reserving key-value pairs for >> the query component... > Personally, I would too. Personally, I'd prefer that URIs were > better defined and that some of the underlying issues identified > in Juha's comments were a part of the basic structure so that > tricks with key-value pairs were unnecessary. I would also like > all URN types to be registered and for all of their designers, > registries and assigners of identifying strings, and resolver > system operators to have the same understanding of "persistence" > and "permanence". I'd also like a pony :-) > > Since I'm unlikely to get any of the things on that list, the > idea of a single reserved key-value pair seemed like a > reasonable suggestion. I think it would be really odd to define a syntax such that either all of the query components were passed to the resolution service, or all of the query components were passed to the resource. More generally, I am struggling to think of any situation where overloading of the same protocol element for use for different purposes by multiple layers has ever been found to be a good idea in the long term. Even the use of IP addresses (from the network layer) to form part of the connection identifier in TCP (the transport layer) is consistently criticized today as being poor design. Why would use of the same query syntax for both resolution services and resources be any better? Keith From moore@network-heretics.com Wed Sep 4 07:51:01 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 B30D911E81D5 for ; Wed, 4 Sep 2013 07:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhoEiu-7C9e5 for ; Wed, 4 Sep 2013 07:50:55 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7795411E81D2 for ; Wed, 4 Sep 2013 07:50:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 323DE216CE; Wed, 4 Sep 2013 10:50:54 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 04 Sep 2013 10:50:54 -0400 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=t+GOofX1//WjWEubs9qbT6 7dUGE=; b=UD3FpbvOASrMETXqYoL/IwNaFhIOF34KUaUfdkUV+ZouDr4yUT5WTT nq/5qETW3tfvY3GaqYvQaF7WJplIQUNvVoFcDLINiR1Cd9LXXoNeJMEyMxN/uU9c QeFlsC/kimapmo4hCrp+kZpWVfT3/quTHbyaBS+EjxWjrSRZ+m5co= X-Sasl-enc: q6ortbcWuZRuTEE685CcCTl8oyrCfBDTWQVQ/3oNKKRf 1378306253 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 4CA1CC00E81; Wed, 4 Sep 2013 10:50:53 -0400 (EDT) Message-ID: <522748B6.4050002@network-heretics.com> Date: Wed, 04 Sep 2013 10:50:30 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Mealling References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> <5225F25D.9090306@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A43A@dnbf-ex1.AD.DDB.DE> <5226084B.3030908@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A4AA@dnbf-ex1.AD.DDB.DE> <52260C42.50206@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437B9E1@dnbf-ex1.AD.DDB.DE> <884F357A-5AB2-4625-B513-62BDD517C399@refactored-networks.com> In-Reply-To: <884F357A-5AB2-4625-B513-62BDD517C399@refactored-networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 14:51:01 -0000 On 09/04/2013 10:34 AM, Michael Mealling wrote: > I helped write or consulted on several of the existed URN registrations and by and large the other communities use URNs as we all originally expected: opaque strings to the outside world and meaning only within their systems. I would say almost half had no intention of trying to use things like query strings or fragment ids. Since they were being used in non-browser, non-HTTP oriented systems those concepts were alien and probably incompatible. Especially the ones related to hierarchy. > > I think its instructive for people involved in these discussions to go look at some of the existing registrations and see how and why they're being used. MOST of the registrations are not library related and even less are meant to be used in browsers by humans: Ok, sure, but do we really think that the way that URNs are used now should dictate or constrain how URNs can be used in the future? I think URNs are still very early on the adoption curve and the usage that we're seeing now is probably not a good indicator of how they'll be used in the future - unless of course we impose restrictions that limit the applicability of URNs based on current experience. Keith From jehakala@mappi.helsinki.fi Wed Sep 4 09:26:20 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 7012121E80E4 for ; Wed, 4 Sep 2013 09:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yce0S0S28Ol7 for ; Wed, 4 Sep 2013 09:26:15 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 80B9421E80C9 for ; Wed, 4 Sep 2013 09:26:14 -0700 (PDT) Received: from localhost (webmail-5.mappi.helsinki.fi [128.214.20.189]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r84GQAKB032127; Wed, 4 Sep 2013 19:26:10 +0300 Received: from wifi-guest-gw.ist.utl.pt (wifi-guest-gw.ist.utl.pt [193.136.152.65]) by webmail.helsinki.fi (Horde Framework) with HTTP; Wed, 04 Sep 2013 19:26:10 +0300 Date: Wed, 04 Sep 2013 19:26:09 +0300 Message-ID: <20130904192609.Horde.mnBPcXTSrUFPWcoX9gwqew8.jehakala@webmail.helsinki.fi> From: jehakala@mappi.helsinki.fi To: Peter Saint-Andre References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA4378345@dnbf-ex1.AD.DDB.DE> <5225F25D.9090306@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A43A@dnbf-ex1.AD.DDB.DE> <5226084B.3030908@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437A4AA@dnbf-ex1.AD.DDB.DE> <52260C42.50206@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA437B9E1@dnbf-ex1.AD.DDB.DE> <884F357A-5AB2-4625-B513-62BDD517C399@refactored-networks.com> <52274624.2050206@stpeter.im> In-Reply-To: <52274624.2050206@stpeter.im> User-Agent: Internet Messaging Program (IMP) H5 (6.0.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 16:26:20 -0000 Hello, Quoting Peter Saint-Andre : > On 9/4/13 8:34 AM, Michael Mealling wrote: >> I helped write or consulted on several of the existed URN >> registrations and by and large the other communities use URNs as we >> all originally expected: opaque strings to the outside world and >> meaning only within their systems. I would say almost half had no >> intention of trying to use things like query strings or fragment ids. >> Since they were being used in non-browser, non-HTTP oriented systems >> those concepts were alien and probably incompatible. Especially the >> ones related to hierarchy. Those namespaces which have no use for fragment and query for the time being do not need to implement them. In the future they may find especially the latter relevant. IMO there is nothing library specific in either in fragment or query as such. Of course library, museum and archival communities may have some specific uses for query since our applications have features (and data model) which are not commonly shared. But other users and communities are free to specify their own resolution services and query syntaxes for requesting these services from the resolvers they maintain. >> >> I think its instructive for people involved in these discussions to >> go look at some of the existing registrations and see how and why >> they're being used. MOST of the registrations are not library related >> and even less are meant to be used in browsers by humans: >> >> http://www.ietf.org/assignments/urn-namespaces/urn-namespaces.txt Yes, it is important to make sure that the URN syntax and resolution service registration mechanism can be adapted to the needs of different communities. > > Agreed. Many or most of the namespace operators I shepherded through the > NID registration process as an AD were issuing XML namespaces. In terms > of numbers of NIDs, use by libraries, publishers, and the like are in > the minority. However, I think the bibliographic and museum communities > have issued far more URNs than all the others combined. This may be true. The largest URN user I am aware of is the National library of Norway, which allocated about 600 million URNs to the files in the Norwegian web archive. There are several libraries which have assigned millions of URNs to digital resources (articles, reports etc) as a part of automated ingest processes. Usage of persistent identifiers will increase further, when libraries start assigning identifiers to metadata records and individual data elements such as names of people and organisations. The system created by the Bibliotheque de France (http://data.bnf.fr/) is a good example of this practice which will spread fast with open linked data projects. Juha > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From jehakala@mappi.helsinki.fi Wed Sep 4 09:58:40 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 2A26C11E80F5 for ; Wed, 4 Sep 2013 09:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[AWL=-2.342, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8ioZUK4e89I for ; Wed, 4 Sep 2013 09:58:35 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id BFFAD21F9A99 for ; Wed, 4 Sep 2013 09:58:33 -0700 (PDT) Received: from localhost (webmail-3.mappi.helsinki.fi [128.214.20.217]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r84GwVfE026674; Wed, 4 Sep 2013 19:58:31 +0300 Received: from wifi-guest-gw.ist.utl.pt (wifi-guest-gw.ist.utl.pt [193.136.152.65]) by webmail.helsinki.fi (Horde Framework) with HTTP; Wed, 04 Sep 2013 19:58:31 +0300 Date: Wed, 04 Sep 2013 19:58:29 +0300 Message-ID: <20130904195829.Horde.zJzZDuyF1rFkws0e6fGCnQ1.jehakala@webmail.helsinki.fi> From: jehakala@mappi.helsinki.fi To: Keith Moore References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <5225F192.3030109@network-heretics.com> <5226A61D.2030506@stpeter.im> <5226A938.1070909@network-heretics.com> In-Reply-To: <5226A938.1070909@network-heretics.com> User-Agent: Internet Messaging Program (IMP) H5 (6.0.4) 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] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 16:58:40 -0000 Hello, Quoting Keith Moore : > On 09/03/2013 11:16 PM, Peter Saint-Andre wrote: >>>> In comparison, the planned use of query in the URN context should be >>>> >> relatively simple. But the URN resolvers may need to get smarter. For >>>> >> instance, if I want a resource description instead of the resource >>>> >> itself, the URN resolver may need to extract the required data >>>> >> elements from the URN query into an SRU searchRetrieve URL (if the >>>> >> target system prefers SRU to URN queries). >>> > >>> > I don't think that makes any sense at all, as it either (a) prevents >>> > users from passing queries to end resources, Passing query to the URN resolver is relatively easy since the functionality provided by the relevant resolvers (specified in RDS or indicated more directly with HTTP URI) will be known. Assuming that the users will be provided a GUI where they indicate the services they want (which are then encoded in queries) people will seldom require something that cannot be supplied. For instance, when I see a link to the resource, I may indicate with the tick box that I want rights metadata about the resource, or technical metadata which will tell me which applications will be able to open the file. It will be an interesting task to manage the situation in which the query is somehow passed to the end resource. Do you mean the browser/viewer/whatever in the client end of the process should be able to fulfill the service request? I would not like to be the person with the task to specify anything like full set of such resolution services. Also, given the diversity of the applications used, it will not be easy to guarantee that the client process does not query services that cannot be supplied. As I see it, queries will primarily be used for passing service requests to the URN resolvers. Such functionality makes a lot of sense, at least from implementer point of view. But in order to future proof the syntax it should also be able to specify queries which should be processed in the client end. >> Do we have any examples of passing a query to the sorts of resources >> that are identified by URNs? One standard-based example is OpenURL: http://resolver.example.edu/cgi?genre=book&isbn=0836218310&title=The+Far+Side+Gallery+3 See http://en.wikipedia.org/wiki/OpenURL for more information. OpenURL and URN are regarded as complementary services which will not collide, for instance because they will be resolved in different services. Of course, if I want to find a copy of an identified resource which I can access, the resolver may translate may urn + query into OpenURL. Juha > > What are "the sorts of resources that are identified by URNs"? > > I thought URNs were supposed to be usable with anything, including (but > certainly not limited to) resources that can be named (less > persistently) with ordinary URLs and are accessible via HTTP or other > protocols that support queries. The scope of URN is the sum of scopes of all identifier systems that have registered namespaces. Given that UUID is included, pretty much anything goes. I find it interesting that there is a trend towards providing persistent identifiers also to e.g. names which "live" in deep web and can only be accessed via HTTP if a query protocol such as SRU is applied in order to create a database query. Juha > > Keith From john-ietf@jck.com Wed Sep 4 15:16:42 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 4FBA521F9FCF for ; Wed, 4 Sep 2013 15:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laJ4wkWt11tf for ; Wed, 4 Sep 2013 15:16:36 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 43A5B21F9FED for ; Wed, 4 Sep 2013 15:16:35 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VHLND-000Akm-PG; Wed, 04 Sep 2013 18:16:27 -0400 Date: Wed, 04 Sep 2013 18:16:22 -0400 From: John C Klensin To: Keith Moore Message-ID: In-Reply-To: <52274777.9070901@network-heretics.com> References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <52274777.9070901@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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, 04 Sep 2013 22:16:42 -0000 --On Wednesday, September 04, 2013 10:45 -0400 Keith Moore wrote: > On 09/03/2013 11:21 PM, John C Klensin wrote: >> >> --On Tuesday, September 03, 2013 21:04 -0600 Peter Saint-Andre >> wrote: >> >>>> Would it be appropriate to incorporate text into 2141bis >>>> and/or 3406bis that explicitly reserves "agent" as a query >>>> keyword and specifies "agent=resolver" as the default case? >>> Personally I'd prefer to avoid reserving key-value pairs for >>> the query component... >> Personally, I would too. Personally, I'd prefer that URIs >> were better defined and that some of the underlying issues >> identified in Juha's comments were a part of the basic >> structure so that tricks with key-value pairs were >> unnecessary. I would also like all URN types to be >> registered and for all of their designers, registries and >> assigners of identifying strings, and resolver system >> operators to have the same understanding of "persistence" and >> "permanence". I'd also like a pony :-) >> >> Since I'm unlikely to get any of the things on that list, the >> idea of a single reserved key-value pair seemed like a >> reasonable suggestion. > > I think it would be really odd to define a syntax such that > either all of the query components were passed to the > resolution service, or all of the query components were passed > to the resource. I'm not sure I understand because I think that is what happens all the time with other URIs. If nothing else, I don't know what the model is that parses and distributes different query components. > More generally, I am struggling to think of any situation where > overloading of the same protocol element for use for different > purposes by multiple layers has ever been found to be a good > idea in the long term. >... > Why would use of the same query syntax > for both resolution services and resources be any better? 100% agree. I think the general approach is a bad idea in principle. But I also think that convincing arguments have been made as to why the different services may need to be involved at different points and the alternative to this little trick (or something like it) would be fork URNs away from the RFC 3986 generic URI syntax. As I've said before, in a different world, that would have a lot of appeal to me. But, in this world, that is probably an even worse idea. john From moore@network-heretics.com Thu Sep 5 15:04:04 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 CA56421E8159 for ; Thu, 5 Sep 2013 15:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx81fRN8fkPD for ; Thu, 5 Sep 2013 15:04:00 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2E25A21E813C for ; Thu, 5 Sep 2013 15:04:00 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9955020756; Thu, 5 Sep 2013 18:03:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 05 Sep 2013 18:03:52 -0400 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=cAHiFvgZAK9mEzYUPd1/Kr zWLxY=; b=KmUFu+YMNuQnnZY37zlOz8omYKliw9VxE4yMEUgbt6F/SLSPWHMovp 2HV4Cw3l11lqsi1bR0znlf/QqS/wNv9LMIfuF2N0jV73maA3Pmed6ZVKkCuf+KcE +NJ0UGTOirPsycIq3vkzFcCQ/HZeNqosZx9nIMPS8QeaZKnneq/c0= X-Sasl-enc: 3Uj3OY9kC1oKutORTRdwGkuc+jrRloCX3chb1cYhRxM2 1378418631 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 198F66800B4; Thu, 5 Sep 2013 18:03:50 -0400 (EDT) Message-ID: <5228FFC4.9030808@network-heretics.com> Date: Thu, 05 Sep 2013 18:03:48 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: jehakala@mappi.helsinki.fi References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <5225F192.3030109@network-heretics.com> <5226A61D.2030506@stpeter.im> <5226A938.1070909@network-heretics.com> <20130904195829.Horde.zJzZDuyF1rFkws0e6fGCnQ1.jehakala@webmail.helsinki.fi> In-Reply-To: <20130904195829.Horde.zJzZDuyF1rFkws0e6fGCnQ1.jehakala@webmail.helsinki.fi> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Thu, 05 Sep 2013 22:04:04 -0000 On 09/04/2013 12:58 PM, jehakala@mappi.helsinki.fi wrote: > Hello, > > Quoting Keith Moore : > >> On 09/03/2013 11:16 PM, Peter Saint-Andre wrote: >>>>> In comparison, the planned use of query in the URN context should be >>>>> >> relatively simple. But the URN resolvers may need to get >>>>> smarter. For >>>>> >> instance, if I want a resource description instead of the resource >>>>> >> itself, the URN resolver may need to extract the required data >>>>> >> elements from the URN query into an SRU searchRetrieve URL (if the >>>>> >> target system prefers SRU to URN queries). >>>> > >>>> > I don't think that makes any sense at all, as it either (a) prevents >>>> > users from passing queries to end resources, > > Passing query to the URN resolver is relatively easy since the > functionality provided by the relevant resolvers (specified in RDS or > indicated more directly with HTTP URI) will be known. Assuming that > the users will be provided a GUI where they indicate the services they > want (which are then encoded in queries) people will seldom require > something that cannot be supplied. > For instance, when I see a link to the resource, I may indicate with > the tick box that I want rights metadata about the resource, or > technical metadata which will tell me which applications will be able > to open the file. > I am very hesitant to make assumptions about the user interface, especially when we don't really have much of an idea of what resolution services will exist. (I don't even want to assume that ordinary clients will want to expose this much functionality to the user - useful though it might be, it seems like it would be a drastic departure from how people are accustomed to having "the web" work.) And anyway, I thought we were discussing how to use query syntax (or some other syntax) to embed resolver requests along with URNs, rather than how to present options for resolution to users. I'm not saying that the latter isn't important, but presumably the purpose of embedding the request in the URN is to predetermine what the user gets back, at least as a default. Issues of query syntax aside, how much should clients be expected to know about different URN namespaces and different URN resolvers? Sometimes I get the impression that people in this WG expect clients using URNs to be specific to particular namespaces and for those clients to know specific information about particular resolution services. I have no doubt that such clients will exist, but I think the architecture should facilitate at least some generic handling across all URN namespaces, a common (yet extensible) core resolution protocol that is applicable to most or all URN namespaces, and a common means of discovering resolution services. It is because I envision a common architecture that is independent of URNs that it makes no sense to me that different URN namespaces should treat "?" differently, or that some query parameters should be delegated to resolution services and others to the resources, or that there should be some sort of magic flag that, when it appears in a URN, specifies that all query parameters are passed to the resolver and that there's no way to pass such parameters to the resource. And sure, the way that different URL types handle query syntax is not consistent from one URL to another. That's mostly because a plethora of URL types (each with different ways of treating query syntax) were developed prior to any serious attempt to promote uniform URL syntax. But I don't see that as a justification for repeating the same mistake in URN space. > It will be an interesting task to manage the situation in which the > query is somehow passed to the end resource. Do you mean the > browser/viewer/whatever in the client end of the process should be > able to fulfill the service request? I mean that when you have a resource (like a search engine, or any program on a server that accepts form data) that, by its very nature, accepts queries or is able to do so, passing queries to that resource is a very natural and desirable thing to be able to do. And sure, in those cases, where the interface for passing the query to the resource is known (say, because it is accessible via HTTP or some other well-known protocol that permits transmitting queries), I'd expect the client to be able to properly format the query and pass it to the resource. > I would not like to be the person with the task to specify anything > like full set of such resolution services. Also, given the diversity > of the applications used, it will not be easy to guarantee that the > client process does not query services that cannot be supplied. If the client sends an invalid query, presumably it gets back an error indication. Why is this a problem? > As I see it, queries will primarily be used for passing service > requests to the URN resolvers. Given that there is today a huge number of network-accessible resources that accept queries and process them, why is your assumption that this won't be a common scenario for resources named by URNs? > Such functionality makes a lot of sense, at least from implementer > point of view. But in order to future proof the syntax it should also > be able to specify queries which should be processed in the client end. I think there is a need to be able to both send queries to the resource and send queries to the resolver. But I don't think the two should share a common syntax. > >>> Do we have any examples of passing a query to the sorts of resources >>> that are identified by URNs? > > One standard-based example is OpenURL: > > http://resolver.example.edu/cgi?genre=book&isbn=0836218310&title=The+Far+Side+Gallery+3 > > > See http://en.wikipedia.org/wiki/OpenURL for more information. > > OpenURL and URN are regarded as complementary services which will not > collide, for instance because they will be resolved in different > services. Of course, if I want to find a copy of an identified > resource which I can access, the resolver may translate may urn + > query into OpenURL. I'm having a difficult time seeing how this example illustrates what (I think) we're talking about. > > Juha >> >> What are "the sorts of resources that are identified by URNs"? >> >> I thought URNs were supposed to be usable with anything, including (but >> certainly not limited to) resources that can be named (less >> persistently) with ordinary URLs and are accessible via HTTP or other >> protocols that support queries. > > The scope of URN is the sum of scopes of all identifier systems that > have registered namespaces. Given that UUID is included, pretty much > anything goes. Here's an important architectural principle for URNs: A URN namespace has nothing inherently to do with the resources that are named by URNs within that namespace. At least as far as the overall URN architecture is concerned, any URN in any namespace can name any kind of resource. (If a particular namespace wants to constrain what kinds of resources it names, that's its business. But it's free to change its policy at some point in the future.) So to answer my own question, it's impossible to characterize the sorts of resources that are or will be identified by URNs. And it's probably a mistake to try to make design or architecture choices based on assumptions about what sorts of resources will be used. Keith From juha.hakala@helsinki.fi Wed Sep 18 22:22: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 3B2CC21F991E for ; Wed, 18 Sep 2013 22:22:11 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om8OVEUSdYdy for ; Wed, 18 Sep 2013 22:22:05 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1274B21F992A for ; Wed, 18 Sep 2013 22:22:03 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r8J5Lwmk010059 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 19 Sep 2013 08:22:00 +0300 Message-ID: <523A89F6.8040603@helsinki.fi> Date: Thu, 19 Sep 2013 08:21:58 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John C Klensin References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> In-Reply-To: <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Thu, 19 Sep 2013 05:22:11 -0000 Hello, On 4.9.2013 6:21, John C Klensin wrote: > > --On Tuesday, September 03, 2013 21:04 -0600 Peter Saint-Andre > wrote: > >>> Would it be appropriate to incorporate text into 2141bis >>> and/or 3406bis that explicitly reserves "agent" as a query >>> keyword and specifies "agent=resolver" as the default case? >> Personally I'd prefer to avoid reserving key-value pairs for >> the query component... It might be better to keep 2141bis simple and leave any guidelines of how to use query out of it. Then there will be no need to amend or expand the text in the future as regards the query utilization. The future version of rfc2483 will not even try to provide an exhaustive list of resolution services, since no such thing can exist. Instead there will be an (IANA) registry of services. This registry should contain a mnemonic (for example I2R for URI to resource) for each service and query syntax for requesting them from resolvers (for example "?s=I2R"). In addition, the registry has to list service-specific parameters. Instead of supplying the query related information piece by piece in 2141bis, 3406bis, 2483bis and in the (proposed) registry of services it is better to collect it into one place from which the implementers can easily find it and where it is as easy as possible to maintain it. I am not sure if we need to / can tell the implementers what kind of query combinations make sense. Making such a document exhaustive would be difficult. IMO it would not do any harm to reserve agent as a query keyword. Juha -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From juha.hakala@helsinki.fi Wed Sep 18 23:06:50 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 4CCA521F9B07 for ; Wed, 18 Sep 2013 23:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in1ojkVx6El8 for ; Wed, 18 Sep 2013 23:06:44 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id A7B2E21F9B0D for ; Wed, 18 Sep 2013 23:06:34 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r8J66VWP002263 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 19 Sep 2013 09:06:32 +0300 Message-ID: <523A9466.9080301@helsinki.fi> Date: Thu, 19 Sep 2013 09:06:30 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Keith Moore References: <520FEA9B.8080509@network-heretics.com> <24637769D123E644A105A0AF0E1F92EFA4374E5D@dnbf-ex1.AD.DDB.DE> <521292C2.4030305@stpeter.im> <52129423.7090900@stpeter.im> <5212A197.3080502@network-heretics.com> <521DE0E9.6070001@helsinki.fi> <5225F192.3030109@network-heretics.com> <5226A61D.2030506@stpeter.im> <5226A938.1070909@network-heretics.com> <20130904195829.Horde.zJzZDuyF1rFkws0e6fGCnQ1.jehakala@webmail.helsinki.fi> <5228FFC4.9030808@network-heretics.com> In-Reply-To: <5228FFC4.9030808@network-heretics.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: jehakala@mappi.helsinki.fi, urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Thu, 19 Sep 2013 06:06:50 -0000 On 6.9.2013 1:03, Keith Moore wrote: > On 09/04/2013 12:58 PM, jehakala@mappi.helsinki.fi wrote: >> Hello, >> >> Quoting Keith Moore : >> >> > > And anyway, I thought we were discussing how to use query syntax (or > some other syntax) to embed resolver requests along with URNs, rather > than how to present options for resolution to users. I'm not saying > that the latter isn't important, but presumably the purpose of embedding > the request in the URN is to predetermine what the user gets back, at > least as a default. Yes. User interfaces are important in this context only because a user may not know what services are available for a given document, and how to construct an appropriate query. > > Issues of query syntax aside, how much should clients be expected to > know about different URN namespaces and different URN resolvers? Clients such as Web browsers should not be expected to know much of what is going on. The main "players" are URN resolvers and the applications they contact to request the service the user is asking for. For instance, Finnish national bibliography may contain a description of an e-book with a URN in it. The GUI of the national bibliography database may give a user an option to find a copy of the book he is allowed to use. When the user clicks that button, the URN + query are passed to the resolver. The resolver passes the request on the the valid OpenURL resolver, which will check the users' permissions and choose an appropriate copy of the resource. > > Sometimes I get the impression that people in this WG expect clients > using URNs to be specific to particular namespaces and for those clients > to know specific information about particular resolution services. I > have no doubt that such clients will exist, but I think the architecture > should facilitate at least some generic handling across all URN > namespaces, a common (yet extensible) core resolution protocol that is > applicable to most or all URN namespaces, and a common means of > discovering resolution services. URN resolver discovery service would be useful, but unfortunately does not exist yet although incorporating it into DNS has been foreseen ever since the first URN WG. The difficulty of finding an appropriate resolver varies from one namespace to the next. If the identifier is "dumb", there is no hint where to find a resolver and only one can exist. ISSN is an example of this; the only place where they can be resolved is the ISSN database of the International ISSN Centre. The more "intelligent" the identifier, the more resolvers then can / must be. NBN and ISBN resolution can / must decentralized to the national level. IMO an identifier which a priori cannot be resolved ("dumb" identifier with no central database) does not deserve a URN namespace. If all URNs from a given namespace are resolved in a single place we know exactly what services will be available. But often there will be multiple resolvers, and the only means of "quality control" is to recommend a minimum set of services in the namespace registration. We have earlier decided that some namespaces may not provide any resolution services at all. This means that core resolution protocol will not apply to all namespaces. > > It is because I envision a common architecture that is independent of > URNs that it makes no sense to me that different URN namespaces should > treat "?" differently, or that some query parameters should be delegated > to resolution services and others to the resources, or that there should > be some sort of magic flag that, when it appears in a URN, specifies > that all query parameters are passed to the resolver and that there's no > way to pass such parameters to the resource. As I see it, different URN namespaces will provide different services, but in all namespaces, a query like "?s=I2L" should provide the same result. And I guess there can be services where the agent can be either the resolver or the client. > > And sure, the way that different URL types handle query syntax is not > consistent from one URL to another. That's mostly because a plethora of > URL types (each with different ways of treating query syntax) were > developed prior to any serious attempt to promote uniform URL syntax. > But I don't see that as a justification for repeating the same mistake > in URN space. > >> It will be an interesting task to manage the situation in which the >> query is somehow passed to the end resource. Do you mean the >> browser/viewer/whatever in the client end of the process should be >> able to fulfill the service request? > I mean that when you have a resource (like a search engine, or any > program on a server that accepts form data) that, by its very nature, > accepts queries or is able to do so, passing queries to that resource is > a very natural and desirable thing to be able to do. And sure, in > those cases, where the interface for passing the query to the resource > is known (say, because it is accessible via HTTP or some other > well-known protocol that permits transmitting queries), I'd expect the > client to be able to properly format the query and pass it to the resource. OK. I have misunderstood your point; to me resource is the object that is the URN identifies. The scenario above is plausible. Let us assume that we want to retrieve bibliographic data about a resource from a library database. The URN + query can be passed to the resolver, which then sends it to the library system as SRU query. But there is no reason why the library system itself would not be able to process URN + query as such. > >> As I see it, queries will primarily be used for passing service >> requests to the URN resolvers. > Given that there is today a huge number of network-accessible resources > that accept queries and process them, why is your assumption that this > won't be a common scenario for resources named by URNs? See above. > >> Such functionality makes a lot of sense, at least from implementer >> point of view. But in order to future proof the syntax it should also >> be able to specify queries which should be processed in the client end. > I think there is a need to be able to both send queries to the resource > and send queries to the resolver. But I don't think the two should > share a common syntax. Why? Juha -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From john-ietf@jck.com Thu Sep 19 08:10: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 123B721F992A for ; Thu, 19 Sep 2013 08:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.493 X-Spam-Level: X-Spam-Status: No, score=-104.493 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvHAeS36RvXL for ; Thu, 19 Sep 2013 08:10:16 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 418AE21F991E for ; Thu, 19 Sep 2013 08:10:16 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VMfry-000FDq-Lv; Thu, 19 Sep 2013 11:10:14 -0400 Date: Thu, 19 Sep 2013 11:10:09 -0400 From: John C Klensin To: urn@ietf.org Message-ID: In-Reply-To: <523A89F6.8040603@helsinki.fi> References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [urn] Open letter to WG participants (was: Re: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Thu, 19 Sep 2013 15:10:21 -0000 Hi. This note started as part of a reply to To be clear, I've got two personal goals in this. I hope most of the WG shares them, but I have no way to tell. One is to get the core set of URN specs far enough along that the WG can finish them and get them through the process and published. Because of necessary interdependencies, I think that list is 2141bis (syntax), 3406bis (namespace definition and registration), last month's ns-reg-transition document, and, probably, 3188bis (NBN). I'm concerned that, if we don't get on with this, various parties will make assumptions about what we will do or should do and go off on their own, leading to future compatibility and interoperability problems. In addition, there are a number of URN registrations in various pending states now (including one that stirred up a lot of noise on the IETF list in the last weeks). We would be far better off if they could get approved/registered under 3188bis. Otherwise, we will need to worry about whether or not they need to be upgraded. The WG will be three years old in late November. I hope and wish we could set a target of having the documents in the hands of the IESG well before that, ideally before Vancouver. Second, it seems obvious to me that we need to future-proof 2141bis and, to the extent necessary, 3406bis. There have been several incidents around the IETF in recent years in which people have said things equivalent to "cannot change or expand that feature because it was specified a different way once and has to be that way forever". The discussions that follow are always complex and unpleasant because the tradeoffs between stability and increased functionality or interoperability are difficult; usually the results are "least bad" solutions. In particular for queries, 2141 was wise in reserving "?" and therefore queries, but, if we even allow "?" in the syntax, we need to be careful that we don't create a future trap for ourselves. A registry of query keywords would be a big step and almost certainly not in the spirit of 3986. It is pretty clear to me that, if we want to do it, we need to do it now, not just to create the registry and rules for it but probably to define a way of distinguishing, by syntax, between keywords that are intended to have global meaning and those that are to be interpreted locally. I don't see reserving a specific keyword or two to have nearly the same implications as trying to give still-unspecified keywords global meanings but either approach becomes part of the critical path and interferes with my "swift completion" fantasies, especially given the speed at which this WG seems to hold discussions. best, john p.s. the supposed WG LC that started this thread was announced for two weeks starting 13 August and was supposed to terminate on 27 August (http://www.ietf.org/mail-archive/web/urn/current/msg02062.html). It is now over three weeks since the closing date and I, at least, have no idea where we are. Do the WG Chair(s) think we have consensus? Is a new version of 2141bis to reflect the many comments expected and, if so, when? Given the dependencies between 2141bis and 3406bis and the risk that details of the latter will require changes to the former, when do we expect the promised new version of 3406bis? From john-ietf@jck.com Thu Sep 19 23:27:31 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 AC10221F84B7 for ; Thu, 19 Sep 2013 23:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.555 X-Spam-Level: X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAMy7SMzGsKX for ; Thu, 19 Sep 2013 23:27:26 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A03A021F84B1 for ; Thu, 19 Sep 2013 23:27:26 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VMuBU-000GRu-5k; Fri, 20 Sep 2013 02:27:20 -0400 Date: Fri, 20 Sep 2013 02:27:15 -0400 From: John C Klensin To: Juha Hakala Message-ID: <0309538CE9F76FA70456AB55@JcK-HP8200.jck.com> In-Reply-To: <523A89F6.8040603@helsinki.fi> References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Fri, 20 Sep 2013 06:27:31 -0000 --On Thursday, September 19, 2013 08:21 +0300 Juha Hakala wrote: > Hello, > > On 4.9.2013 6:21, John C Klensin wrote: >> >> --On Tuesday, September 03, 2013 21:04 -0600 Peter Saint-Andre >> wrote: >> >>>> Would it be appropriate to incorporate text into 2141bis >>>> and/or 3406bis that explicitly reserves "agent" as a query >>>> keyword and specifies "agent=resolver" as the default case? >>> Personally I'd prefer to avoid reserving key-value pairs for >>> the query component... > It might be better to keep 2141bis simple and leave any > guidelines of how to use query out of it. Then there will be > no need to amend or expand the text in the future as regards > the query utilization. The problem I see is that, unless we leave "?" as "reserved, use prohibited" --which would not serve any of the needs that have been identified for queries-- we either need to specify guidelines now or lose control of it. Global (i.e., across namespaces) keywords, any reserved keywords, any attempt to distinguish between queries to resolution mechanisms and queries to objects, and so on either need to have provision made for them now or we will find that adding them later is hopeless. > The future version of rfc2483 will not even try to provide an > exhaustive list of resolution services, since no such thing > can exist. Instead there will be an (IANA) registry of > services. This registry should contain a mnemonic (for example > I2R for URI to resource) for each service and query syntax for > requesting them from resolvers (for example "?s=I2R"). In > addition, the registry has to list service-specific parameters. I'm not sure. We've got IANA registries for URN namespaces (http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml). They could easily be extended to include per-namespace resolution services information and parameters if that were really needed. Do you think a separate mechanism is important? > Instead of supplying the query related information piece by > piece in 2141bis, 3406bis, 2483bis and in the (proposed) > registry of services it is better to collect it into one place > from which the implementers can easily find it and where it is > as easy as possible to maintain it. Historically, most "query related information" has been per-domain (or, in our case, presumably per-NID) and not in any sense global. In particular, there has never been a requirement, s.t., e.g., given http://www.example.com/?fribble=zorg and http://www.example.net/?fribble=zorg that either "fribble" or "zorg" have the same interpretation in both URLs (or even that "zorg" does if "fribble" happens to do so). So were are fairly far into uncharted territory here. And, fwiw, I think it is certain that there will be at least some query keywords that the relevant namespace maintainers will have no desire to give a global interpretation. That is likely to be another example of "if we tell then to not do it, they will ignore us". > I am not sure if we need to / can tell the implementers what > kind of query combinations make sense. Making such a document > exhaustive would be difficult. or impossible. > IMO it would not do any harm to reserve agent as a query > keyword. yes, although that is, to some degree, part of the problem (see the other note). best, john From sm@resistor.net Sat Sep 21 10:47:45 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 641A621F9CEA for ; Sat, 21 Sep 2013 10:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIzruSaVARSv for ; Sat, 21 Sep 2013 10:47:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 563F621F9CDA for ; Sat, 21 Sep 2013 10:47:44 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8LHlRtc005312; Sat, 21 Sep 2013 10:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379785655; bh=pl8Y051lzkUHqevNClH7LESzN4JqxO2QH+I3TbMLj7U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bhHhi2FausPa4pUNl8YDKZmUZSVF9AyWtLw+JQl5lMXzqarkGHUA9RbsviqzAxCKI yPh9AWmhnZr1ZRNuxOD+5R9BmKgu2e5lOx8O77+XNmtRW3UxwJNlP4yf2qES53S0U8 hDR62pXhxgAKBEvggKDvhOGuGUvT03LW5W2ppwjk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1379785655; i=@resistor.net; bh=pl8Y051lzkUHqevNClH7LESzN4JqxO2QH+I3TbMLj7U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zI+fzw1pZsqK/SiwVhYW9fvqt5f8Q2musDGgZu9DwrZF+pSovPi8UjtfyvsQfs8tM XIyHh+3a6x7VhhLk0s6ZL6noG4E204tLr/20qJRGm+L2qCwba2EcPVAoQk6nnGU85o OT8ZsPLoiOMZSWE97sB5a4KPi7zMpWBntqCeOBkQ= Message-Id: <6.2.5.6.2.20130921101933.064ab7d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 21 Sep 2013 10:28:04 -0700 To: Andrew Newton , Alfred Hoenes From: SM In-Reply-To: References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: urn@ietf.org Subject: Re: [urn] Open letter to WG participants (was: Re: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Sat, 21 Sep 2013 17:47:45 -0000 Hi Andrew, Alfred, At 08:10 19-09-2013, John C Klensin wrote: >The WG will be three years old in late November. I hope and >wish we could set a target of having the documents in the hands >of the IESG well before that, ideally before Vancouver. The milestone was February 2013. >p.s. the supposed WG LC that started this thread was announced >for two weeks starting 13 August and was supposed to terminate >on 27 August >(http://www.ietf.org/mail-archive/web/urn/current/msg02062.html). >It is now over three weeks since the closing date and I, at >least, have no idea where we are. Do the WG Chair(s) think we >have consensus? Is a new version of 2141bis to reflect the many >comments expected and, if so, when? Given the dependencies >between 2141bis and 3406bis and the risk that details of the >latter will require changes to the former, when do we expect the >promised new version of 3406bis? I have not seen any response to the above questions. I think that it would help the WG work if the WG Chairs could provide a timely response. Regards, -sm From juha.hakala@helsinki.fi Sun Sep 22 22:03: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 73CDE21F9E13 for ; Sun, 22 Sep 2013 22:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.251 X-Spam-Level: X-Spam-Status: No, score=-5.251 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4gtEsVRwrYa for ; Sun, 22 Sep 2013 22:03:52 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id B17DB21F9E0B for ; Sun, 22 Sep 2013 22:03:49 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r8N53jCF020402 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 23 Sep 2013 08:03:46 +0300 Message-ID: <523FCBB0.1070700@helsinki.fi> Date: Mon, 23 Sep 2013 08:03:44 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John C Klensin References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> <0309538CE9F76FA70456AB55@JcK-HP8200.jck.com> In-Reply-To: <0309538CE9F76FA70456AB55@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Mon, 23 Sep 2013 05:03:56 -0000 Hello, On 20.9.2013 9:27, John C Klensin wrote: > > --On Thursday, September 19, 2013 08:21 +0300 Juha Hakala > wrote: > >> Hello, >> >> On 4.9.2013 6:21, John C Klensin wrote: > The problem I see is that, unless we leave "?" as "reserved, use > prohibited" --which would not serve any of the needs that have > been identified for queries-- we either need to specify > guidelines now or lose control of it. Global (i.e., across > namespaces) keywords, any reserved keywords, any attempt to > distinguish between queries to resolution mechanisms and queries > to objects, and so on either need to have provision made for > them now or we will find that adding them later is hopeless. We need to specify guidelines for using query, but we do not need to do that in 2141bis or 3406bis. Resolution services and their properties are dependent on the underlying technical infrastructure and therefore subject to change. RFC 2483 was a good start, but we know now that new services pop up constantly, and at least in some cases existing services are enriched; I2C is a good example of that. >> The future version of rfc2483 will not even try to provide an >> exhaustive list of resolution services, since no such thing >> can exist. Instead there will be an (IANA) registry of >> services. This registry should contain a mnemonic (for example >> I2R for URI to resource) for each service and query syntax for >> requesting them from resolvers (for example "?s=I2R"). In >> addition, the registry has to list service-specific parameters. > I'm not sure. We've got IANA registries for URN namespaces > (http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml). > They could easily be extended to include per-namespace > resolution services information and parameters if that were > really needed. Do you think a separate mechanism is important? It would be cumbersome to provide resolution service specifications only in the context of namespace registrations. Same information would be repeated many times, and it would be difficult to find all services and service parameters. The current registry for URN namespaces can however be extended with service-related information. There would first be the list of services and service parameters, followed by namespace registrations (which may provide information about global / local services available). As far as I am concerned, we can choose whatever approach IANA prefers - new registry or an extension of the current one. > > >> Instead of supplying the query related information piece by >> piece in 2141bis, 3406bis, 2483bis and in the (proposed) >> registry of services it is better to collect it into one place >> from which the implementers can easily find it and where it is >> as easy as possible to maintain it. > Historically, most "query related information" has been > per-domain (or, in our case, presumably per-NID) and not in any > sense global. In particular, there has never been a > requirement, s.t., e.g., given > http://www.example.com/?fribble=zorg > and > http://www.example.net/?fribble=zorg > that either "fribble" or "zorg" have the same interpretation in > both URLs (or even that "zorg" does if "fribble" happens to do > so). There are many popular Internet protocols (for instance, SRU, OAI-PMH and OpenURL) which rely on globally coordinated usage of query. These standards are used across domains (libraries, publishers, universities etc.). As far as I know, there has been no problems in using query as required by these protocols. IMO queries in URNs will be simple in comparison. See for instance http://www.openarchives.org/OAI/openarchivesprotocol.html for relatively complex usage of query (which is more or less globally supported by institutional repositories). With URNs, we have assumed since RFC 2483 that it is possible to specify a limited set of generic resolution services. If that is the case, there may be per-NID services, but there will also be services which will be supported across multiple NIDs. And any per-NID service may later become more widely used. For instance, users want to find copies of resources that they can access. Underlying technical infrastructure, based on the OpenURL technology, is widely supported by publishers and libraries. Therefore multiple URN namespaces have a need and technical capabilities to support new service "URI to accessible resource", or I2AR. > > So were are fairly far into uncharted territory here. This territory may be uncharted to IETF, but not to e.g. libraries and publishers. > And, > fwiw, I think it is certain that there will be at least some > query keywords that the relevant namespace maintainers will have > no desire to give a global interpretation. That is likely to be > another example of "if we tell then to not do it, they will > ignore us". It may help to allow specification of formal, informal and experimental resolution services and perhaps even service parameters. Nobody else is likely to start using an experimental resolution service, but other users may be interested in registering an experimental service as formal, once it has been battle proven. All the best, Juha > >> I am not sure if we need to / can tell the implementers what >> kind of query combinations make sense. Making such a document >> exhaustive would be difficult. > or impossible. > >> IMO it would not do any harm to reserve agent as a query >> keyword. > yes, although that is, to some degree, part of the problem (see > the other note). > > best, > john > -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From duerst@it.aoyama.ac.jp Mon Sep 23 00:30:24 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 902C921F90CC for ; Mon, 23 Sep 2013 00:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.148 X-Spam-Level: X-Spam-Status: No, score=-104.148 tagged_above=-999 required=5 tests=[AWL=-0.358, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj9dP-WgAlTR for ; Mon, 23 Sep 2013 00:30:18 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBFB21F93F8 for ; Mon, 23 Sep 2013 00:30:16 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8N7Tw3B029914; Mon, 23 Sep 2013 16:29:59 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 413a_f54d_f31b7998_2421_11e3_8c44_001e6722eec2; Mon, 23 Sep 2013 16:29:57 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 73EB1BF4E2; Mon, 23 Sep 2013 16:29:57 +0900 (JST) Message-ID: <523FEDDF.9080805@it.aoyama.ac.jp> Date: Mon, 23 Sep 2013 16:29:35 +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: Juha Hakala References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> In-Reply-To: <523A89F6.8040603@helsinki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: [urn] Separate schemes for resources and resolution services (was: Re: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Mon, 23 Sep 2013 07:30:24 -0000 Hello Juha, John, others, Caveat: I have been following the urn WG only with a limited time budget, but see below for my thinking. On 2013/09/19 14:21, Juha Hakala wrote: > Hello, > > On 4.9.2013 6:21, John C Klensin wrote: >> >> --On Tuesday, September 03, 2013 21:04 -0600 Peter Saint-Andre >> wrote: >> >>>> Would it be appropriate to incorporate text into 2141bis >>>> and/or 3406bis that explicitly reserves "agent" as a query >>>> keyword and specifies "agent=resolver" as the default case? >>> Personally I'd prefer to avoid reserving key-value pairs for >>> the query component... > It might be better to keep 2141bis simple and leave any guidelines of > how to use query out of it. Then there will be no need to amend or > expand the text in the future as regards the query utilization. > > The future version of rfc2483 will not even try to provide an exhaustive > list of resolution services, since no such thing can exist. Instead > there will be an (IANA) registry of services. This registry should > contain a mnemonic (for example I2R for URI to resource) for each > service and query syntax for requesting them from resolvers (for example > "?s=I2R"). In addition, the registry has to list service-specific > parameters. > > Instead of supplying the query related information piece by piece in > 2141bis, 3406bis, 2483bis and in the (proposed) registry of services it > is better to collect it into one place from which the implementers can > easily find it and where it is as easy as possible to maintain it. > > I am not sure if we need to / can tell the implementers what kind of > query combinations make sense. Making such a document exhaustive would > be difficult. > > IMO it would not do any harm to reserve agent as a query keyword. URNs are resource identifiers. As such, I think that if they have query parameters, these should be defined by the resource, without any influence by resolution services. That's what I'd assume for any other URI scheme, too. For something close to resolution parameters, I seem to remember that an early URI spec defined a place for such parameters after a ';'. I can dig up the spec if that helps. However, I think that it might be better to create a new scheme, or new schemes, for resolution services if they need additional parameters. An example generic 'resolution service' scheme might look as follows: urn-resolution:urn=urn:isbn:123-45678-90;resolve-to=meta_data Schemes for particular resolver protocols are also possible; some of them might not need their own scheme, in particular if they run over http. This has several advantages: It separates the resource from the resolution, which is conceptually how things should be.[*] It allows both resources and resolution to use whatever 'query' parameters they deem appropriate, without name conflicts, and it allows the query parameter space for resolution services to be developed from now on, at a point where we are not sure yet how much these parameters will be shared between resolution services. Hope this helps, Martin. [*] Just to give an example, nobody would propose to put a "proxy" parameter into an http: URI, although HTTP proxies can be thought of as a kind of resolution service. Also, nobody would propose to add something to the http: URI syntax in order to e.g. distinguish a "GET" request from a "HEAD" request. But this is quite close to the distinction between 'resource' and 'metadata' in the URN resolver discussions. From andy@hxr.us Mon Sep 23 11:07: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 6359021F8A7B for ; Mon, 23 Sep 2013 11:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.977 X-Spam-Level: X-Spam-Status: No, score=-4.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GgpCA9rhKXH for ; Mon, 23 Sep 2013 11:07:11 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8003421F9D42 for ; Mon, 23 Sep 2013 11:06:44 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id ld10so3885770pab.22 for ; Mon, 23 Sep 2013 11:06:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L4bOfnir+c5A22gm9/1B5Zvu9F8PkEJroNK70MyrtLo=; b=Aq5VlxeFe6/vLZTq/Msdbr8mUUOuCeMWjHKa9qHeMCCTVhl9eg/acvrUcDsmVfpKOT WlpWlR/2uP5jcAiTZp38D11yGVIfuX19F+oDKsDD6PnIMMEM2YaYeHSEMnK00378Xcg9 Zyy01n8tsLtnLj7K/wITBLwEeHVOmrbVjHQ8vPk97y+OpGl0xyLgFsJ+j7OrNWmqP4+B IO0y7cD30bufPmPG02846cf5M4HUNTtwrwrBDzDOyla+ot+1yY8uZaqsawJnLKdxSxIl UL2qu5Ea2vQMS9Z+r9KKD3BKmnOyjQt7e2QuwX541mUMPXmRJorMn/EVFj4grY2XQ3eS GA7Q== X-Gm-Message-State: ALoCoQkScawnmEuwZ3jWbfEFebHHo5PLUXiL+NH2dC8peUupnXYQQl/rH2CAcLrBCFNjuTAJ0MBJ MIME-Version: 1.0 X-Received: by 10.66.227.39 with SMTP id rx7mr26466241pac.44.1379959602807; Mon, 23 Sep 2013 11:06:42 -0700 (PDT) Received: by 10.68.113.68 with HTTP; Mon, 23 Sep 2013 11:06:42 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> Date: Mon, 23 Sep 2013 14:06:42 -0400 Message-ID: From: Andrew Newton To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: "urn@ietf.org" Subject: Re: [urn] Open letter to WG participants (was: Re: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Mon, 23 Sep 2013 18:07:16 -0000 On Thu, Sep 19, 2013 at 11:10 AM, John C Klensin wrote: > p.s. the supposed WG LC that started this thread was announced > for two weeks starting 13 August and was supposed to terminate > on 27 August > (http://www.ietf.org/mail-archive/web/urn/current/msg02062.html). > It is now over three weeks since the closing date and I, at > least, have no idea where we are. Do the WG Chair(s) think we > have consensus? John, Thank you for this note. I should have sent a message to the list earlier regarding the WGLC. It is my opinion that we do not have consensus on 2141bis with respect to Keith Moore's observation regarding a difference between the query parameters used by a resolution service and those used by a resource. This issue needs to be addressed in some manner, either by a technical solution, text explaining why it is not of concern, or something in between. If ideas have already been put forward, then we need to call them out specifically in separate email threads as the discussions on this list can be quite involved. I hope this helps. If there are any questions, please ask. -andy From juha.hakala@helsinki.fi Mon Sep 23 22:33:59 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 C72DE21F9E11 for ; Mon, 23 Sep 2013 22:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocb4VIGZCxDd for ; Mon, 23 Sep 2013 22:33:55 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 60F5811E80D1 for ; Mon, 23 Sep 2013 22:33:53 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r8O5Xoce023276 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 24 Sep 2013 08:33:52 +0300 Message-ID: <5241243E.9020003@helsinki.fi> Date: Tue, 24 Sep 2013 08:33:50 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] Open letter to WG participants 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, 24 Sep 2013 05:33:59 -0000 Hello, On 23.9.2013 21:06, Andrew Newton wrote: > > It is my opinion that we do not have consensus on 2141bis with respect > to Keith Moore's observation regarding a difference between the query > parameters used by a resolution service and those used by a resource. > > This issue needs to be addressed in some manner, either by a technical > solution, text explaining why it is not of concern, or something in > between. I believe this issue is not of concern (from 2141bis and 3406bis point of view). Our technical environment consists of (among other things): - resolvers, which may deal with 1-n namespaces (and even 1-n persistent identifiers) - resources, such as HTTP servers or institutional repositories, and - objects and their surrogates, such as e-books and metadata about them By definition, every URN is always processed by the appropriate URN resolver first. Since we do not have a resolver discovery service in place, for the time being we use HTTP URIs which include the resolver address such as http://urn.fi. There is not much intelligence in current resolvers; they often just map the URN to one or 1-n URLs. In the future, when query is used to convey additional information about the users' wishes, resolvers must get a lot smarter. They must be able to understand which URN resolution service & parameter is being requested. They must also know which resource(s) will be able to supply what the human / software user is asking for. In order to simplify the implementation process, resolvers will transform the URNs into something that can be processed by the resources. For instance, a user may want bibliographic information about the object identified by the URN. If the appropriate resource (e.g. an institutional repository) supports SRU query protocol, the resolver can create an SRU search request and pass it on to DSpace, Fedora or other repository application is used. If the resolver knows that the resource supports URN queries as such, the resolver has an option of passing the URN unchanged to the resource. But this may not be the best policy (see below). HTTP URI http://urn.fi/URN:ISBN:978-952-60-5254-0 is currently resolved to URL https://aaltodoc.aalto.fi/handle/123456789/10927. No other resolution services are available. In the future, a user may ask for a full bibliographic description of the book identified by this URN:ISBN. In order to facilitate this, the URN resolver at http://urn.fi (which is globally responsible of resolving all URN:ISBNs where ISBN starts with 978-952) must know that metadata about Finnish books is available in e.g. the national bibliography and that this database supports SRU search protocol. Then the resolver can change for instance URN + query http://urn.fi/URN:ISBN:978-952-60-5254-0?s=I2C&p=fullRecord into a search request the SRU server in the national bibliography database can deal with (what follows is just an example of what a resulting search might look like): http://linnea1.linneanet.fi:11391/voyager?version=1.1&operation=searchRetrieve&query=978-952-60-5254-0&maximumRecords=1&recordSchema=marcxml URIs like this are not persistent (and unlike RFC3986 says, they certainly do not identify anything ;-)). The mapping tables in the resolver have to be maintained so that even if the record schemas, protocol versions and applications change, the users will still get what they want. I guess any resource such as database application could be enhanced so that it can deal with "raw" URN queries, but for existing (and future) standard driven resolution services it is more economical to let the resolvers convert the URNs centrally into e.g. SRU queries, OpenURLs etc, since these URIs are already widely supported by a large number of different Internet resources. Allowing queries to pass unchecked and unprocessed through URN resolvers to resources would also increase the risk that the resources would not know what to do with the particular query. A resource may support only a subset of resolution services and service parameters, and maintaining all this detailed information in the URN resolver would be cumbersome. Many current and future resolution services will be based on widely used standard protocols such as OpenURL and SRU. This will make it easier to get started with query usage and make the existing resolvers smarter. No doubt there will also be localized and / or non-standard services, and for them passing the URN + query on unchanged from the URN resolver to the resource may be a practical alternative. All the best, Juha > If ideas have already been put forward, then we need to call > them out specifically in separate email threads as the discussions on > this list can be quite involved. > > I hope this helps. If there are any questions, please ask. > > -andy > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From L.Svensson@dnb.de Tue Sep 24 01:13: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 8BB0C21F9DCE for ; Tue, 24 Sep 2013 01:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.249 X-Spam-Level: X-Spam-Status: No, score=-12.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD05GlwGkoCN for ; Tue, 24 Sep 2013 01:12:56 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id B73A921F9DCF for ; Tue, 24 Sep 2013 01:12:43 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 9CA727EECD; Tue, 24 Sep 2013 10:12:40 +0200 (CEST) From: "Svensson, Lars" To: Andrew Newton , John C Klensin Thread-Topic: [urn] Open letter to WG participants (was: Re: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt) Thread-Index: Ac612xEfKNucDJgcQXWcBb7wUKry6ACm9NkAACGsKnA= Date: Tue, 24 Sep 2013 08:12:40 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4393897@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.123] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] Open letter to WG participants (was: Re: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.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: Tue, 24 Sep 2013 08:13:00 -0000 On Montag, 23. September 2013 20:07, Andrew Newton wrote: > It is my opinion that we do not have consensus on 2141bis with respect to > Keith Moore's observation regarding a difference between the query > parameters used by a resolution service and those used by a resource. In my opinion we also do not have consensus on the allowed/reserved charact= ers, particularly ~, / and &. Best regards, 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 From duerst@it.aoyama.ac.jp Wed Sep 25 18:55:50 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 7EB4A21F9E3B for ; Wed, 25 Sep 2013 18:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.921 X-Spam-Level: X-Spam-Status: No, score=-103.921 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XXXpugmEJkA for ; Wed, 25 Sep 2013 18:55:45 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 33FD321F89F7 for ; Wed, 25 Sep 2013 18:55:44 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8Q1tDZI017002; Thu, 26 Sep 2013 10:55:14 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0fa5_abcb_af1689c0_264e_11e3_8134_001e6722eec2; Thu, 26 Sep 2013 10:55:12 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 508F4BF4D0; Thu, 26 Sep 2013 10:55:13 +0900 (JST) Message-ID: <524393F6.9030303@it.aoyama.ac.jp> Date: Thu, 26 Sep 2013 10:55:02 +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: Juha Hakala References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> <5241243E.9020003@helsinki.fi> In-Reply-To: <5241243E.9020003@helsinki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Open letter to WG participants 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, 26 Sep 2013 01:55:50 -0000 Hello Juha, others, On 2013/09/24 14:33, Juha Hakala wrote: > Hello, > > On 23.9.2013 21:06, Andrew Newton wrote: >> >> It is my opinion that we do not have consensus on 2141bis with respect >> to Keith Moore's observation regarding a difference between the query >> parameters used by a resolution service and those used by a resource. >> >> This issue needs to be addressed in some manner, either by a technical >> solution, text explaining why it is not of concern, or something in >> between. > I believe this issue is not of concern (from 2141bis and 3406bis point > of view). > > Our technical environment consists of (among other things): > > - resolvers, which may deal with 1-n namespaces (and even 1-n persistent > identifiers) > - resources, such as HTTP servers or institutional repositories, and > - objects and their surrogates, such as e-books and metadata about them Can we *please* use a terminology that isn't in conflict with the terminology of RFC 3986 (URI spec)? The term 'resource' is used in RFC 3986 (and many other places) for the stuff that is denoted by URIs (including URNs). So please change 'resource' to something like 'server infrastructure' or so, to avoid confusion. > By definition, every URN is always processed by the appropriate URN > resolver first. Not necessarily. There may be URN namespaces such as one for integers (surely something very persistent; I seem to remember there having been a proposal for such a thing, but I don't remember how far it went), and resolution for them may be just built in to some of the software that uses them. Of course you could also call this built-in software component a resolver, but then you'd also have to call the software/protocol/server combination that deals with http requests a resolver. > Since we do not have a resolver discovery service in > place, for the time being we use HTTP URIs which include the resolver > address such as http://urn.fi. There is not much intelligence in current > resolvers; they often just map the URN to one or 1-n URLs. > > In the future, when query is used to convey additional information about > the users' wishes, resolvers must get a lot smarter. They must be able > to understand which URN resolution service & parameter is being > requested. They must also know which resource(s) will be able to supply > what the human / software user is asking for. In order to simplify the > implementation process, resolvers will transform the URNs into something > that can be processed by the resources. For instance, a user may want > bibliographic information about the object identified by the URN. If the > appropriate resource (e.g. an institutional repository) supports SRU > query protocol, the resolver can create an SRU search request and pass > it on to DSpace, Fedora or other repository application is used. > > If the resolver knows that the resource supports URN queries as such, > the resolver has an option of passing the URN unchanged to the resource. > But this may not be the best policy (see below). > > HTTP URI http://urn.fi/URN:ISBN:978-952-60-5254-0 is currently resolved > to URL https://aaltodoc.aalto.fi/handle/123456789/10927. No other > resolution services are available. > > In the future, a user may ask for a full bibliographic description of > the book identified by this URN:ISBN. In order to facilitate this, the > URN resolver at http://urn.fi (which is globally responsible of > resolving all URN:ISBNs where ISBN starts with 978-952) must know that > metadata about Finnish books is available in e.g. the national > bibliography and that this database supports SRU search protocol. > > Then the resolver can change for instance URN + query > > http://urn.fi/URN:ISBN:978-952-60-5254-0?s=I2C&p=fullRecord > > into a search request the SRU server in the national bibliography > database can deal with (what follows is just an example of what a > resulting search might look like): > > http://linnea1.linneanet.fi:11391/voyager?version=1.1&operation=searchRetrieve&query=978-952-60-5254-0&maximumRecords=1&recordSchema=marcxml > > > URIs like this are not persistent (and unlike RFC3986 says, they > certainly do not identify anything ;-)). Of course they identify something. They identify the search request, or the results of that request, if nothing else. > The mapping tables in the > resolver have to be maintained so that even if the record schemas, > protocol versions and applications change, the users will still get what > they want. > > I guess any resource such as database application could be enhanced so > that it can deal with "raw" URN queries, but for existing (and future) > standard driven resolution services it is more economical to let the > resolvers convert the URNs centrally into e.g. SRU queries, OpenURLs > etc, since these URIs are already widely supported by a large number of > different Internet resources. Allowing queries to pass unchecked and > unprocessed through URN resolvers to resources would also increase the > risk that the resources would not know what to do with the particular > query. A resource may support only a subset of resolution services and > service parameters, and maintaining all this detailed information in the > URN resolver would be cumbersome. > > Many current and future resolution services will be based on widely used > standard protocols such as OpenURL and SRU. This will make it easier to > get started with query usage and make the existing resolvers smarter. No > doubt there will also be localized and / or non-standard services, and > for them passing the URN + query on unchanged from the URN resolver to > the resource may be a practical alternative. I would like to point out that in the examples above, there is no example of an URN with a query part. In both the http://urn.fi/ example and the http://linnea1.linneanet.fi example, the query part is a http query part. Can you please make an example with query parts directly on an urn, and show how it fits into the above picture? Regards, Martin. > All the best, > > Juha > >> If ideas have already been put forward, then we need to call >> them out specifically in separate email threads as the discussions on >> this list can be quite involved. >> >> I hope this helps. If there are any questions, please ask. >> >> -andy >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > > From juha.hakala@helsinki.fi Wed Sep 25 23:03:18 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 E2E3521F9E02 for ; Wed, 25 Sep 2013 23:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.06 X-Spam-Level: X-Spam-Status: No, score=-7.06 tagged_above=-999 required=5 tests=[AWL=1.237, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElHZ99AwfPZQ for ; Wed, 25 Sep 2013 23:03:14 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5761621F944C for ; Wed, 25 Sep 2013 23:03:12 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r8Q638jY002583 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 26 Sep 2013 09:03:10 +0300 Message-ID: <5243CE1C.3030906@helsinki.fi> Date: Thu, 26 Sep 2013 09:03:08 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> <5241243E.9020003@helsinki.fi> <524393F6.9030303@it.aoyama.ac.jp> In-Reply-To: <524393F6.9030303@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] Open letter to WG participants 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, 26 Sep 2013 06:03:19 -0000 Hello, It seems that we need to clarify the terminology we use a bit. On 26.9.2013 4:55, "Martin J. Dürst" wrote: > > Can we *please* use a terminology that isn't in conflict with the > terminology of RFC 3986 (URI spec)? > > The term 'resource' is used in RFC 3986 (and many other places) for > the stuff that is denoted by URIs (including URNs). So please change > 'resource' to something like 'server infrastructure' or so, to avoid > confusion. I was confused myself by for instance this statement by Keith which is pure 3986: > Given that there is today a huge number of network-accessible resources > that accept queries and process them, why is your assumption that this > won't be a common scenario for resources named by URNs? but then, once I had grasped that there could be two different meanings of resource here, tried to clarify that in my response. The problem I see is that resource as used in RFC 3986 can be a database (which may accept a request and process it) or an object (such a single record within that database) which has been identified by URN. Of course the URN resolvers are, in RFC 3986 terminology, resources as well. So if we stick to the RFC 3986 terminology URN is resolved by resource, and as a result 1-n URIs are processed by 1-n resources, and in the end we get the identified resource or its surrogate. Instead, like Martin suggests, we should be more precise and talk about URN resolvers, Internet servers (to which the URIs generated in the resolution process are passed) and identified resources (and their surrogates which may be identified resources as well). > > >> By definition, every URN is always processed by the appropriate URN >> resolver first. > > Not necessarily. There may be URN namespaces such as one for integers > (surely something very persistent; I seem to remember there having > been a proposal for such a thing, but I don't remember how far it > went), and resolution for them may be just built in to some of the > software that uses them. Of course you could also call this built-in > software component a resolver, but then you'd also have to call the > software/protocol/server combination that deals with http requests a > resolver. I look forward to seeing the first such namespace in real life. > >> >> >> http://linnea1.linneanet.fi:11391/voyager?version=1.1&operation=searchRetrieve&query=978-952-60-5254-0&maximumRecords=1&recordSchema=marcxml >> >> >> >> URIs like this are not persistent (and unlike RFC3986 says, they >> certainly do not identify anything ;-)). > > Of course they identify something. They identify the search request, > or the results of that request, if nothing else. I disagree, because I have a librarian's formal approach to what "identify" means. You can of course say that the URI above identifies the retrieved bibliographic record. But any change in the underlying technology will change this "identifier". An analogy from the real world: that you can claim that somebody's email address or snail mail address identifies him/her, but such identification is known to be non-persistent and unreliable (many people can live in the same addresss; same person can have many email addresses) and therefore it is not used. And libraries do not use URLs such as the one above but URNs to identify bibliographic records in their databases. I don't mind what W3C or IETF in general says about identification, but in this WG identification should be something reliable and identifiers unique and persistent, because that's what URNs are supposed to be. > > I would like to point out that in the examples above, there is no > example of an URN with a query part. In both the http://urn.fi/ > example and the http://linnea1.linneanet.fi example, the query part is > a http query part. > > Can you please make an example with query parts directly on an urn, > and show how it fits into the above picture? Sorry, I do not understand this. Unless I am mistaken the URN part is no different from the generic URI syntax query. We may/shall specify syntax (reserved keywords etc) for URN queries which will be understood by resolvers, but at least so far we have not made any deviations from the syntax specified in RFC 3986. Best regards, Juha > > Regards, Martin. > > > >> All the best, >> >> Juha >> >>> If ideas have already been put forward, then we need to call >>> them out specifically in separate email threads as the discussions on >>> this list can be quite involved. >>> >>> I hope this helps. If there are any questions, please ask. >>> >>> -andy >>> _______________________________________________ >>> urn mailing list >>> urn@ietf.org >>> https://www.ietf.org/mailman/listinfo/urn >> >> -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678