From stpeter@stpeter.im Sun Nov 3 14:36:09 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 E0F4B21E8123 for ; Sun, 3 Nov 2013 14:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 8YR3JCMi4QA4 for ; Sun, 3 Nov 2013 14:36:01 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C210021E80E9 for ; Sun, 3 Nov 2013 14:36:00 -0800 (PST) Received: from sjc-vpn7-585.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B6F024010C; Sun, 3 Nov 2013 15:35:56 -0700 (MST) Message-ID: <5276CFCB.4000108@stpeter.im> Date: Sun, 03 Nov 2013 14:35:55 -0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: John C Klensin , jehakala@mappi.helsinki.fi, 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> <5271CDD5.1020501@stpeter.im> <15DBB27F4BDA1975C9FDD985@JcK-HP8200.jck.com> In-Reply-To: <15DBB27F4BDA1975C9FDD985@JcK-HP8200.jck.com> X-Enigmail-Version: 1.6 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: Sun, 03 Nov 2013 22:36:09 -0000 On 10/31/13 7:00 AM, John C Klensin wrote: > > > --On Wednesday, October 30, 2013 21:26 -0600 Peter Saint-Andre > wrote: > >>> 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. >> >> I understand why we might want to pass queries to resolvers. >> >> I don't understand why we need to pass those queries as part >> of URNs themselves. >> >> It appears that the designers of some systems currently >> deployed have decided that passing queries in URNs is a good >> idea. As far as I can see, even though we don't know why they >> did so, this WG is essentially being asked to validate that >> decision. > > Peter, > > Perhaps stupidly, I put off trying to respond to some of the > threads until after some documents and a WG Last Call analysis > appeared and have now completely lost whatever my train of > thought was at the time. As a result, I may be missing > something that would change the comments below. But... > > First of all, I think Juha and others have given several reasons > why queries "as part of" URNs are necessary, with references > into named objects being key among them. One might be able to > meet most of those needs with fragments instead, but doing so > would essentially turn fragment identifiers into queries. > Probably that is not a good idea although I'm not sure I > understand all of the implications either way. > > More important, IMO, is a problem I would describe in terms > other than "validate that decision". There are folks who are > using URNs (or at least things they consider URNs). They have > discovered that they need queries and need queries with certain > properties. They have made it clear that they are deploying > those URNs, in several cases at very large (and growing) scale > and using them as named identifiers that are very stable with > objects that have very long expected lifetimes. > > I think that leaves the IETF with several choices: > > (1) We can say "not in _our_ URNs", which is what I read your > response above and the one to Martin as saying. Perhaps I > misunderstand your intent, but the option still exists. > > (2) We can say "the URI spec makes that idea bad news, so not in > our URNs". > > (3) We can pretend the problem doesn't exist and just approve > 2141bis and the mythical > draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07 more or less as they > exist today, without addressing queries at all. There is a > difference between this and (1), but it isn't huge. > > (4) We can work with those groups to get some appropriate query > syntax into URNs and define their syntax and semantics > appropriately. > > (5) We can explain to those groups the reasons why, if queries > are needed, they don't belong in URNs and they should be using > something else or something supplemental. If part of that > explanation requires a new URI type or a new near-URI type > (i.e., something that is conceptually URI-like but that would > not conform to RFC 3986) we'd better sketch it out and be ready > to explain why it is better than URNs-with-queries and/or why it > should or should not gradually supercede URNs. Whatever that > explanation is, the other groups need to find it persuasive, > i.e., the decision about whether it is persuasive or not is not > up to the IETF. If we take this approach and are not > persuasive, there is no difference between this choice as (1) > above. > > Now, if those other groups were some collection of loonies who > want to complement the FUSSP [1] with the Final Ultimate > Solution to the Identifier Problem (FUSIP ?), it would probably > be entirely reasonable to ignore them or, better yet, refer them > to either ICANN or groups who are thinking grand thoughts about > universal semantics. At least some of them aren't. They > include, instead, national archive and repository libraries. It > isn't hard to make a case that they know far more about > identifiers, identifier and object stability, and similar things > than the IETF does, nor to extrapolate from history that they > will be around long after the IETF has been forgotten. > > Because of that situation, I believe that choices (1), (2), or > (3) (or an unpersuasive (5)) will result in a fork in the URN > definition. Whether the non-IETF branch is formalized or not is > a separate question but, if it is not formalized by someone and > conformed to, we will likely have multiple solutions that don't > completely interoperate with each other, much less with > 2141bis-style URNs. > > That leads me to believe that we had better suck it up and > either define URN queries in some reasonable way or propose a > plausible alternative. Or we should find some body that wants > to do the work, close the WG, and turn the URN definition over > to them. Hi John, In fact, your (4) is not, to me, unreasonable -- but I haven't seen a clear story about why it's needed. I do think that I understand the concerns of those who say that using the existing URI query syntax for passing information to URN resolvers might be problematic. If we accept that reasoning, then using some other delimiter (such as '/') for the URN-query-component (whatever we call such a beast) might make sense. In your (4), do you think that we need to use the URI query syntax or do you instead think that the folks you mention above might be open to using some other syntax? Peter -- Peter Saint-Andre https://stpeter.im/ From L.Svensson@dnb.de Mon Nov 4 10:43:26 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084B511E81CE for ; Mon, 4 Nov 2013 10:43:26 -0800 (PST) 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=[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 2LILpI7FMQ6n for ; Mon, 4 Nov 2013 10:43:21 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id DE05E11E815F for ; Mon, 4 Nov 2013 10:43:20 -0800 (PST) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 04DAC7EE1F; Mon, 4 Nov 2013 19:43:19 +0100 (CET) From: "Svensson, Lars" To: Peter Saint-Andre , John C Klensin , "jehakala@mappi.helsinki.fi" , Keith Moore Thread-Topic: Re: [urn] Working Group Last Callof draft-ietf-urnbis-rfc2141bis-urn-06.txt Thread-Index: Ac7ZjbYODpModWpAT4SACJ0s3rUhzA== Date: Mon, 4 Nov 2013 18:43:18 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA43A6203@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.189] 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 Callof 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, 04 Nov 2013 18:43:26 -0000 On Monday, November 4, Peter Saint-Andre wrote: All, > On 10/31/13 7:00 AM, John C Klensin wrote: > > > > > > --On Wednesday, October 30, 2013 21:26 -0600 Peter Saint-Andre > > wrote: > > > >>> 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. > >> > >> I understand why we might want to pass queries to resolvers. If I understand Juha's arguments correctly, he considers the query not to b= e part of the URN, but rather attached to it: [[ Since query is not part of the URN, what is being identified does not chang= e. In that sense the meaning of the URN does not change. But each example a= bove would use different queries to ask the URN resolver to launch differen= t resolution services. ]] [1] My reading of this is that this would be a URN urn:example:foo but this is not a URN urn:example:foo?query=3Dgoes&here=3D! @Juha: Can you please confirm (or not) if my reading of your arguments is c= orrect? I agree with Peter (and possibly others) that queries are good for sending = information to resolvers. IMO we should handle those queries in RFC 2483bis= .=20 > >> I don't understand why we need to pass those queries as part of URNs > >> themselves.=20 I have tried to give a few examples (most of them fairly far-fetched); ther= e search-in-e-book example is probably the most interesting one [2]. That d= oes not mean that I promote queries in URNs, but only for resolution servic= es. > >> It appears that the designers of some systems currently deployed have > >> decided that passing queries in URNs is a good idea. As far as I can > >> see, even though we don't know why they did so, this WG is > >> essentially being asked to validate that decision. > > First of all, I think Juha and others have given several reasons why > > queries "as part of" URNs are necessary, with references into named > > objects being key among them. One might be able to meet most of those > > needs with fragments instead, but doing so would essentially turn > > fragment identifiers into queries. > > Probably that is not a good idea although I'm not sure I understand > > all of the implications either way. I currently only see that people pass queries to resolution services by usi= ng UIs that create an http-URI having a URN and a query in it, not that the= y actually pass queries in URNs. I'll finish with two questions to the group: Do we in the WG have consensus on where a URN ends (and thus if query and f= ragment are part of the URN or not)? Do we in the WG have consensus on if URNs (with or without queries and frag= ments) are URIs or not? Lars [1] http://www.ietf.org/mail-archive/web/urn/current/msg02010.html [2] http://www.ietf.org/mail-archive/web/urn/current/msg02094.html From juha.hakala@helsinki.fi Tue Nov 5 00:57: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 DCA8921E80BB for ; Tue, 5 Nov 2013 00:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 5aHeKz+QFBzp for ; Tue, 5 Nov 2013 00:57:38 -0800 (PST) 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 AEB1D21F9E9F for ; Tue, 5 Nov 2013 00:57:36 -0800 (PST) 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 rA58vTH2007268 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 5 Nov 2013 10:57:30 +0200 Message-ID: <5278B2F9.5030503@helsinki.fi> Date: Tue, 05 Nov 2013 10:57:29 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: "Svensson, Lars" References: <24637769D123E644A105A0AF0E1F92EFA43A6203@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA43A6203@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "jehakala@mappi.helsinki.fi" , "urn@ietf.org" , Keith Moore Subject: Re: [urn] Working Group Last Callof 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, 05 Nov 2013 08:57:44 -0000 Hello, On 4.11.2013 20:43, Svensson, Lars wrote: > If I understand Juha's arguments correctly, he considers the query not to be part of the URN, but rather attached to it: > > [[ > Since query is not part of the URN, what is being identified does not change. In that sense the meaning of the URN does not change. But each example above would use different queries to ask the URN resolver to launch different resolution services. Sorry, I was not specific enough. The idea is that the query is not part of the URN namespace specific string. > ]] [1] > > My reading of this is that this would be a URN > > urn:example:foo > > but this is not a URN > > urn:example:foo?query=goes&here=! > > @Juha: Can you please confirm (or not) if my reading of your arguments is correct? Both URIs above contain the same URN. That is, they have the same NSS (example) and NID (foo) and therefore identify the same resource. The difference between these URNs lies in the resolution process. The former resolves to whatever is the default thing supplied by the resolver which deals with the URN namespace "example", while the latter specifies a service the resolver is expected to provide. It should be noted that according to RFC 3986, the thing that the latter URN resolves to (e.g. a metadata record describing the identified resource) is identified by the URN + query. This would extend the scope of some (most?) existing URN namespaces far beyond what is acceptable and make identification process very hard to manage. > > I agree with Peter (and possibly others) that queries are good for sending information to resolvers. IMO we should handle those queries in RFC 2483bis. Fine. The work on RFC 2483bis will start in earnest once the URNBIS WG is in full agreement on how to proceed. > >>>> I don't understand why we need to pass those queries as part of URNs >>>> themselves. Because it seems that that may be the easiest way of passing service requests to resolvers. The first URN WG could not consider that option because back then the URI generic syntax did not specify query. Now that the specification is in place, we should use it if and when possible. And we must in any case tell how query and fragment are to be understood in the URN context, since the RFC 3986 approach is not palatable for most URN namespaces. > I have tried to give a few examples (most of them fairly far-fetched); there search-in-e-book example is probably the most interesting one [2]. That does not mean that I promote queries in URNs, but only for resolution services. > >>>> It appears that the designers of some systems currently deployed have >>>> decided that passing queries in URNs is a good idea. As far as I can >>>> see, even though we don't know why they did so, this WG is >>>> essentially being asked to validate that decision. I do not agree with this view. Most URN resolvers do not support queries. I do not know any applications which do (but Lars seems to be familiar with some; see below) Most implementers are waiting for the new URN syntax and related documentation (such as RFC 2483bis) to tell them exactly how to proceed. Some PIDs (most notably ARK) have developed their own, non-RFC 3986 compliant ways of passing service requests to resolvers. Although one may argue that this is OK (since ARK resolver will know how to deal with "?" or "??" in the end of the ARK identifier) my gut feeling is that solutions such as these should be avoided if the same thing can be done using the plain vanilla URI syntax. If in some distant future ARKs have to be resolved by e.g. URN resolvers non-standard syntactical features may become a pain in the neck. The challenge URN implementers are facing is that there are more and more resolution services that could / should be supported, but the existing means for specifying services (RFC 2483) and mechanisms for passing them to resolvers (DDDS) do not meet the requirements. Since the implementations of DDDS are for some reason few and far between, we need something that should be easier to implement (and could be used by other PIDs as well). If the WG does not provide any quidelines for the use of query of even excludes it from the URN syntax, there is a risk that people start using them in any case. This will inevitably lead to interoperability problems and duplication of effort. IMO ARK is a good example of what will happen if we fail to tell the implementers what to do with the query. >>> First of all, I think Juha and others have given several reasons why >>> queries "as part of" URNs are necessary, with references into named >>> objects being key among them. One might be able to meet most of those >>> needs with fragments instead, but doing so would essentially turn >>> fragment identifiers into queries. Yes, and that is something I definitely don't want to do. URN fragments should not be functionally any different from URI fragments. Otherwise there is of course the difference that from URN point of view, fragment does not identify anything, it just pinpoints a location within the document identified by the URN. >>> Probably that is not a good idea although I'm not sure I understand >>> all of the implications either way. > I currently only see that people pass queries to resolution services by using UIs that create an http-URI having a URN and a query in it, not that they actually pass queries in URNs. Lars, can you give me examples of these resolvers? The functionality you describe above is exactly what we have in mind in e.g. my library. What is missing is the specifications of services, service parameters and syntax in which to express them as a query. Existing implementations, although premature, might give an idea of what works and perhaps also of what does not. > > I'll finish with two questions to the group: > > Do we in the WG have consensus on where a URN ends (and thus if query and fragment are part of the URN or not)? Neither fragment nor query should part of the NID. So if we say that URNs consist of "urn:", NSS and NID, then fragment and query are not part of the URN, although they are part of the HTTP URI which is resolved. However, since the WG intends to provide quidelines on how to construct queries, I prefer a solution (which is at least implicitly embedded into the current RFC 2141bis) where query and fragment are seen as part of the URN, although they do not have a role in identification. > Do we in the WG have consensus on if URNs (with or without queries and fragments) are URIs or not? URNs are definitely URIs and therefore should follow the letter (syntax) if not the spirit (semantics) of RFC 3986. Juha PS. Lars noted 24.9 that: > In my opinion we also do not have consensus on the allowed/reserved characters, particularly ~, / and &. Correct. Initially I thought that we may reserve all these characters in NIDs. But a colleague told me that he is involved with a project which wants to use / in NID and does not want to percent encode the character. If we allow /, should we then allow also & and ~? > > Lars > > [1] http://www.ietf.org/mail-archive/web/urn/current/msg02010.html > [2] http://www.ietf.org/mail-archive/web/urn/current/msg02094.html -- 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 Nov 5 03:21: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 AD72E11E8283 for ; Tue, 5 Nov 2013 03:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.249 X-Spam-Level: X-Spam-Status: No, score=-11.249 tagged_above=-999 required=5 tests=[AWL=1.000, 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 8Tx8HWtH2HW0 for ; Tue, 5 Nov 2013 03:21:12 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id BFD3811E827D for ; Tue, 5 Nov 2013 03:21:09 -0800 (PST) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 44CB77EE07; Tue, 5 Nov 2013 12:21:09 +0100 (CET) From: "Svensson, Lars" To: Juha Hakala Thread-Topic: Re: AW: Re: [urn] Working Group Last Callof draft-ietf-urnbis-rfc2141bis-urn-06.txt Thread-Index: Ac7aGRlKYkX3Ja4ZR2SpyB37r5RdEg== Date: Tue, 5 Nov 2013 11:21:09 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA43A656C@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.123] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jehakala@mappi.helsinki.fi" , "urn@ietf.org" , Keith Moore Subject: Re: [urn] Working Group Last Callof 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, 05 Nov 2013 11:21:16 -0000 Juha, Thanks for your clarifications. =20 > On 4.11.2013 20:43, Svensson, Lars wrote: > > If I understand Juha's arguments correctly, he considers the query not = to > be part of the URN, but rather attached to it: > > > > [[ > > Since query is not part of the URN, what is being identified does not > change. In that sense the meaning of the URN does not change. But each > example above would use different queries to ask the URN resolver to > launch different resolution services. > Sorry, I was not specific enough. The idea is that the query is not part = of the > URN namespace specific string. > > ]] [1] > > > > My reading of this is that this would be a URN > > > > urn:example:foo > > > > but this is not a URN > > > > urn:example:foo?query=3Dgoes&here=3D! > > > > @Juha: Can you please confirm (or not) if my reading of your arguments = is > correct? > Both URIs above contain the same URN. That is, they have the same NSS > (example) and NID (foo) and therefore identify the same resource. The > difference between these URNs lies in the resolution process. The former > resolves to whatever is the default thing supplied by the resolver which = deals > with the URN namespace "example", while the latter specifies a service th= e > resolver is expected to provide. My reading of your answer is that a urn starts with 'urn' and ends with the= character before the first '?', the first '#' or with the end of the strin= g, whichever comes first. Is my understanding of your position correct? The= reason I keep asking is that I need to understand where the URN starts and= where it ends. In my opinion we should not discuss syntactic elements for = URNs that are not part of the URN itself. So if query and fragment are not = part of the URN (i. e. URN + query !=3D URN), we should leave them out of R= FC 2141bis.=20 > It should be noted that according to RFC 3986, the thing that the latter = URN > resolves to (e.g. a metadata record describing the identified > resource) is identified by the URN + query. This would extend the scope o= f > some (most?) existing URN namespaces far beyond what is acceptable and > make identification process very hard to manage. Yes, and that is why it might be a better idea not to allow queries in URN = syntax. If we agree that they make sense for resolution services but not in= other contexts, we should not allow them in URNs (i. e. in RFC 2141bis) bu= t only specify them for resolution services (RFC 2483bis). > > I agree with Peter (and possibly others) that queries are good for send= ing > information to resolvers. IMO we should handle those queries in RFC > 2483bis. > Fine. The work on RFC 2483bis will start in earnest once the URNBIS WG is= in > full agreement on how to proceed. So here we seem to agree. > >>>> I don't understand why we need to pass those queries as part of > >>>> URNs themselves. > Because it seems that that may be the easiest way of passing service > requests to resolvers. The first URN WG could not consider that option > because back then the URI generic syntax did not specify query. Now that > the specification is in place, we should use it if and when possible. > And we must in any case tell how query and fragment are to be understood > in the URN context, since the RFC 3986 approach is not palatable for most > URN namespaces. What I don't understand is why I need to attach the query to the URN per se= . I add the query when I send a resolution request to the resolver, and the= n I add it to the resolution request, not to the URN. Or put differently: W= hen I want to resolve a URN, I have three parts to consider: 1) the resolution service, available at some address 2) the URN I want to resolve 3) further information targeted at the resolution service (e.g. preferred m= etadata format, only MD5 hash, etc.). IMO 3) could (should?) be put into a query, but again, I send that query to= the resolver, not to the resource identified by the URN. Thus the query ha= s nothing to do with URNs but only with resolution services (I'm repeating = myself...). > >>>> It appears that the designers of some systems currently deployed > >>>> have decided that passing queries in URNs is a good idea. As far as > >>>> I can see, even though we don't know why they did so, this WG is > >>>> essentially being asked to validate that decision. > I do not agree with this view. Most URN resolvers do not support queries.= I > do not know any applications which do (but Lars seems to be familiar with > some; see below) Most implementers are waiting for the new URN syntax > and related documentation (such as RFC 2483bis) to tell them exactly how = to > proceed. >=20 > Some PIDs (most notably ARK) have developed their own, non-RFC 3986 > compliant ways of passing service requests to resolvers. Although one may > argue that this is OK (since ARK resolver will know how to deal with "?" = or > "??" in the end of the ARK identifier) my gut feeling is that solutions s= uch as > these should be avoided if the same thing can be done using the plain van= illa > URI syntax. If in some distant future ARKs have to be resolved by e.g. UR= N > resolvers non-standard syntactical features may become a pain in the neck= . >=20 > The challenge URN implementers are facing is that there are more and more > resolution services that could / should be supported, but the existing me= ans > for specifying services (RFC 2483) and mechanisms for passing them to > resolvers (DDDS) do not meet the requirements. Since the implementations > of DDDS are for some reason few and far between, we need something that > should be easier to implement (and could be used by other PIDs as well). >=20 > If the WG does not provide any quidelines for the use of query of even > excludes it from the URN syntax, there is a risk that people start using = them > in any case. This will inevitably lead to interoperability problems and > duplication of effort. IMO ARK is a good example of what will happen if w= e > fail to tell the implementers what to do with the query. Again, those are queries targeted at resolution services and should be hand= led in RFC 2483bis. >=20 > >>> First of all, I think Juha and others have given several reasons why > >>> queries "as part of" URNs are necessary, with references into named > >>> objects being key among them. One might be able to meet most of > >>> those needs with fragments instead, but doing so would essentially > >>> turn fragment identifiers into queries. > Yes, and that is something I definitely don't want to do. URN fragments > should not be functionally any different from URI fragments. Otherwise > there is of course the difference that from URN point of view, fragment d= oes > not identify anything, it just pinpoints a location within the document > identified by the URN. Just in order to keep terminology aligned: "it just pinpoints a location wi= thin the *resource* identified by the URN." > >>> Probably that is not a good idea although I'm not sure I understand > >>> all of the implications either way. > > I currently only see that people pass queries to resolution services by= using > UIs that create an http-URI having a URN and a query in it, not that they > actually pass queries in URNs. > Lars, can you give me examples of these resolvers? The functionality you > describe above is exactly what we have in mind in e.g. my library. What i= s > missing is the specifications of services, service parameters and syntax = in > which to express them as a query. Existing implementations, although > premature, might give an idea of what works and perhaps also of what does > not. I don't have working examples and my wording was grubby. What I intended to= say was that what I see is that people want to pass queries to resolution = services and that they don't want to query the identified resource. When implementing the German URN-NBN resolver [1], we chose to make a work-= around to address fragments in resources [2], since the syntax doesn't allo= w it. > > I'll finish with two questions to the group: > > > > Do we in the WG have consensus on where a URN ends (and thus if query > and fragment are part of the URN or not)? > Neither fragment nor query should part of the NID. So if we say that URNs > consist of "urn:", NSS and NID, then fragment and query are not part of t= he > URN, although they are part of the HTTP URI which is resolved. >=20 > However, since the WG intends to provide quidelines on how to construct > queries, I prefer a solution (which is at least implicitly embedded into = the > current RFC 2141bis) where query and fragment are seen as part of the URN= , > although they do not have a role in identification. >=20 > > Do we in the WG have consensus on if URNs (with or without queries and > fragments) are URIs or not? > URNs are definitely URIs and therefore should follow the letter (syntax) = if > not the spirit (semantics) of RFC 3986. OK, thanks for your response. > Juha >=20 > PS. Lars noted 24.9 that: >=20 > > In my opinion we also do not have consensus on the allowed/reserved > characters, particularly ~, / and &. > Correct. Initially I thought that we may reserve all these characters in = NIDs. > But a colleague told me that he is involved with a project which wants to= use > / in NID and does not want to percent encode the character. If we allow = /, > should we then allow also & and ~? Yes, this is another open question... [1] http://nbn-resolving.org/ [2] http://nbn-resolving.org/examples Best, Lars=20 From prvs=00228850d4=bengt.neiss@kb.se Wed Nov 6 05:26: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 A046521F9DBE for ; Wed, 6 Nov 2013 05:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35] 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 yg9wSqdQO5gi for ; Wed, 6 Nov 2013 05:26:46 -0800 (PST) Received: from mspkb001.kb.se (mspkb001.kb.se [193.10.12.10]) by ietfa.amsl.com (Postfix) with ESMTP id C2DFF21F9DBD for ; Wed, 6 Nov 2013 05:26:45 -0800 (PST) From: Bengt Neiss To: "Svensson, Lars" , Juha Hakala Thread-Topic: [urn] Working Group Last Callof draft-ietf-urnbis-rfc2141bis-urn-06.txt Thread-Index: Ac7aGRlKYkX3Ja4ZR2SpyB37r5RdEgA2hE/w Date: Wed, 6 Nov 2013 13:26:42 +0000 Message-ID: References: <24637769D123E644A105A0AF0E1F92EFA43A656C@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA43A656C@dnbf-ex1.AD.DDB.DE> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Cc: "jehakala@mappi.helsinki.fi" , "urn@ietf.org" , Keith Moore Subject: Re: [urn] Working Group Last Callof 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, 06 Nov 2013 13:26:50 -0000 Hello all, > -----Ursprungligt meddelande----- > Fr=E5n: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] F=F6r Svensson= , > Lars > Skickat: den 5 november 2013 12:21 > Till: Juha Hakala > Kopia: jehakala@mappi.helsinki.fi; urn@ietf.org; Keith Moore > =C4mne: Re: [urn] Working Group Last Callof draft-ietf-urnbis-rfc2141bis-= urn- > 06.txt >=20 > Juha, >=20 > Thanks for your clarifications. >=20 > > On 4.11.2013 20:43, Svensson, Lars wrote: > > > If I understand Juha's arguments correctly, he considers the query > > > not to > > be part of the URN, but rather attached to it: > > > > > > [[ > > > Since query is not part of the URN, what is being identified does > > > not > > change. In that sense the meaning of the URN does not change. But each > > example above would use different queries to ask the URN resolver to > > launch different resolution services. > > Sorry, I was not specific enough. The idea is that the query is not > > part of the URN namespace specific string. > > > ]] [1] > > > > > > My reading of this is that this would be a URN > > > > > > urn:example:foo > > > > > > but this is not a URN > > > > > > urn:example:foo?query=3Dgoes&here=3D! > > > > > > @Juha: Can you please confirm (or not) if my reading of your > > > arguments is > > correct? >=20 > > Both URIs above contain the same URN. That is, they have the same NSS > > (example) and NID (foo) and therefore identify the same resource. The > > difference between these URNs lies in the resolution process. The > > former resolves to whatever is the default thing supplied by the > > resolver which deals with the URN namespace "example", while the > > latter specifies a service the resolver is expected to provide. >=20 > My reading of your answer is that a urn starts with 'urn' and ends with t= he > character before the first '?', the first '#' or with the end of the stri= ng, > whichever comes first. Is my understanding of your position correct? The > reason I keep asking is that I need to understand where the URN starts an= d > where it ends. In my opinion we should not discuss syntactic elements for > URNs that are not part of the URN itself. So if query and fragment are no= t > part of the URN (i. e. URN + query !=3D URN), we should leave them out of= RFC > 2141bis. As the text in draft-ietf-urnbis-rfc2141bis-urn-06 is written it defines a = urn as " assigned-name =3D "urn" ":" NID ":" NSS " and " namestring =3D= assigned-name [ "?" query ] [ "#" fragment ] " As I understand it a URN corresponds to the "assigned name" and query and = fragment are not part of the URN. >=20 > > It should be noted that according to RFC 3986, the thing that the > > latter URN resolves to (e.g. a metadata record describing the > > identified > > resource) is identified by the URN + query. This would extend the > > scope of some (most?) existing URN namespaces far beyond what is > > acceptable and make identification process very hard to manage. >=20 > Yes, and that is why it might be a better idea not to allow queries in UR= N > syntax. If we agree that they make sense for resolution services but not = in > other contexts, we should not allow them in URNs (i. e. in RFC 2141bis) b= ut > only specify them for resolution services (RFC 2483bis). >=20 > > > I agree with Peter (and possibly others) that queries are good for > > > sending > > information to resolvers. IMO we should handle those queries in RFC > > 2483bis. > > Fine. The work on RFC 2483bis will start in earnest once the URNBIS WG > > is in full agreement on how to proceed. >=20 > So here we seem to agree. I agree. >=20 > > >>>> I don't understand why we need to pass those queries as part of > > >>>> URNs themselves. > > Because it seems that that may be the easiest way of passing service > > requests to resolvers. The first URN WG could not consider that option > > because back then the URI generic syntax did not specify query. Now > > that the specification is in place, we should use it if and when possib= le. > > And we must in any case tell how query and fragment are to be > > understood in the URN context, since the RFC 3986 approach is not > > palatable for most URN namespaces. >=20 > What I don't understand is why I need to attach the query to the URN per = se. > I add the query when I send a resolution request to the resolver, and the= n I > add it to the resolution request, not to the URN. Or put differently: Whe= n I > want to resolve a URN, I have three parts to consider: > 1) the resolution service, available at some address > 2) the URN I want to resolve > 3) further information targeted at the resolution service (e.g. preferred > metadata format, only MD5 hash, etc.). >=20 > IMO 3) could (should?) be put into a query, but again, I send that query = to > the resolver, not to the resource identified by the URN. Thus the query h= as > nothing to do with URNs but only with resolution services (I'm repeating > myself...). I guess this depends on what we consider to be a resource. For us (and our use cases), working at a national library, it is quite obvi= ous (I guess) for what we consider to be a resource.=20 For others a resource might be a something totally different where a query = sent to the resource might make sense.=20 But for me I agree Query is sent to the resolver, not the resource, so no need to attach the q= uery to the URN per se. >=20 > > >>>> It appears that the designers of some systems currently deployed > > >>>> have decided that passing queries in URNs is a good idea. As far > > >>>> as I can see, even though we don't know why they did so, this WG > > >>>> is essentially being asked to validate that decision. > > I do not agree with this view. Most URN resolvers do not support > > queries. I do not know any applications which do (but Lars seems to be > > familiar with some; see below) Most implementers are waiting for the > > new URN syntax and related documentation (such as RFC 2483bis) to tell > > them exactly how to proceed. > > > > Some PIDs (most notably ARK) have developed their own, non-RFC 3986 > > compliant ways of passing service requests to resolvers. Although one > > may argue that this is OK (since ARK resolver will know how to deal > > with "?" or "??" in the end of the ARK identifier) my gut feeling is > > that solutions such as these should be avoided if the same thing can > > be done using the plain vanilla URI syntax. If in some distant future > > ARKs have to be resolved by e.g. URN resolvers non-standard syntactical > features may become a pain in the neck. > > > > The challenge URN implementers are facing is that there are more and > > more resolution services that could / should be supported, but the > > existing means for specifying services (RFC 2483) and mechanisms for > > passing them to resolvers (DDDS) do not meet the requirements. Since > > the implementations of DDDS are for some reason few and far between, > > we need something that should be easier to implement (and could be used > by other PIDs as well). > > > > If the WG does not provide any quidelines for the use of query of even > > excludes it from the URN syntax, there is a risk that people start > > using them in any case. This will inevitably lead to interoperability > > problems and duplication of effort. IMO ARK is a good example of what > > will happen if we fail to tell the implementers what to do with the que= ry. >=20 > Again, those are queries targeted at resolution services and should be > handled in RFC 2483bis. The text in draft-ietf-urnbis-rfc2141bis-urn-06 section 4.3 (Query Componen= t and Fragment Identifier Component) already gives some directions on where= guidelines can be found (refers the question to, for example RFC 2483bis, = as I understand it).=20 Is the concern that this is not enough and that the text should be more exp= licit about it? >=20 > > > > >>> First of all, I think Juha and others have given several reasons > > >>> why queries "as part of" URNs are necessary, with references into > > >>> named objects being key among them. One might be able to meet > > >>> most of those needs with fragments instead, but doing so would > > >>> essentially turn fragment identifiers into queries. > > Yes, and that is something I definitely don't want to do. URN > > fragments should not be functionally any different from URI fragments. > > Otherwise there is of course the difference that from URN point of > > view, fragment does not identify anything, it just pinpoints a > > location within the document identified by the URN. >=20 > Just in order to keep terminology aligned: "it just pinpoints a location = within > the *resource* identified by the URN." >=20 > > >>> Probably that is not a good idea although I'm not sure I > > >>> understand all of the implications either way. > > > I currently only see that people pass queries to resolution services > > > by using > > UIs that create an http-URI having a URN and a query in it, not that > > they actually pass queries in URNs. > > Lars, can you give me examples of these resolvers? The functionality > > you describe above is exactly what we have in mind in e.g. my library. > > What is missing is the specifications of services, service parameters > > and syntax in which to express them as a query. Existing > > implementations, although premature, might give an idea of what works > > and perhaps also of what does not. >=20 > I don't have working examples and my wording was grubby. What I intended > to say was that what I see is that people want to pass queries to resolut= ion > services and that they don't want to query the identified resource. >=20 > When implementing the German URN-NBN resolver [1], we chose to make a > work-around to address fragments in resources [2], since the syntax doesn= 't > allow it. >=20 > > > I'll finish with two questions to the group: > > > > > > Do we in the WG have consensus on where a URN ends (and thus if > > > query > > and fragment are part of the URN or not)? >=20 > > Neither fragment nor query should part of the NID. So if we say that > > URNs consist of "urn:", NSS and NID, then fragment and query are not > > part of the URN, although they are part of the HTTP URI which is resolv= ed. > > > > However, since the WG intends to provide quidelines on how to > > construct queries, I prefer a solution (which is at least implicitly > > embedded into the current RFC 2141bis) where query and fragment are > > seen as part of the URN, although they do not have a role in identifica= tion. > > > > > Do we in the WG have consensus on if URNs (with or without queries > > > and > > fragments) are URIs or not? > > URNs are definitely URIs and therefore should follow the letter > > (syntax) if not the spirit (semantics) of RFC 3986. >=20 > OK, thanks for your response. >=20 > > Juha > > > > PS. Lars noted 24.9 that: > > > > > In my opinion we also do not have consensus on the allowed/reserved > > characters, particularly ~, / and &. > > Correct. Initially I thought that we may reserve all these characters i= n NIDs. > > But a colleague told me that he is involved with a project which wants > > to use / in NID and does not want to percent encode the character. If > > we allow /, should we then allow also & and ~? >=20 > Yes, this is another open question... >=20 > [1] http://nbn-resolving.org/ > [2] http://nbn-resolving.org/examples >=20 All the best, //Bengt From L.Svensson@dnb.de Wed Nov 6 07:33: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 7180511E8150 for ; Wed, 6 Nov 2013 07:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.749 X-Spam-Level: X-Spam-Status: No, score=-10.749 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 38BHji01z7rQ for ; Wed, 6 Nov 2013 07:33:01 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF7021E80DF for ; Wed, 6 Nov 2013 07:33:00 -0800 (PST) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 1D6FE7EDF6 for ; Wed, 6 Nov 2013 16:33:00 +0100 (CET) From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: SV: [urn] Working Group Last Callof draft-ietf-urnbis-rfc2141bis-urn-06.txt Thread-Index: Ac7bBXgXIW2+YaXdRFu9DHHv3zVLkA== Date: Wed, 6 Nov 2013 15:32:58 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA43A6F29@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.195] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [urn] Working Group Last Callof 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, 06 Nov 2013 15:33:05 -0000 All (trimming the recipient list), Bengt wrote:=20 > The text in draft-ietf-urnbis-rfc2141bis-urn-06 section 4.3 (Query Compon= ent > and Fragment Identifier Component) already gives some directions on where > guidelines can be found (refers the question to, for example RFC 2483bis,= as I > understand it). > Is the concern that this is not enough and that the text should be more > explicit about it? My concern is that if we don't have any cases where the query is sent direc= tly to the resource identified by the URN, we should either 1) leave queries out of URNs, or 2) explain very carefully to the readers of the specification what is the d= ifference between queries in URNs (i. e. queries sent to the resource ident= ified by the URN) and queries sent to resolvers. And then we need a way to = differentiate between the two, should we have cases where a URN with a quer= y is sent to a resolver and we use another query to send information to the= resolver. Best, Lars ***Lesen. H=F6ren. Wissen. Deutsche Nationalbibliothek*** ***Reading. Listening. Understanding. German National Library*** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de From juha.hakala@helsinki.fi Fri Nov 8 02:24:39 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D1221E80AE for ; Fri, 8 Nov 2013 02:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 n6gTeJl3q96z for ; Fri, 8 Nov 2013 02:24:33 -0800 (PST) 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 E5D0A21E80AA for ; Fri, 8 Nov 2013 02:24:31 -0800 (PST) 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 rA8AOSZN002645 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 8 Nov 2013 12:24:29 +0200 Message-ID: <527CBBDC.3010904@helsinki.fi> Date: Fri, 08 Nov 2013 12:24:28 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EFA43A6F29@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA43A6F29@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [urn] Working Group Last Callof 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, 08 Nov 2013 10:24:39 -0000 Hello, I am not sure if it is a good idea to indicate ("hard-code") in a query whether the query should be processed by the URN resolver or the resource. It might be best to leave the decision to the resolver, since they should know what the best option is. Let us assume that the human end user wants descriptive metadata about the identified resource, in order to make sure that what he will get exactly what he wants. The URN resolver must know at least one resource which is capable of supplying the requested service. This service might be for instance a bibliographic database which supports SRU query. The resolver must know the search protocol, and it must be capable of transforming the URN + query into appropriate SRU search request. Following a software update in the bibliographic database, it might become possible to pass the URN + query as such to the database. Then there would be no need to anything to the query in the resolver and the URN can be passed as such to the resource. The URN resolver might know of 1-n resources which may provide the requested service. These resources may differ from another in that some may prefer the URN as such, while others may support other approaches, such as receiving SRU search requests. Letting the user to specify where the query is to be processed might also be counterproductive if the user makes the wrong choice; that is, demanding for instance that the resolver passes the URN + query to resource which cannot deal with URNs (but does support 1-n interfaces that would do). To make things clear to the implementers, RFC 2483bis could explain that normally URN resolvers will decide whether to pass queries on as such or to turn them into something else before passing the request on to the resource. The end users should not even need to know where their requests are processed; all they care about is that they get what they are asking for. Best regards, Juha On 6.11.2013 17:32, Svensson, Lars wrote: > All (trimming the recipient list), > > Bengt wrote: > >> The text in draft-ietf-urnbis-rfc2141bis-urn-06 section 4.3 (Query Component >> and Fragment Identifier Component) already gives some directions on where >> guidelines can be found (refers the question to, for example RFC 2483bis, as I >> understand it). >> Is the concern that this is not enough and that the text should be more >> explicit about it? > My concern is that if we don't have any cases where the query is sent directly to the resource identified by the URN, we should either > 1) leave queries out of URNs, or > 2) explain very carefully to the readers of the specification what is the difference between queries in URNs (i. e. queries sent to the resource identified by the URN) and queries sent to resolvers. And then we need a way to differentiate between the two, should we have cases where a URN with a query is sent to a resolver and we use another query to send information to the resolver. > > Best, > > Lars > > ***Lesen. Hören. Wissen. Deutsche Nationalbibliothek*** > ***Reading. Listening. Understanding. German National Library*** > -- 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 Fri Nov 8 07:25:46 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D85121E8193 for ; Fri, 8 Nov 2013 07:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156, 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 hGScmE4kJAsB for ; Fri, 8 Nov 2013 07:25:35 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDB721E819C for ; Fri, 8 Nov 2013 07:25:34 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VenwC-000HeB-UB; Fri, 08 Nov 2013 10:25:33 -0500 Date: Fri, 08 Nov 2013 10:25:32 -0500 From: John C Klensin To: Juha Hakala , urn@ietf.org Message-ID: <038FA310EC49A589FEA82B24@JCK-EEE10> In-Reply-To: <527CBBDC.3010904@helsinki.fi> References: <24637769D123E644A105A0AF0E1F92EFA43A6F29@dnbf-ex1.AD.DDB.DE> <527CBBDC.3010904@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] Names and operatiions on named objects (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: Fri, 08 Nov 2013 15:25:47 -0000 --On Friday, 08 November, 2013 12:24 +0200 Juha Hakala wrote: > Hello, > > I am not sure if it is a good idea to indicate ("hard-code") > in a query whether the query should be processed by the URN > resolver or the resource. It might be best to leave the > decision to the resolver, since they should know what the best > option is. Let me suggest putting that question aside for the moment and concentrating on what the actual requirement might be. > Let us assume that the human end user wants descriptive > metadata about the identified resource, in order to make sure > that what he will get exactly what he wants. After some discussion in Vancouver but with the understanding that the confusion that follows is strictly mine, when I read the above and the rest of the note, I'd like to ask some fundamental questions about whether we can understand each other and our terminology sufficiently to carry on a discussion. And I'd like to do that without getting too much tied up in the history of URNs and URIs. I apologize for the length of this. In some respects, I'm trying to re-derive the theory of URNs. If I've succeeded (I doubt that I have), a version of the contents of this note might belong in an informational document somewhere. Can we agree about the following? URNs, just about by definition and without the details, are supposed to provide names for objects, either directly or by incorporating and using other identifiers for the objects. ISBN, ISSN, and DOI URNs are examples of the latter. We don't have URNs for classification system values (e.g., Dewey or LC identifiers) because those are more like locators than about names of objects. Or perhaps they are something else -- I think that one thing that has gotten several of us confused is that we have divided the resource-reference world into "locators" and "identifiers" and that there really are other categories (as the original URI model anticipated). The notion of naming an information-containing object is obviously centuries old. Books and even some scrolls and tablets have had titles (sometimes formal, sometimes not) nearly forever. Modern names (perhaps more properly "identifiers") have developed to clear up "same thing" ambiguities and controversies by binding the identifier not only to an object but to an axiomatic set of conventions about "sameness" and/or a per-object registration procedure. Now, where the original URN definition may have been inadequate is that it sort of assumed that named objects were atomic. A URN that identifies the content of a web page, independent of where the pages is located, is fine. But, when the named objects get large and complicated one needs to recognize that subsidiary identifiers of document structure are needs. Again, this is nothing new: RFC 2026, Section 4.1 The Art of Computer Programming, Chapter 2 are examples of resource identifiers that we use all the time, but that the original URN model doesn't handle well unless we assign names to chapters or sections as well as to the whole work, and that causes other problems. Are we all together this far? If we are not, I think we have either terminology or conceptual problems so basic that I need someone to explain them to me. Now, using a functional notation that is deliberately different from the URN/URI form, we can say * name(Art of Computer Programming) But get what is, at the level of precise object or resource identifiers, an ambiguous or multiple answer because there are edition and volume issues when that function is evaluated. Those edition issues (at least) raise issues with what we have called stability, but, in this case, they are a lot more about uniqueness. Whether that is a problem of not depends on why we would want to use the function. ISBN(Art of Computer Programming, Volume 1, 1968) The hypothetical function yields "ISBN 0-201-03801-3", and is unambiguous and stable. ISBN(Art of Computer Programming, Volume 1, 1968, Chapter 2) This function evaluation probably fails, not because there is anything wrong with the object-reference but because ISBNs just don't do that. On the other hand, since functions that return ISBNs aren't ISBNs, one could define an ISBN-returning function, ISBNvar, s.t., ISBNvar(Art of Computer Programming, Volume 1, 1968, Chapter 2) Might then return "ISBN 0-201-03801-3; Chapter 2". That is _not_ an ISBN; it is something that an ISBN dereferencer/ processor that returns parts of books might be able to do something with. But that dereferencer isn't the "name" of the chapter, it is a function that works on it. So ISBNvar is a function that is applied to an object and that yields a particular type of identifier (an identifier that cannot be stated as part of an RFC 2141-3406-3187 URN). If one had a book-retriever function s.t., book-retriever(adequately-unique-book-id) Handed back the book, that would be really useful. It doesn't make much difference to that conceptual definition whether exec(book-retriever(adequately-unique-book-id)) is performed by a human or a machine, the point is that one applies a function to a book identifier and gets the book back. And, again, this basic function is centuries old. The function is also not a candidate for a URN [namespace] because it doesn't name something, it retrieves a named object. For completeness and assuming the ability to deal with nested functions, book-retriever("ISBN 0-201-03801-3") and book-retriever(ISBN(Art of Computer Programming, Volume 1, 1968)) are equivalent. If one defined "book-retriever" appropriately, book-retriever(ISBNvar(Art of Computer Programming, Volume 1, 1968, Chapter 2)) would be fine too -- the book-retriever function just over-retrieves a bit and no one thinks about it. But now let's assume that the library is modern, does print-on-demand, and has sorted out all the copyright and other issues. The new function, book-facsimile-retriever, returns different things when applied to ISBNvar when that is applied to strings with and without chapter identifiers for all of the obvious economic and resource reasons. Ok so far? If I have this right, at least some of our discussion isn't actually about URNs or even URN defererencing. We have a clear issue as to whether URN namespace and syntax that would allow an equivalent of ISBNvar to be expressed (my own impression from the above and discussions on the list is a pretty clear "yes"). But choices of functions that can be applied to a given URN (e.g., between "book-retriever" and "book-facsimile-retriever" above) is not a URN problem. That choice also implies that we'd best be careful when we think about systems for finding functions that can be applied to a particular URN namespace to retrieve or otherwise process objects because there can be several such functions that are appropriate under different circumstances (as well as zero for some namespaces). I'm reasonably sure about all of the above. Of course, I could be completely wrong. If I am, can we have the discussion in the above terms rather than getting tied up with what is or is not a URN and how they are organized, compared, etc. Those are important questions, but I think we need to be sure we are all talking about the same thing before we try to answer them. In particular, I think different people are using "URN resolver" in a number of different ways and that is contributing to our confusion (and some of us being bewildered by what others appear to be saying). That brings me back to Juha's note because, at least if the above reasoning is correct, retrieval of metadata about a named object is no more part of the name, or functions that act on an object to name it, than book-retrieval is. In other words, a function like: metadata-retriever(name, attributes) Makes perfectly good sense, even if "name" actually makes the function metadata-retriever(ISBNvar(Art of Computer Programming, Volume 1, 1968, Chapter 2), "page-count", "publisher", ...) Which would return some number and "Addison-Wesley". In the same context, one might have: metadata-search((ISBNvar), "page-count", "publisher") or, if someone could design the relevant abstractions (not our problem, fortunately) ISBNvar(metadata-search("page-count", "publisher")) Which would return a number of names in whatever format ISBNvar returned. Coming back to Juha's note and stressing that I'm not disagreeing, I'm just trying to be sure that we are all talking about the same thing. > The URN resolver must know at least one resource which is > capable of supplying the requested service. This service might > be for instance a bibliographic database which supports SRU > query. The resolver must know the search protocol, and it must > be capable of transforming the URN + query into appropriate > SRU search request. This, along with the closely-related notion of just typing a URN into a web browser where a URL might otherwise go, is what I keep having trouble getting my head around. A [generic] "URL resolver" works because a URL doesn't specify a location at all. Instead, it specifies a method and data for that method. As such, a "URL resolver" isn't a resolver, it is what some computer science disciplines would call a "method dispatcher". If I'm right, a "URN resolver" is a function (or member of a set of functions) that might reasonably be applied to a name with a namespace-specific domain. That might make a database or registry of functions that work on the names in a particular namespace an interesting thing to have (or not), but that one can't have a universal URN resolver because its inputs would have to be not just the name but a method-like statement about what one wanted to do with that name or the associated object, if any... and those are not the same thing. > > Following a software update in the bibliographic database, it > might become possible to pass the URN + query as such to the > database. Then there would be no need to anything to the query > in the resolver and the URN can be passed as such to the > resource. I'm confused about this too, partially because, as someone who used to work in databases, I'm used to phrases like "pass [something] to the database" being the worst kind of handwaving. I think the above use may be too, but I'm not sure what is actually intended. I know what it means to apply a function to a database because I then know how to determine whether that function and its arguments are actually well-specified. f(name, query) over a particular database (or f((database), name, query) don't bother me at all, but I hope you see where this is going. >... > Letting the user to specify where the query is to be processed > might also be counterproductive if the user makes the wrong > choice; that is, demanding for instance that the resolver > passes the URN + query to resource which cannot deal with URNs > (but does support 1-n interfaces that would do). See the "chapter" and "book-retriever" discussions above. > To make things clear to the implementers, RFC 2483bis could > explain that normally URN resolvers will decide whether to > pass queries on as such or to turn them into something else > before passing the request on to the resource. The end users > should not even need to know where their requests are > processed; all they care about is that they get what they are > asking for. I think the latter is very important, but the "URN resolver" postulated above seems to require a component of magic. best regards, john From juha.hakala@helsinki.fi Wed Nov 13 05:56: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 BA8C121E813A for ; Wed, 13 Nov 2013 05:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[AWL=-3.379, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, 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 OIFiZzcgTorN for ; Wed, 13 Nov 2013 05:55:55 -0800 (PST) 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 E01E721E8105 for ; Wed, 13 Nov 2013 05:55:48 -0800 (PST) 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 rADDti5m007651 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 13 Nov 2013 15:55:46 +0200 Message-ID: <528384E0.5080707@helsinki.fi> Date: Wed, 13 Nov 2013 15:55:44 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: John C Klensin References: <24637769D123E644A105A0AF0E1F92EFA43A6F29@dnbf-ex1.AD.DDB.DE> <527CBBDC.3010904@helsinki.fi> <038FA310EC49A589FEA82B24@JCK-EEE10> In-Reply-To: <038FA310EC49A589FEA82B24@JCK-EEE10> Content-Type: multipart/alternative; boundary="------------080601020500060206000708" Cc: urn@ietf.org Subject: Re: [urn] Names and operatiions on named objects 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, 13 Nov 2013 13:56:01 -0000 This is a multi-part message in MIME format. --------------080601020500060206000708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello John; all, A lot of comments below. On 8.11.2013 17:25, John C Klensin wrote: > --On Friday, 08 November, 2013 12:24 +0200 Juha Hakala > wrote: > >> Hello, >> >> I am not sure if it is a good idea to indicate ("hard-code") >> in a query whether the query should be processed by the URN >> resolver or the resource. It might be best to leave the >> decision to the resolver, since they should know what the best >> option is. > Let me suggest putting that question aside for the moment and > concentrating on what the actual requirement might be. OK. >> Let us assume that the human end user wants descriptive >> metadata about the identified resource, in order to make sure >> that what he will get exactly what he wants. > After some discussion in Vancouver but with the understanding > that the confusion that follows is strictly mine, when I read > the above and the rest of the note, I'd like to ask some > fundamental questions about whether we can understand each other > and our terminology sufficiently to carry on a discussion. And > I'd like to do that without getting too much tied up in the > history of URNs and URIs. Without relying too much on any theory, my response below is based on actual implementation requirements, especially in the library community but also in museums and archives. > I apologize for the length of this. In some respects, I'm > trying to re-derive the theory of URNs. If I've succeeded (I > doubt that I have), a version of the contents of this note might > belong in an informational document somewhere. > > Can we agree about the following? > > URNs, just about by definition and without the details, are > supposed to provide names for objects, either directly or by > incorporating and using other identifiers for the objects. > ISBN, ISSN, and DOI URNs are examples of the latter. OK. > We don't > have URNs for classification system values (e.g., Dewey or LC > identifiers) because those are more like locators than about > names of objects. I agree that we don't have URNs for classification system values yet, but the National Library of Finland intends to assign URN:NBNs to concepts in the trilingual Finnish national ontology system. For now, cool URIs are used as identifiers (for instance, the URI for term damage is http://www.yso.fi/onto/koko/p35352), but we do not think that this is a satisfactory solution in the long run. Assigning persistent identifiers for data element values is seen as an essential part in creating linked data. And for libraries a subject heading like "damage" is not a locator but an object that can be used in various ways in information retrieval. It would not be possible to use e.g. ISBNs to identify subject headings, but that is not a problem with e.g. NBNs. Given that we have very liberal namespaces such as UUID or NBN, almost anything can be identified by URNs. > Or perhaps they are something else -- I think > that one thing that has gotten several of us confused is that we > have divided the resource-reference world into "locators" and > "identifiers" and that there really are other categories (as the > original URI model anticipated). > > The notion of naming an information-containing object is > obviously centuries old. Books and even some scrolls and > tablets have had titles (sometimes formal, sometimes not) nearly > forever. Modern names (perhaps more properly "identifiers") > have developed to clear up "same thing" ambiguities and > controversies by binding the identifier not only to an object > but to an axiomatic set of conventions about "sameness" and/or a > per-object registration procedure. Yes; some identifiers / namespaces have strict rules for specifying when the two resources are the same and when they are different. And we may have several, interrelated identifiers, and underlying model of how they relate to one another. One of these is the libraries' practice of separating works, manifestations and items (each of which can have an identifier). One work such as Hamlet may have a lot of different manifestations, and there may be a lot of copies (items) of each manifestation. Applying these models in practice requires complex rules. > Now, where the original URN definition may have been inadequate > is that it sort of assumed that named objects were atomic. A > URN that identifies the content of a web page, independent of > where the pages is located, is fine. But, when the named > objects get large and complicated one needs to recognize that > subsidiary identifiers of document structure are needs. Again, > this is nothing new: > RFC 2026, Section 4.1 > The Art of Computer Programming, Chapter 2 > > are examples of resource identifiers that we use all the time, > but that the original URN model doesn't handle well unless we > assign names to chapters or sections as well as to the whole > work, and that causes other problems. Yes, we routinely refer to / cite parts of documents, but citing does not imply that we want to identify them. In the current URN documentation we allow the use of URI fragment to indicate locations such as section 4.1 of RFC 2026. But this is only possible if RFC 2026 as a whole has a URN, encoding of the RFC allows us to mark the beginning of chapter 4.1 and if HTTP is used. So quite often we need to provide additional information such as page number to pinpoint the information we are referring to. In the URN context, fragment only indicates a location within the identified document; it does not identify anything. If that were the case, then URN:ISBN + fragment could be used to identify basically anything within a book (as long as that is technically possible), and the ISBN community would find it very difficult to accept such an uncontrolled extension of the scope and user community of the standard. The fact that fragments cannot be used to identify component parts of documents is not a problem, since different identifier systems can apply namespace specific means for identification of logical fragments. So, if chapter 2 of The Art of Computer Programming is for sale as a separate file, a URN:ISBN can be given to it, and that URN will resolve to Chapter 2 only. Or, a library can digitize a book and give a URN:NBN to each page image (and the entire book). Other PID systems have paid no attention whatsoever to fragment identification. In practice, projects using Handles have extended the scope of the PID by developing some innovative solutions for fragment identification, some of them completely against the stipulations of RFC 3986. This is one reason why URNbis should develop a standard solution for how to use fragment (and query). My gut feeling is that if we cannot agree on what to do, we may see a lot more innovative solutions for fragment identification in URNs, Handles, DOIs and so on. > Are we all together this far? If we are not, I think we have > either terminology or conceptual problems so basic that I need > someone to explain them to me. > > Now, using a functional notation that is deliberately different > from the URN/URI form, we can say > > * name(Art of Computer Programming) > But get what is, at the level of precise object or > resource identifiers, an ambiguous or multiple answer > because there are edition and volume issues when that > function is evaluated. Those edition issues (at least) > raise issues with what we have called stability, but, in > this case, they are a lot more about uniqueness. > Whether that is a problem of not depends on why we would > want to use the function. In the future, libraries will start the process from identification of the immaterial work. Art of Computer Programming, written by Donald Knuth, is a popular work with 151 different manifestations (not counting the multivolume versions). The identifier applied for textual works will be ISTC, and URN:ISTC will resolve to a description of the work and links to expressions (translations) and manifestations (physical embodiments) of which > > ISBN(Art of Computer Programming, Volume 1, 1968) > The hypothetical function yields "ISBN 0-201-03801-3", > and is unambiguous and stable. is just one. Each manifestation should have its own ISBN. > ISBN(Art of Computer Programming, Volume 1, 1968, Chapter 2) > This function evaluation probably fails, not because > there is anything wrong with the object-reference but > because ISBNs just don't do that. On the other hand, > since functions that return ISBNs aren't ISBNs, one > could define an ISBN-returning function, ISBNvar, s.t., Correct. But ISBN + fragment could take the user to the beginning of Chapter 2, and if we have digitized the book, we may have URN:NBNs both in chapter and in page level. > ISBNvar(Art of Computer Programming, Volume 1, 1968, Chapter 2) > Might then return "ISBN 0-201-03801-3; Chapter 2". That > is _not_ an ISBN; it is something that an ISBN > dereferencer/ processor that returns parts of books > might be able to do something with. But that > dereferencer isn't the "name" of the chapter, it is a > function that works on it. We might get ISBN + fragment as a response for this. We might also be able to check if a book which has been identified with ISBN has component parts which have been identified with URN:NBN. Different URN namespaces can be applied to complement one another. In practice, we do not see cases like this yet. If publishers sell chapters separately, they assign ISBNs (or DOIs) to each of them. > ISBNvar is a function that is applied to an object and > that yields a particular type of identifier (an > identifier that cannot be stated as part of an RFC > 2141-3406-3187 URN). Yes, but we might use 3188 (NBN) to extend the scope of 3187 (ISBN). > > If one had a book-retriever function s.t., > > book-retriever(adequately-unique-book-id) > Handed back the book, that would be really useful. It > doesn't make much difference to that conceptual > definition whether > > exec(book-retriever(adequately-unique-book-id)) > is performed by a human or a machine, the point is that > one applies a function to a book identifier and gets the > book back. And, again, this basic function is centuries > old. The function is also not a candidate for a URN > [namespace] because it doesn't name something, it > retrieves a named object. What we can add to this now is that if a person wants to find a manifestation of a book (such as 1968 edition of The Art of Computer Programming) and that version is not available, we can easily find out if one of the 150 other editions (such as the 3rd edition from 2011) is available. > > For completeness and assuming the ability to deal with nested > functions, > > book-retriever("ISBN 0-201-03801-3") and > book-retriever(ISBN(Art of Computer Programming, Volume 1, 1968)) > > are equivalent. If one defined "book-retriever" appropriately, > > book-retriever(ISBNvar(Art of Computer Programming, Volume 1, > 1968, Chapter 2)) > > would be fine too -- the book-retriever function just > over-retrieves a bit and no one thinks about it. > > But now let's assume that the library is modern, does > print-on-demand, and has sorted out all the copyright and other > issues. The new function, book-facsimile-retriever, returns > different things when applied to ISBNvar when that is applied to > strings with and without chapter identifiers for all of the > obvious economic and resource reasons. > > Ok so far? I think so. But we should not try to do too many things with URN syntax; a lot of functionality can be left to the namespaces. And it is important to know what current / future identification practices are within the potential URN user communities; otherwise we may develop features which will not be useful or will replicate things people prefer to leave to the namespace level. > If I have this right, at least some of our discussion isn't > actually about URNs or even URN defererencing. We have a clear > issue as to whether URN namespace and syntax that would allow an > equivalent of ISBNvar to be expressed (my own impression from > the above and discussions on the list is a pretty clear "yes"). > But choices of functions that can be applied to a given URN > (e.g., between "book-retriever" and "book-facsimile-retriever" > above) is not a URN problem. Yes - bibliographic information systems will be aware of relations between books and their digital or facsimile surrogates. So if somebody wants to read a Finnish dissertation printed in 17th century, the user will be informed that the original book is only available witihin the library, but digital copy is free. Interlinking of bibliographic records describing these versions of the book will be based on identifiers, but URNs themselves do not need to be aware of all these versions; the required links are embedded in bibliographic metadata. > That choice also implies that we'd > best be careful when we think about systems for finding > functions that can be applied to a particular URN namespace to > retrieve or otherwise process objects because there can be > several such functions that are appropriate under different > circumstances (as well as zero for some namespaces). Right; and because there is no pre-defined and stable set of functions (services) it must be easy to specify additional URN resolution services whenever they are needed. > > I'm reasonably sure about all of the above. Of course, I could > be completely wrong. If I am, can we have the discussion in the > above terms rather than getting tied up with what is or is not a > URN and how they are organized, compared, etc. Those are > important questions, but I think we need to be sure we are all > talking about the same thing before we try to answer them. > > In particular, I think different people are using "URN resolver" > in a number of different ways and that is contributing to our > confusion (and some of us being bewildered by what others appear > to be saying). Some (most?) of us have URN resolvers in production. And there are plans of how to enrich them with new functionality, so that we can supply for instance metadata as a surrogate to the resource itself. > > That brings me back to Juha's note because, at least if the > above reasoning is correct, retrieval of metadata about a named > object is no more part of the name, or functions that act on an > object to name it, than book-retrieval is. In other words, a > function like: > > metadata-retriever(name, attributes) > Makes perfectly good sense, even if "name" actually > makes the function > > metadata-retriever(ISBNvar(Art of Computer Programming, Volume > 1, 1968, Chapter 2), "page-count", "publisher", ...) > Which would return some number and "Addison-Wesley". > > In the same context, one might have: > > metadata-search((ISBNvar), "page-count", "publisher") > or, if someone could design the relevant abstractions > (not our problem, fortunately) > ISBNvar(metadata-search("page-count", "publisher")) > > Which would return a number of names in whatever format > ISBNvar returned. > > Coming back to Juha's note and stressing that I'm not > disagreeing, I'm just trying to be sure that we are all talking > about the same thing. My impression is that we are all talking about an elephant, but perhaps concentrating on different body parts ;-). Libraries have been using URNs for a long time, and our URN-related requirements stem on the one hand from our collections and systems, and on the other hand from the legacy identifier systems libraries use. Like any other user community, we want a URN that can be adapted to meet our needs. It would be very difficult for us to change our key routines (such as assigning ISBNs to books) to accommodate a PID system. > >> The URN resolver must know at least one resource which is >> capable of supplying the requested service. This service might >> be for instance a bibliographic database which supports SRU >> query. The resolver must know the search protocol, and it must >> be capable of transforming the URN + query into appropriate >> SRU search request. > This, along with the closely-related notion of just typing a URN > into a web browser where a URL might otherwise go, is what I > keep having trouble getting my head around. A [generic] "URL > resolver" works because a URL doesn't specify a location at all. > Instead, it specifies a method and data for that method. As > such, a "URL resolver" isn't a resolver, it is what some > computer science disciplines would call a "method dispatcher". URNs are no different in that respect. Currently most URN resolvers are very simple, and HTTP URI with embedded URN is mapped into the URL which shows the current location of the resource in the Internet. What we are looking forward to is a resolver which can support a wider set of resolution services, so that if a user wants metadata about the resource instead of the resource itself, then the URN resolver must a search request according to the SRU protocol, or, in John's terminology, method (SRU) and data (search request encoded as URL). > If I'm right, a "URN resolver" is a function (or member of a set > of functions) that might reasonably be applied to a name with a > namespace-specific domain. Yes. > That might make a database or > registry of functions that work on the names in a particular > namespace an interesting thing to have (or not), but that one > can't have a universal URN resolver because its inputs would > have to be not just the name but a method-like statement about > what one wanted to do with that name or the associated object, > if any... and those are not the same thing. We are not striving for anything universal, just a network of interconnected resolvers, each one of which is aware of how to deal with certain kinds of resolution requests. A user could produce something like http://urn.fi/urn:isbn:?s=URC and our national URN resolver would know how to deal with that. >> Following a software update in the bibliographic database, it >> might become possible to pass the URN + query as such to the >> database. Then there would be no need to anything to the query >> in the resolver and the URN can be passed as such to the >> resource. > I'm confused about this too, partially because, as someone who > used to work in databases, I'm used to phrases like "pass > [something] to the database" being the worst kind of handwaving. Sorry for being too vague with this. What I meant was that a URI like http://urn.fi/urn:isbn:?s=URC can be passed to the appropriate port in a bibliographic database. The application would have to know how to parse the request. Bibliographic databases are currently able to deal with SRU search requests, which look like this: http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query= It is not hard for the URN resolvers to map HTTP URIs such as the one above into SRU queries. The resolver only needs to know the address of the relevant SRU server, and the mapping of the URN NID into an SRU query term. And if the resolver can do this, the bibliographic information system can do such mapping as well. > I think the above use may be too, but I'm not sure what is > actually intended. I know what it means to apply a function to > a database because I then know how to determine whether that > function and its arguments are actually well-specified. f(name, > query) over a particular database (or f((database), name, query) > don't bother me at all, but I hope you see where this is going. Yes, I do. > >> ... >> Letting the user to specify where the query is to be processed >> might also be counterproductive if the user makes the wrong >> choice; that is, demanding for instance that the resolver >> passes the URN + query to resource which cannot deal with URNs >> (but does support 1-n interfaces that would do). > See the "chapter" and "book-retriever" discussions above. > >> To make things clear to the implementers, RFC 2483bis could >> explain that normally URN resolvers will decide whether to >> pass queries on as such or to turn them into something else >> before passing the request on to the resource. The end users >> should not even need to know where their requests are >> processed; all they care about is that they get what they are >> asking for. > I think the latter is very important, but the "URN resolver" > postulated above seems to require a component of magic. I hope not; there is nothing magical in our information systems although they sometimes produce unpredictable results :-). Juha > > best regards, > 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 --------------080601020500060206000708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello John; all,

 A lot of comments below.

