From stpeter@stpeter.im Wed Oct 30 20:06:03 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 182A411E82FE for ; Wed, 30 Oct 2013 20:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 fFqls3NBaxIL for ; Wed, 30 Oct 2013 20:05:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C754521E80B8 for ; Wed, 30 Oct 2013 20:05:29 -0700 (PDT) Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3F9654010C; Wed, 30 Oct 2013 21:05:13 -0600 (MDT) Message-ID: <5271C8E8.70008@stpeter.im> Date: Wed, 30 Oct 2013 21:05:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Juha Hakala References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi> <523FEDDF.9080805@it.aoyama.ac.jp> In-Reply-To: <523FEDDF.9080805@it.aoyama.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] Separate schemes for resources and resolution services X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 03:06:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Martin, my apologies for the delayed reply to this and other threads. On 09/23/2013 01:29 AM, "Martin J. Dürst" wrote: > Hello Juha, John, others, > > Caveat: I have been following the urn WG only with a limited time > budget, but see below for my thinking. > > On 2013/09/19 14:21, Juha Hakala wrote: >> Hello, >> >> On 4.9.2013 6:21, John C Klensin wrote: >>> >>> --On Tuesday, September 03, 2013 21:04 -0600 Peter Saint-Andre >>> wrote: >>> >>>>> Would it be appropriate to incorporate text into 2141bis >>>>> and/or 3406bis that explicitly reserves "agent" as a query >>>>> keyword and specifies "agent=resolver" as the default >>>>> case? >>>> Personally I'd prefer to avoid reserving key-value pairs for >>>> the query component... >> It might be better to keep 2141bis simple and leave any >> guidelines of how to use query out of it. Then there will be no >> need to amend or expand the text in the future as regards the >> query utilization. >> >> The future version of rfc2483 will not even try to provide an >> exhaustive list of resolution services, since no such thing can >> exist. Instead there will be an (IANA) registry of services. This >> registry should contain a mnemonic (for example I2R for URI to >> resource) for each service and query syntax for requesting them >> from resolvers (for example "?s=I2R"). In addition, the registry >> has to list service-specific parameters. >> >> Instead of supplying the query related information piece by piece >> in 2141bis, 3406bis, 2483bis and in the (proposed) registry of >> services it is better to collect it into one place from which the >> implementers can easily find it and where it is as easy as >> possible to maintain it. >> >> I am not sure if we need to / can tell the implementers what kind >> of query combinations make sense. Making such a document >> exhaustive would be difficult. >> >> IMO it would not do any harm to reserve agent as a query >> keyword. > > URNs are resource identifiers. As such, I think that if they have > query parameters, these should be defined by the resource, without > any influence by resolution services. That's what I'd assume for > any other URI scheme, too. > > For something close to resolution parameters, I seem to remember > that an early URI spec defined a place for such parameters after a > ';'. I can dig up the spec if that helps. > > However, I think that it might be better to create a new scheme, or > new schemes, for resolution services if they need additional > parameters. An example generic 'resolution service' scheme might > look as follows: > urn-resolution:urn=urn:isbn:123-45678-90;resolve-to=meta_data > Schemes for particular resolver protocols are also possible; some > of them might not need their own scheme, in particular if they run > over http. > > This has several advantages: It separates the resource from the > resolution, which is conceptually how things should be.[*] It > allows both resources and resolution to use whatever 'query' > parameters they deem appropriate, without name conflicts, and it > allows the query parameter space for resolution services to be > developed from now on, at a point where we are not sure yet how > much these parameters will be shared between resolution services. > > Hope this helps, Martin. > > [*] Just to give an example, nobody would propose to put a "proxy" > parameter into an http: URI, although HTTP proxies can be thought > of as a kind of resolution service. Also, nobody would propose to > add something to the http: URI syntax in order to e.g. distinguish > a "GET" request from a "HEAD" request. But this is quite close to > the distinction between 'resource' and 'metadata' in the URN > resolver discussions. Martin, I find these distinctions quite helpful. In previous messages to this list, I have mentioned that I would find it reasonable for a URN resolution service to be run as a web service at an HTTP(S) URI, for example: https://res.example.com/?urn=urn:isbn:123-45678-90&resolve-to=metadata (As you suggest, we could define some new URI scheme for resolution, but using HTTP(S) seems much easier.) However, I don't really find it reasonable to use URNs to both identity resources and interact with resoluton services. Although it's been assumed that this makes sense, I think it's incumbent upon those who want this feature to make a clear, cogent, persuasive argument for it. Thus I suggest that we leave 2141bis as the specification for resource naming only (which is what the acronym "URN" denotes anyway). If those who use resolution services feel that they need to define a new URI scheme or to define conventions for resolving URNs via HTTP or some other protocol, they are free to do so. Overloading the resource naming scheme (URNs) to also interact with resolution services seems quite problematic to me. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSccjnAAoJEOoGpJErxa2pGb0P/A146oy0w6KFjibDLeRAWx8D TQw7ydZ0k/Mp5A+XSYJNN7VtmADBxFbvs7XoFPfl1OBqUU/OQUD4OllbXCIiA8sc JWDzTzJtKlcD92dus8MApT/m+80iTI3/DB8/aUgOAaLwTcobEYfTo64VUh2adBCt EjRaXbgMrJAR4oWeDdtB47ruZHrzog+6iosXMLTuEsuW7a5mqJK6PbIhALCTAgNd PXCHw/pdFUkquaSMtgyJfImvBuTNNwriFiY9TxOJYYYFELr4HE3r2cQCzCZPMKwd zM4XJYrsSoU7T3JFgNwQLvhx4Ysl4QM3RwohdPPdyTZ4uh2iMd5L7yasG8Q7Zlaq i3JVHkQjYl8jQkp84VpNFo5msBLNKtliGcX/MbZDaba8oI6466UtQFPSkaw65riI Qk0ZLJUdxf6xgoYEJeNUCvfu1HK/Bnls/6SjckD1EaQ5LR2FY3oDSbOKgoRTNNYN PKFgRawCENMcw2C298CFQd5BPdvw9L7mouehZCBPJvlVGpF+p9AamONUM+MKdb4r rubgyFDjvz2SL3te+uyWRjZM2w2K8ai27snm4NpqLkrAcWYfrHrAi7LW4wuBOaVt UytwMU0gbiDF5LmNT4nV1KHzULlD+bt+fJ0FkKkk4pGfP93qFhXGRVSzrKPqQ1cs 3gxUmUZDM7LaxsZvWbc7 =XrnO -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Oct 30 20:26:25 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE31711E8301 for ; Wed, 30 Oct 2013 20:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 Ppk1mgLiYlcS for ; Wed, 30 Oct 2013 20:26:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B8AE211E81DD for ; Wed, 30 Oct 2013 20:26:14 -0700 (PDT) Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F0AF44010C; Wed, 30 Oct 2013 21:26:13 -0600 (MDT) Message-ID: <5271CDD5.1020501@stpeter.im> Date: Wed, 30 Oct 2013 21:26:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: 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> In-Reply-To: <20130904195829.Horde.zJzZDuyF1rFkws0e6fGCnQ1.jehakala@webmail.helsinki.fi> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 03:26:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/04/2013 10:58 AM, jehakala@mappi.helsinki.fi wrote: > Hello, > > Quoting Keith Moore : > >> On 09/03/2013 11:16 PM, Peter Saint-Andre wrote: >>>>> In comparison, the planned use of query in the URN context >>>>> should be >>>>>>> relatively simple. But the URN resolvers may need to >>>>>>> get >>>>> smarter. For >>>>>>> instance, if I want a resource description instead of >>>>>>> the resource itself, the URN resolver may need to >>>>>>> extract the required data elements from the URN query >>>>>>> into an SRU searchRetrieve URL (if the target system >>>>>>> prefers SRU to URN queries). >>>>> >>>>> I don't think that makes any sense at all, as it either (a) >>>>> prevents users from passing queries to end resources, > > Passing query to the URN resolver is relatively easy since the > functionality provided by the relevant resolvers (specified in RDS > or indicated more directly with HTTP URI) will be known. Assuming > that the users will be provided a GUI where they indicate the > services they want (which are then encoded in queries) people will > seldom require something that cannot be supplied. For instance, > when I see a link to the resource, I may indicate with the tick box > that I want rights metadata about the resource, or technical > metadata which will tell me which applications will be able to open > the file. > > It will be an interesting task to manage the situation in which > the query is somehow passed to the end resource. Do you mean the > browser/viewer/whatever in the client end of the process should be > able to fulfill the service request? I would not like to be the > person with the task to specify anything like full set of such > resolution services. Also, given the diversity of the applications > used, it will not be easy to guarantee that the client process does > not query services that cannot be supplied. > > As I see it, queries will primarily be used for passing service > requests to the URN resolvers. Such functionality makes a lot of > sense, at least from implementer point of view. But in order to > future proof the syntax it should also be able to specify queries > which should be processed in the client end. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJScc3VAAoJEOoGpJErxa2pas4P/ApHhw6bdDuHaMmqZlQbvw8p 5jm2BqsUP+ETTDU56f6zRAdlUYvqTMKGNNaMnpNmI2YAj+qYwBXpR31Vsruu4UXI hYueyNRb4cJOP13ORQe06BgOK9S0+VwuykcV0U63wjnL9IoYAC68EUGiwnkAYrVC IPQx7EZmRpoimfW6LdXNKVUdzt6DoxnFaZqVgpTMIbIW6Ivzv81BT0peWhF4H+ri RuI7Vmtaa8kZ9rMKaWmNkpDaPY03WghTP9mKOjh97hhRTSKhKXcUOyhqpVTzApRm 6CU1cO/rqwhIcGbTvWnhN9y1zC5j2eGD3umgI1zVL2ZVz7HIT+vMIf+Wxg2YizeQ GfR5/int/AIPCkFR8r2yN3yxWhR7o7jxvaSmAl0yx0SMRW/WyRM8ixWAiyGdwpVI /Izk+f9uWE8XkJurxRwY7S3J0zd0h1On8hSEZP+AjmkvF4kBv8Ys5ksz63Osl5M/ uvNXBlsV0nsdC/p9QAR/dz3SKzdi8o6PVdFAwFQtn2GSP3pVvuFWpgPn/XWQywY8 BfNRQ5SDavWqXgjxKjadQyvu+bxMyLoOa5W6QZKRHAOEekIg2IOHcO5p3SMY4nSi H4kauHR4pSHfrc/QAevhAlRdHxkrSVQqnO848FK+oVMdx2/W5TyOE2zDbg+2kb2H x8RGrh07maC+Y+a+XWDm =VWDP -----END PGP SIGNATURE----- From john-ietf@jck.com Thu Oct 31 07:00:54 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3116721E805D for ; Thu, 31 Oct 2013 07:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.739 X-Spam-Level: X-Spam-Status: No, score=-103.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpxETd4dV-9D for ; Thu, 31 Oct 2013 07:00:48 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 72C0611E8196 for ; Thu, 31 Oct 2013 07:00:42 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VbsnY-000LBx-6d; Thu, 31 Oct 2013 10:00:32 -0400 Date: Thu, 31 Oct 2013 10:00:27 -0400 From: John C Klensin To: Peter Saint-Andre , jehakala@mappi.helsinki.fi, Keith Moore Message-ID: <15DBB27F4BDA1975C9FDD985@JcK-HP8200.jck.com> In-Reply-To: <5271CDD5.1020501@stpeter.im> 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> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: urn@ietf.org Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:00:54 -0000 --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. best, john [1] http://www.rhyolite.com/anti-spam/you-might-be.html