On 8.11.2013 17:25, John C Klensin wrote:
--On Friday, 08 November, 2013 12:24 +0200 Juha Hakala
<juha.hakala@helsinki.fi> wrote:


Hello,

I am not sure if it is a good idea to indicate ("hard-code")
in a query whether the query should be processed by the URN
resolver or the resource. It might be best to leave the
decision to the resolver, since they should know what the best
option is.

Let me suggest putting that question aside for the moment and
concentrating on what the actual requirement might be.

OK. 

      

        
Let us assume that the human end user wants descriptive
metadata about the identified resource, in order to make sure
that what he will get exactly what he wants.


      

      
After some discussion in Vancouver but with the understanding
that the confusion that follows is strictly mine, when I read
the above and the rest of the note, I'd like to ask some
fundamental questions about whether we can understand each other
and our terminology sufficiently to carry on a discussion.  And
I'd like to do that without getting too much tied up in the
history of URNs and URIs.

    

    

    Without relying too much on any theory, my response below is based
    on actual implementation requirements, especially in the library
    community but also in museums and archives. 

    

    

      
I apologize for the length of this.  In some respects, I'm
trying to re-derive the theory of URNs.  If I've succeeded (I
doubt that I have), a version of the contents of this note might
belong in an informational document somewhere.

Can we agree about the following?

URNs, just about by definition and without the details, are
supposed to provide names for objects, either directly or by
incorporating and using other identifiers for the objects.
ISBN, ISSN, and DOI URNs are examples of the latter.   

    

    

    OK. 

    

    

      
We don't
have URNs for classification system values (e.g., Dewey or LC
identifiers) because those are more like locators than about
names of objects.  

    

    I agree that we don't have URNs for classification system values
    yet, but the National Library of Finland intends to assign URN:NBNs
    to concepts in the trilingual Finnish national ontology system. For
    now, cool URIs are used as identifiers (for instance, the URI for
    term damage is http://www.yso.fi/onto/koko/p35352),
    but we do not think that this is a satisfactory solution in the long
    run. 

    

    Assigning persistent identifiers for data element values is seen as
    an essential part in creating linked data. And for libraries a
    subject heading like "damage" is not a locator but an object that
    can be used in various ways in information retrieval. 

    

    It would not be possible to use e.g. ISBNs to identify subject
    headings, but that is not a problem with e.g. NBNs. Given that we
    have very liberal namespaces such as UUID or NBN, almost anything
    can be identified by URNs. 

    

      
Or perhaps they are something else -- I think
that one thing that has gotten several of us confused is that we
have divided the resource-reference world into "locators" and
"identifiers" and that there really are other categories (as the
original URI model anticipated).

The notion of naming an information-containing object is
obviously centuries old.  Books and even some scrolls and
tablets have had titles (sometimes formal, sometimes not) nearly
forever.  Modern names (perhaps more properly "identifiers")
have developed to clear up "same thing" ambiguities and
controversies by binding the identifier not only to an object
but to an axiomatic set of conventions about "sameness" and/or a
per-object registration procedure.

    

    Yes; some identifiers / namespaces have strict rules for specifying
    when the two resources are the same and when they are different. And
    we may have several, interrelated identifiers, and underlying model
    of how they relate to one another. One of these is the libraries'
    practice of separating works, manifestations and items (each of
    which can have an identifier). One work such as Hamlet may have a
    lot of different manifestations, and there may be a lot of copies
    (items) of each manifestation. Applying these models in practice
    requires complex rules.  

    

      
Now, where the original URN definition may have been inadequate
is that it sort of assumed that named objects were atomic.  A
URN that identifies the content of a web page, independent of
where the pages is located, is fine.  But, when the named
objects get large and complicated one needs to recognize that
subsidiary identifiers of document structure are needs.  Again,
this is nothing new:
     RFC 2026, Section 4.1
     The Art of Computer Programming, Chapter 2

are examples of resource identifiers that we use all the time,
but that the original URN model doesn't handle well unless we
assign names to chapters or sections as well as to the whole
work, and that causes other problems.

    

    Yes, we routinely refer to / cite parts of documents, but citing
    does not imply that we want to identify them.

     

    In the current URN documentation we allow the use of URI fragment to
    indicate locations such as section 4.1 of RFC 2026. But this is only
    possible if RFC 2026 as a whole has a URN, encoding of the RFC
    allows us to mark the beginning of chapter 4.1 and if HTTP is used.
    So quite often we need to provide additional information such as
    page number to pinpoint the information we are referring to.  

    

    In the URN context, fragment only indicates a location within the
    identified document; it does not identify anything. If that were the
    case, then URN:ISBN + fragment could be used to identify basically
    anything within a book (as long as that is technically possible),
    and the ISBN community would find it very difficult to accept such
    an uncontrolled extension of the scope and user community of the
    standard. 

    

    The fact that fragments cannot be used to identify component parts
    of documents is not a problem, since different identifier systems
    can apply namespace specific means for identification of logical
    fragments. So, if chapter 2 of The Art of Computer Programming is
    for sale as a separate file, a URN:ISBN can be given to it, and that
    URN will resolve to Chapter 2 only. Or, a library can digitize a
    book and give a URN:NBN to each page image (and the entire book).  

    

    Other PID systems have paid no attention whatsoever to fragment
    identification. In practice, projects using Handles have extended
    the scope of the PID by developing some innovative solutions for
    fragment identification, some of them completely against the
    stipulations of RFC 3986. This is one reason why URNbis should
    develop a standard solution for how to use fragment (and query). My
    gut feeling is that if we cannot agree on what to do, we may see a
    lot more innovative solutions for fragment identification in URNs,
    Handles, DOIs and so on.     

    

    

      
Are we all together this far?   If we are not, I think we have
either terminology or conceptual problems so basic that I need
someone to explain them to me.

Now, using a functional notation that is deliberately different
from the URN/URI form, we can say 

* name(Art of Computer Programming)
	But get what is, at the level of precise object or
	resource identifiers, an ambiguous or multiple answer
	because there are edition and volume issues when that
	function is evaluated.  Those edition issues (at least)
	raise issues with what we have called stability, but, in
	this case, they are a lot more about uniqueness.
	Whether that is a problem of not depends on why we would
	want to use the function.

    

    In the future, libraries will start the process from identification
    of the immaterial work. Art of Computer Programming, written by
    Donald Knuth, is a popular work with 151 different manifestations
    (not counting the multivolume versions). 

    

    The identifier applied for textual works will be ISTC, and URN:ISTC
    will resolve to a description of the work and links to expressions
    (translations) and manifestations (physical embodiments) of which  
    

    

      
	
ISBN(Art of Computer Programming, Volume 1, 1968)
	The hypothetical function yields "ISBN 0-201-03801-3",
	and is unambiguous and stable.

    

    is just one. Each manifestation should have its own ISBN.   

    

      
ISBN(Art of Computer Programming, Volume 1, 1968, Chapter 2)
	This function evaluation probably fails, not because
	there is anything wrong with the object-reference but
	because ISBNs just don't do that.  On the other hand,
	since functions that return ISBNs aren't ISBNs, one
	could define an ISBN-returning function, ISBNvar, s.t.,

    

    Correct. But ISBN + fragment could take the user to the beginning of
    Chapter 2, and if we have digitized the book, we may have URN:NBNs
    both in chapter and in page level. 

    

      
ISBNvar(Art of Computer Programming, Volume 1, 1968, Chapter 2)
	Might then return "ISBN 0-201-03801-3; Chapter 2".  That
	is _not_ an ISBN; it is something that an ISBN
	dereferencer/ processor that returns parts of books
	might be able to do something with.   But that
	dereferencer isn't the "name" of the chapter, it is a
	function that works on it.

    

    We might get ISBN + fragment as a response for this. We might also
    be able to check if a book which has been identified with ISBN has
    component parts which have been identified with URN:NBN. Different
    URN namespaces can be applied to complement one another.  

    

    In practice, we do not see cases like this yet. If publishers sell
    chapters separately, they assign ISBNs (or DOIs) to each of them. 

    

      
	ISBNvar is a function that is applied to an object and
	that yields a particular type of identifier (an
	identifier that cannot be stated as part of an RFC
	2141-3406-3187 URN).

    

    Yes, but we might use 3188 (NBN) to extend the scope of 3187 (ISBN).
    

    

      

If one had a book-retriever function s.t., 

book-retriever(adequately-unique-book-id)
	Handed back the book, that would be really useful.  It
	doesn't make much difference to that conceptual
	definition whether 

exec(book-retriever(adequately-unique-book-id))
	is performed by a human or a machine, the point is that
	one applies a function to a book identifier and gets the
	book back.  And, again, this basic function is centuries
	old.  The function is also not a candidate for a URN
	[namespace] because it doesn't name something, it
	retrieves a named object.

    

    What we can add to this now is that if a person wants to find a
    manifestation of a book (such as 1968 edition of The Art of Computer
    Programming) and that version is not available, we can easily find
    out if one of the 150 other editions (such as the 3rd edition from
    2011) is available.   

    

      

For completeness and assuming the ability to deal with nested
functions,

book-retriever("ISBN 0-201-03801-3")     and
book-retriever(ISBN(Art of Computer Programming, Volume 1, 1968))

are equivalent.  If one defined "book-retriever" appropriately, 

book-retriever(ISBNvar(Art of Computer Programming, Volume 1,
1968, Chapter 2))

	would be fine too -- the book-retriever function just
	over-retrieves a bit and no one thinks about it.

But now let's assume that the library is modern, does
print-on-demand, and has sorted out all the copyright and other
issues.  The new function, book-facsimile-retriever, returns
different things when applied to ISBNvar when that is applied to
strings with and without chapter identifiers for all of the
obvious economic and resource reasons.

Ok so far?

    

    I think so. But we should not try to do too many things with URN
    syntax; a lot of functionality can be left to the namespaces. And it
    is important to know what current / future identification practices
    are within the potential URN user communities; otherwise we may
    develop features which will not be useful or will replicate things
    people prefer to leave to the namespace level. 

    

      
If I have this right, at least some of our discussion isn't
actually about URNs or even URN defererencing.  We have a clear
issue as to whether URN namespace and syntax that would allow an
equivalent of ISBNvar to be expressed (my own impression from
the above and discussions on the list is a pretty clear "yes").
But choices of functions that can be applied to a given URN
(e.g., between "book-retriever" and "book-facsimile-retriever"
above) is not a URN problem.  

    

    Yes - bibliographic information systems will be aware of relations
    between books and their digital or facsimile surrogates. So if
    somebody wants to read a Finnish dissertation printed in 17th
    century, the user will be informed that the original book is only
    available witihin the library, but digital copy is free.
    Interlinking of bibliographic records describing these versions of
    the book will be based on identifiers, but URNs themselves do not
    need to be aware of all these versions; the required links are
    embedded in bibliographic metadata. 

    

    

      
That choice also implies that we'd
best be careful when we think about systems for finding
functions that can be applied to a particular URN namespace to
retrieve or otherwise process objects because there can be
several such functions that are appropriate under different
circumstances (as well as zero for some namespaces).

    

    Right; and because there is no pre-defined and stable set of
    functions (services) it must be easy to specify additional URN
    resolution services whenever they are needed. 

    

      

I'm reasonably sure about all of the above.   Of course, I could
be completely wrong.  If I am, can we have the discussion in the
above terms rather than getting tied up with what is or is not a
URN and how they are organized, compared, etc.   Those are
important questions, but I think we need to be sure we are all
talking about the same thing before we try to answer them.

In particular, I think different people are using "URN resolver"
in a number of different ways and that is contributing to our
confusion (and some of us being bewildered by what others appear
to be saying).

    

    Some (most?) of us have URN resolvers in production. And there are
    plans of how to enrich them with new functionality, so that we can
    supply for instance metadata as a surrogate to the resource itself.
    

    

      

That brings me back to Juha's note because, at least if the
above reasoning is correct, retrieval of metadata about a named
object is no more part of the name, or functions that act on an
object to name it, than book-retrieval is.   In other words, a
function like:

metadata-retriever(name, attributes)
	Makes perfectly good sense, even if "name" actually
	makes the function
	
metadata-retriever(ISBNvar(Art of Computer Programming, Volume
1, 1968, Chapter 2), "page-count", "publisher", ...)
	Which would return some number and "Addison-Wesley".

In the same context, one might have:

metadata-search((ISBNvar), "page-count", "publisher")
	or, if someone could design the relevant abstractions
	(not our problem, fortunately)
ISBNvar(metadata-search("page-count", "publisher"))

	Which would return a number of names in whatever format
	ISBNvar returned.
	
Coming back to Juha's note and stressing that I'm not
disagreeing, I'm just trying to be sure that we are all talking
about the same thing.

    

    My impression is that we are all talking about an elephant, but
    perhaps concentrating on different body parts ;-). Libraries have
    been using URNs for a long time, and our URN-related requirements
    stem on the one hand from our collections and systems, and on the
    other hand from the legacy identifier systems libraries use. Like
    any other user community, we want a URN that can be adapted to meet
    our needs. It would be very difficult for us to change our key
    routines (such as assigning ISBNs to books) to accommodate a PID
    system.  

    

      



      

        
The URN resolver must know at least one resource which is
capable of supplying the requested service. This service might
be for instance a bibliographic database which supports SRU
query. The resolver must know the search protocol, and it must
be capable of transforming the URN + query into appropriate
SRU search request.


      

      
This, along with the closely-related notion of just typing a URN
into a web browser where a URL might otherwise go, is what I
keep having trouble getting my head around.  A [generic] "URL
resolver" works because a URL doesn't specify a location at all.
Instead, it specifies a method and data for that method.  As
such, a "URL resolver" isn't a resolver, it is what some
computer science disciplines would call a "method dispatcher".

    

    URNs are no different in that respect. Currently most URN resolvers
    are very simple, and HTTP URI with embedded URN is mapped into the
    URL which shows the current location of the resource in the
    Internet.  

    

    What we are looking forward to is a resolver which can support a
    wider set of resolution services, so that if a user wants metadata
    about the resource instead of the resource itself, then the URN
    resolver must a search request according to the SRU protocol, or, in
    John's terminology, method (SRU) and data (search request encoded as
    URL). 

    

      
If I'm right, a "URN resolver" is a function (or member of a set
of functions) that might reasonably be applied to a name with a
namespace-specific domain.  

    

    Yes. 

    

      
That might make a database or
registry of functions that work on the names in a particular
namespace an interesting thing to have (or not), but that one
can't have a universal URN resolver because its inputs would
have to be not just the name but a method-like statement about
what one wanted to do with that name or the associated object,
if any... and those are not the same thing.

    

    We are not striving for anything universal, just a network of
    interconnected resolvers, each one of which is aware of how to deal
    with certain kinds of resolution requests. A user could produce
    something like  

    

    http://urn.fi/urn:isbn:<isbn-number>?s=URC

    

    and our national URN resolver would know how to deal with that. 

    

      

      

        
Following a software update in the bibliographic database, it
might become possible to pass the URN + query as such to the
database. Then there would be no need to anything to the query
in the resolver and the URN can be passed as such to the
resource.


      

      
I'm confused about this too, partially because, as someone who
used to work in databases, I'm used to phrases like "pass
[something] to the database" being the worst kind of handwaving.

    

    Sorry for being too vague with this. What I meant was that a URI
    like 

    

    http://urn.fi/urn:isbn:<isbn-number>?s=URC

    

    can be passed to the appropriate port in a bibliographic database.
    The application would have to know how to parse the request. 

    

    Bibliographic databases are currently able to deal with SRU search
    requests, which look like this:

    

    http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=<isbn-number>

    

    It is not hard for the URN resolvers to map HTTP URIs such as the
    one above into SRU queries. The resolver only needs to know the
    address of the relevant SRU server, and the mapping of the URN NID
    into an SRU query term. And if the resolver can do this, the
    bibliographic information system can do such mapping as well. 

      

    

      
I think the above use may be too, but I'm not sure what is
actually intended.  I know what it means to apply a function to
a database because I then know how to determine whether that
function and its arguments are actually well-specified.  f(name,
query) over a particular database (or f((database), name, query)
don't bother me at all, but I hope you see where this is going.

    

    Yes, I do.

    

      



      

        
...
Letting the user to specify where the query is to be processed
might also be counterproductive if the user makes the wrong
choice; that is, demanding for instance that the resolver
passes the URN + query to resource which cannot deal with URNs
(but does support 1-n interfaces that would do).


      

      
See the "chapter" and "book-retriever" discussions above.



      

        
To make things clear to the implementers, RFC 2483bis  could
explain that normally URN resolvers will decide whether to
pass queries on as such or to turn them into something else
before passing the request on to the resource. The end users
should not even need to know where their requests are
processed; all they care about is that they get what they are
asking for.


      

      
I think the latter is very important, but the "URN resolver"
postulated above seems to require a component of magic.

    

    I hope not; there is nothing magical in our information systems
    although they sometimes produce unpredictable results :-).

    

    Juha

    

      

best regards,
   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 




  


--------------080601020500060206000708--

From stpeter@stpeter.im  Wed Nov 13 15:13: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 D65D311E810C for ; Wed, 13 Nov 2013 15:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.29
X-Spam-Level: 
X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 ynG0AvPGyna5 for ; Wed, 13 Nov 2013 15:13:15 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D2A3A21E80CF for ; Wed, 13 Nov 2013 15:13:12 -0800 (PST)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5A47E4010C; Wed, 13 Nov 2013 16:13:11 -0700 (MST)
Message-ID: <52840784.2030302@stpeter.im>
Date: Wed, 13 Nov 2013 16:13:08 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: John C Klensin , urn@ietf.org
References: <7639E40F70A558B99C1D2367@JcK-HP8200.jck.com>
In-Reply-To: <7639E40F70A558B99C1D2367@JcK-HP8200.jck.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [urn] The 3406bis template
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, 13 Nov 2013 23:13:20 -0000

[ old thread alert ]

On 8/2/13 6:51 AM, John C Klensin wrote:
> Hi.
> 
> I just looked back through the template in
> draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06 in the light of the
> WG discussion this morning.
> 
> The template description is now over four pages long and some of
> the suggestions made this morning will probably make it longer.
> That is pretty scary; it asks for enough information be copied
> into the template and handed to IANA to probably be seen as a
> barrier to registration in some quarters.  
> 
> Recommendations:
> 
> (1) When the "instructions to Expert Reviewer" material is
> added, be clear about what is required and what is merely
> expected.  Then reflect that in the sections of the template
> itself.
> 
> (2) Number or otherwise identify the sections of the template to
> make references and cross-references convenient.  That will,
> fwiw, keep this document from running afoul of some
> possibly-pending RFC Editor style rules.
> 
> (3) Create an internal table of contents for the template itself.
> 
> (4) Explicitly permit most sections of the template to be
> incorporated by reference to a stable external specification
> (stable by at least the "Specification Required" definition, not
> just the RFC Editor one) or by a mixture of text and such a
> reference.  By explicit about which ones cannot (I think the
> first three sections need to be present in the template itself).
> 
> Let's not make this any harder than it absolutely needs to be.

I completely agree. In fact, over the last few days I have performed
some major surgery on 3406bis to further simplify registration. In my
working copy, the template is now one page, not four. I will submit my
proposal soon so that folks here can review it. It's possible that I've
gone too far in the direction of simplification, in which case we can
always meeting somewhere in the middle.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From internet-drafts@ietf.org  Wed Nov 13 15:29:37 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 A128F11E8136; Wed, 13 Nov 2013 15:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level: 
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 cVDvmi7kQj1U; Wed, 13 Nov 2013 15:29:37 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FB011E810B; Wed, 13 Nov 2013 15:29:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131113232937.30506.99807.idtracker@ietfa.amsl.com>
Date: Wed, 13 Nov 2013 15:29:37 -0800
Cc: urn@ietf.org
Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07.txt
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 23:29:37 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Uniform Resource Names, Revised Working G=
roup of the IETF.

	Title           : Uniform Resource Name (URN) Namespace Definition Mechani=
sms
	Author(s)       : Peter Saint-Andre
	Filename        : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07.txt
	Pages           : 14
	Date            : 2013-11-13

Abstract:
   This document supplements the Uniform Resource Name (URN) syntax
   specification by defining the concept of a URN namespace, as well as
   mechanisms for defining and registering such namespaces.  This
   document obsoletes RFC 3406.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3406bis-urn-ns-reg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc3406bis-urn-ns-reg-=
07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From andy@hxr.us  Mon Nov 25 14:16:12 2013
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE291AE051 for ; Mon, 25 Nov 2013 14:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0D_Vr8o6wdx6 for ; Mon, 25 Nov 2013 14:16:10 -0800 (PST)
Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id AA8441AE05F for ; Mon, 25 Nov 2013 14:16:10 -0800 (PST)
Received: by mail-pb0-f51.google.com with SMTP id up15so6667641pbc.38 for ; Mon, 25 Nov 2013 14:16:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=f22mRovVFVWYrwTsFHEIctq/4hObxssX0NrMi64Me+w=; b=mVEuA9hO31UPTIRMK7FaN6jixgKOLtE4gmmjBTJ/bQKR8IPFRQHTZnTQ95qmPD5Jbp WIc22+PdXu3/u2KHLWSCcWDg075dMQVRmj69bHQUDlTDA4RTIu0DMs3nc426EEn1F0m3 iUqBz/xxQoyYw55kiVGjC94+Oclr+STHzsiD1r+c2Y8+zo/FpmRQ2SK3UyNsp9MSZsT4 xZW9k/PiWLmjyuEmYrOZ1gbbeABMbxdRRFstxZMJbpWjlXtgKRahuPQAMFJO3/EQ9Fmz tpK9OPwnI2nxMx9RUiy6PGc0N3vaE32i8r2eprvrSASn8B+C0OPmULoQyFPgRr63+2ju IMsg==
X-Gm-Message-State: ALoCoQkXqP/KTxIGDbDtcf3r+TTVfBErdP/2aQw5yymRwXwT4I7BO3eirLvwomfs+PnJViB6y8bt
MIME-Version: 1.0
X-Received: by 10.66.246.229 with SMTP id xz5mr5273767pac.128.1385417769866; Mon, 25 Nov 2013 14:16:09 -0800 (PST)
Received: by 10.68.16.196 with HTTP; Mon, 25 Nov 2013 14:16:09 -0800 (PST)
X-Originating-IP: [2001:500:4:15:b0de:85f:8372:904e]
Date: Mon, 25 Nov 2013 17:16:09 -0500
Message-ID: 
From: Andrew Newton 
To: "urn@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [urn] New Milestones
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Nov 2013 22:16:12 -0000

All,

Our milestones have been out of date for some time. In working with
Barry Leiba (our Area Director) and our document authors, new
milestones have been set for this working group. It should be noted
that they are fairly aggressive, and we are hoping to finish up work
here in the early part of next year.

The new milestones are listed on our charter page:
http://datatracker.ietf.org/wg/urnbis/charter/

...but for your convenience:

Dec 2013Update URN Namespace Definition (3406bis)
Dec 2013Collect and settle fragment/query requirements
Jan 2014WGLC on URN Namespace Definition (3406bis)
Jan 2014WGLC on URN Namespace Registration Transition
Feb 2014Update URN Syntax (2141bis) based on resolution of requirements
Mar 2014WGLC on URN Syntax (2141bis)

-andy