From stpeter@stpeter.im Tue Dec 3 19:06:54 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 C52911ADFAD for ; Tue, 3 Dec 2013 19:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URV509RIqFAb for ; Tue, 3 Dec 2013 19:06:52 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA641AE00A for ; Tue, 3 Dec 2013 19:06:52 -0800 (PST) Received: from ergon.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AB0A34032B; Tue, 3 Dec 2013 20:06:48 -0700 (MST) Message-ID: <529E9C47.6040004@stpeter.im> Date: Tue, 03 Dec 2013 20:06:47 -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.1 MIME-Version: 1.0 To: Juha Hakala , John C Klensin References: <24637769D123E644A105A0AF0E1F92EFA43A6F29@dnbf-ex1.AD.DDB.DE> <527CBBDC.3010904@helsinki.fi> <038FA310EC49A589FEA82B24@JCK-EEE10> <528384E0.5080707@helsinki.fi> In-Reply-To: <528384E0.5080707@helsinki.fi> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Names and operatiions on named objects X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 03:06:55 -0000 I'm still working to fully understand this thread. In the meantime, I have a few comments inline. On 11/13/13 6:55 AM, Juha Hakala wrote: > > On 8.11.2013 17:25, John C Klensin wrote: >> --On Friday, 08 November, 2013 12:24 +0200 Juha Hakala >> wrote: >>> 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. Me, too. >> 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. That model makes sense to me. > 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). Juha, are people assuming that these future resolvers won't embed URNs in HTTP URIs, but instead will represent all of the information (in John's terms, the name and various attributes or parameters) into the URN alone? If so, why? What features of the next generation of resolvers lead people to think that the current model (embed URN into HTTP URI) can't do the job? Peter -- Peter Saint-Andre https://stpeter.im/ From juha.hakala@helsinki.fi Wed Dec 4 02:40:32 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 E01711AE0DC for ; Wed, 4 Dec 2013 02:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptdgDpycIAor for ; Wed, 4 Dec 2013 02:40:29 -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 27C4B1AE0E6 for ; Wed, 4 Dec 2013 02:40:26 -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 rB4AeL9V014564 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 4 Dec 2013 12:40:21 +0200 Message-ID: <529F0695.10702@helsinki.fi> Date: Wed, 04 Dec 2013 12:40:21 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20131028 Thunderbird/17.0.10 MIME-Version: 1.0 To: urn@ietf.org, Peter Saint-Andre References: <7639E40F70A558B99C1D2367@JcK-HP8200.jck.com> <52840784.2030302@stpeter.im> In-Reply-To: <52840784.2030302@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] The 3406bis template X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:40:33 -0000 Hello, On 14.11.2013 1:13, Peter Saint-Andre wrote: > ... 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 I have taken a look at this I-D. A few minor comments: In chapter 4.1 there are a few criteria for organizations that will assign URNs within a formal namespace. The first requirement - organizational stability and the ability to maintain the URN namespace for a long time - only needs to apply to the organization which registers the namespace. Especially when there is a single point where the URNs within the namespace are resolved (ISSN namespace is an example of this) the organizations which just assign URNs do not themselves need to be stable. The last two requirements - competency in name assignment & commitment to not reassign existing names - apply to both the registrant of the namespace and organizations which assign URNs within that namespace. Usually they are not the one and the same organization. These two requirements have been inherited from RFC 3406, and if we want to keep them, fine. But it is possible to merge the last two requirements together by saying that organizations which assign URNs within a formal namespace must familiar with (and stick to) the rules and regulations concerning the usage of the identifier system to which that namespace has been registered. In chapter 5.1 it might be useful to add an example to the first question: - The kinds of resources (e.g., books) identified by URNs assigned within the namespace I would not require an explanation why it is preferable to use URNs rather than some other technology. As an aside, the current example is not helpful since URNs are also URIs. The second point could be for instance - Why existing URN namespaces are not a good fit, especially if there is a namespace which covers same kinds of resources. For instance, NBN, like ISBN, covers books. But NBN should only be used to the book when it does not have an ISBN, so there is no overlap between these two namespaces. Section 7 should make it clear if some action is required on behalf of the registrants of the existing URN namespaces. My take on this is that all old namespace registrations will still be valid after the new namespace definition mechanism has been approved, but any revision to these old namespace registrations must be done according to the new procedure. Section 8 claims that registrants ("sometimes do not initially understand some of the subtleties of URN namespaces"). It might be better to say that they sometimes do not initially understand some of the subtleties (or requirements) of the URN namespace registration process. Namespaces themselves, as long as their features depend on the identifier systems behind them, must be familiar to any competent registrant. Otherwise the draft looks OK to me. Best regards, Juha -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From juha.hakala@helsinki.fi Wed Dec 4 03:29:54 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 765321AE241 for ; Wed, 4 Dec 2013 03:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wZNuWlKTUPt for ; Wed, 4 Dec 2013 03:29:51 -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 1D4501AE0FA for ; Wed, 4 Dec 2013 03:29:50 -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 rB4BTiU9028288 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 4 Dec 2013 13:29:45 +0200 Message-ID: <529F1228.9070207@helsinki.fi> Date: Wed, 04 Dec 2013 13:29:44 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20131028 Thunderbird/17.0.10 MIME-Version: 1.0 To: Peter Saint-Andre References: <24637769D123E644A105A0AF0E1F92EFA43A6F29@dnbf-ex1.AD.DDB.DE> <527CBBDC.3010904@helsinki.fi> <038FA310EC49A589FEA82B24@JCK-EEE10> <528384E0.5080707@helsinki.fi> <529E9C47.6040004@stpeter.im> In-Reply-To: <529E9C47.6040004@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Names and operatiions on named objects X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 11:29:54 -0000 Hello, On 4.12.2013 5:06, Peter Saint-Andre wrote: > I'm still working to fully understand this thread. In the meantime, I > have a few comments inline. I'll try to answer the questions below. Sometimes one face to face meeting could be worth many emails; I don't think that there is that much disagreement between us, but it seems that I have not been able to explain clearly enough the expectations the libraries have. Not being a native English speaker doesn't help :-(. >>>> 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. > Me, too. The basic assumption here is that a) there is a limited number of resolvers which can deal with any namespace or part of that namespace and b) for any URN, there is just one resolver which will deal with it. There are namespaces which will only ever have a single resolver (example: ISSN namespace or any other namespace with "dumb" identifier) which can of course be mirrored. Some other namespaces must be split into component parts which will each have its own resolver. For instance, URN:NBN has Finnish part which is taken care of by 1-n resolvers dealing with URN:NBN:fi and its sub-divisions. In these hierarchical namespaces, the top level resolver can harvest all the mapping information from sub-ordinate resolvers. The library community has also made experiments with harvesting across national NBN namespaces. When a resolver gets the plain vanilla URN (in e.g. form http://urn.fi/) it currently provides whatever service it can. Currently it is usually mapping from URN to single URL. A default service has never been specified, which IMO may become a problem in the future when there are more resolution services available, and different namespaces may have different preferences. Then a user who relies on multiple namespaces will get confused. If the user does not want the default service and there is a choice between two or more services, there must be a way to indicate what he wants. Assuming that URI query is used, then the resolver has to know how to deal with it. URN - URL mapping is something that can be done internally within the resolver with the mapping table. These tables are currently very simple things which specify URNs and corresponding up-to-date URLs. In the future we'll have a lot more information aiding the resolution. For instance, if we have an URN belonging to the URN:NBN:FI -namespace, and the user wants bibliographic data about the identified resource. The resolver must know that for any URN belonging to that sub-namespace, if the resolution service requested is URC (bibliographic information about the resource) the URN + query has to be mapped into a query expressed in SRU protocol which is sent into the appropriate port in the Finnish national bibliography. Each URN namespace (or sub-namespace) must specify how to supply the services supported within that namespace. This is not as complicated as it sounds, since we are dealing with limited number of sophisticated identifier systems and limited number of services. These services will vary over time, and the protocols used to supply them will change. The critical thing is that the URI query syntax remains the same once it has been fixed. Then, 100 years from now, if a user wants a citation of the resource (instead of the thing itself) she can still use the same URN and query, even though the underlying protocols and applications have changed many times over. > >>> 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. > That model makes sense to me. This is what we currently have. But with URNs we can and we must go further. > >> 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). > Juha, are people assuming that these future resolvers won't embed URNs > in HTTP URIs, but instead will represent all of the information (in > John's terms, the name and various attributes or parameters) into the > URN alone? For the time being we definitely need HTTP URIs. And of course we can carry on using them, if the resolver discovery service does not emerge. However, if and when RDS is established, it has to be possible to "port" whatever we are doing into this new environment. > > If so, why? What features of the next generation of resolvers lead > people to think that the current model (embed URN into HTTP URI) can't > do the job? With the current system we must have resolvers in fixed locations such as http://urn.fi. Given the limited number of resolvers, this is not an impossible burden. The resolver URLs are very stable ("cool" URIs par excellence) and if they change, making DNS redirects for handful of addresses is not hard. But in the very long run, it would be better if we could use just plain URNs and leave the resolver tracking to RDS. Then there would be nothing protocol dependent in the name, and resolvers could be moved around as long as the RDS is able to keep track of them. Juha > > Peter > -- 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 moore@network-heretics.com Wed Dec 4 08:47:18 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 3F8DE1AE2EE for ; Wed, 4 Dec 2013 08:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0eHVISXWVyr for ; Wed, 4 Dec 2013 08:47:14 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 829FA1ADFB4 for ; Wed, 4 Dec 2013 08:47:14 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6C78221584; Wed, 4 Dec 2013 11:47:11 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 04 Dec 2013 11:47:11 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=QARkxeUF9h62kQqGESfTLW WAO1k=; b=uthDasaACGpaDuqDf43q+rY5JHzObxcvzYmeUPsnZ2uttiyusffyXJ 8FIcPcnEvld6TNBRmNGcSyTtp5qnxAQ1y6Tx1lzEKqrW5ZIocSrM3JOA48sv/PkE GrHc7La1X6fpuvVVcvIa3OcU5fUrk8CjgxM/nLWTlSb5a0csZ4JXg= X-Sasl-enc: PWn9Pl7kYsXyKsQmMk0BmHaJT6gCO2ZhVKiZYjt2e8YJ 1386175630 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id A33CB6800A8; Wed, 4 Dec 2013 11:47:09 -0500 (EST) Message-ID: <529F5C89.5010905@network-heretics.com> Date: Wed, 04 Dec 2013 11:47:05 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Peter Saint-Andre , Juha Hakala , John C Klensin References: <24637769D123E644A105A0AF0E1F92EFA43A6F29@dnbf-ex1.AD.DDB.DE> <527CBBDC.3010904@helsinki.fi> <038FA310EC49A589FEA82B24@JCK-EEE10> <528384E0.5080707@helsinki.fi> <529E9C47.6040004@stpeter.im> In-Reply-To: <529E9C47.6040004@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Names and operatiions on named objects X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 16:47:18 -0000 On 12/03/2013 10:06 PM, Peter Saint-Andre wrote: > I'm still working to fully understand this thread. In the meantime, I > have a few comments inline. > > On 11/13/13 6:55 AM, Juha Hakala wrote: >> On 8.11.2013 17:25, John C Klensin wrote: >>> --On Friday, 08 November, 2013 12:24 +0200 Juha Hakala >>> wrote: > > >>>> 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. > Me, too. > >>> 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. > That model makes sense to me. > >> 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). > Juha, are people assuming that these future resolvers won't embed URNs > in HTTP URIs, but instead will represent all of the information (in > John's terms, the name and various attributes or parameters) into the > URN alone? > > If so, why? What features of the next generation of resolvers lead > people to think that the current model (embed URN into HTTP URI) can't > do the job? > > Peter > > Peter, The original purpose of URNs was to serve as a location-independent identifier for a resource that was potentially network-accessible. Yes, URNs can be used to name resources that aren't network-accessible and never will be. But URNs were created because we observed, very early in the history of the web, that resource identifiers with embedded "locations" (i.e. domain names) were almost inherently not indefinitely "persistent". So the idea of embedding URNs in HTTP URIs was never the intended way to use URNs. It was a hack to work around the fact that URNs weren't (yet) supported by web browsers. Embedding a URN in a HTTP URI results in a URI that was assumed to be unlikely to be persistent. However, I don't recall that the idea was ever that a URN should be able to include "the various attributes and parameters" that would cause the resulting identifier to be interpreted as an identifier for, say, (some of) the resource's metadata rather than the resource itself. The above is a summary of my memory of the thinking (circa mid 1990s) that went into the design of URNs and related services. A number of assumptions have changed a bit since then, but there still seems to be a need (and demand) for identifiers which provide assurance of "persistence" and are clearly distinguished from other identifiers for which persistence is not assured. (And there's still some reason to doubt that URI with an embedded URN will be persistent indefinitely.) --- In principle, a URI names a resource, and doesn't specify what you can do with that named resource. In principle, HTTP [+WebDAV] (for example) supports a large number of "methods" which can operate on a resource, and some other access protocols also support multiple methods. But in practice, the most common operation on a URI is "GET" - i.e. download the contents of the resource. Usually this is followed by some sort of interpretation and/or presentation of the resource that is obvious from the context in which the URI is being used. GET is attractive, in part, because it requires no parameters other than the URL itself. Yes, there might be some content-negotiation that affects the data that is obtained from a GET, but to the extent that it happens, the additional information needed is obtained "by context". It's not part of the GET itself. Think about the various contexts in which URLs are used. If the expected method is GET, the URL can be just a parameter to something like an A or IMG tag. But if the expected method is almost anything else, the specification of how to interact with that resource becomes a lot more complicated. Instead of just specifying a URL in a parameter, you typically have to write _code_ that manages the interaction. (For this reason, there's some pressure even in the URL-only world to shoehorn additional information into GET. It's why you so often see URLs consisting of some base URL with a lot of additional stuff tacked on the end, either as "form data" or as additional components of the "path".) Because GET is so popular and obviously useful, a lot of us think that it should be possible to GET a resource named by a URN - at least, if that resource is something for which GET makes sense: it's network-accessible, and it has content that can be downloaded without additional explicit information being supplied. For example, an HTML document should someday be able to have URNs in any of the contexts in which GET is the implicit operation, with the reasonable expectation that browsers will do the right thing, and all of the code necessary to do the right thing will be embedded in the browser. This may seem like a dream, but it can work. All it needs is for every namespace (for which GET on its URNs potentially makes sense) to support a standard resolution protocol and some number of resolution servers, and for those resolution servers to be associated with that namespace in DNS. If the resolution protocol and servers support other functionality beyond facilitating GET, so much the better. (Or to state it from a different point-of-view: I get the impression that there is interest in resolution services for several different URN namespaces. In addition to whatever other functionality those resolution services provide, I would like it if there were enough of a common standard among these resolution services to facilitate browser/client implementation of GET, for those URNs for which GET makes sense. ) Of course GET isn't the only method that we'd like to be able to use with resources named by URNs, but GET is the method that is the most broadly applicable across the range of network-accessible resources and access protocols. If what you want to do instead with a particular URN is, say, POST, you need to be able to find a resource location and access protocol for that URN, for which POST is defined. But with URNs, just as with URLs, chances are good that if you need to facilitate interaction with a resource using some other method than GET, you're going to be writing code to do that. You're going to be writing code because the interaction is no longer simple and one-step and/or entirely determined by the URI and context: it may involve multiple interactions with the resolution server, and your code may have to make decisions after each interaction based on the data obtained. So my conclusions are: - We (IETF URN WG) should resume work toward a URN architecture and infrastructure that facilitate GET on URNs, for those URNs for which it makes sense. This includes a standard resolution protocol with the ability to support queries for resource locations (whatever else it supports), and a means of registering resolution servers such that browsers and other clients can find resolution servers for particular namespaces. If DNS works to do this, that's great, if it doesn't work, pick something else. - I haven't seen a need to be able to specify resolution parameters as part of URNs, because I think that the vast majority of things that aren't GET will require writing code anyway. So (for example) if what you want to do is obtain the output of querying a resolution service for something or another, instead of having a link to something that consists of URN + resolution parameters, you're probably going to need to write some JavaScript or other code to actually interact with the resolution service. - Based on the above, I haven't seen a need to overload existing URI query syntax to allow resolution parameters to be supplied with URNs. So when the query syntax is used with URNs, it can unambiguously mean a query that is supplied to the resource named by the URN, rather than parameters passed to the resolution server. [*] Keith [*] However, what any resolution server does with query parameters passed to it, is its own business, unless/until that interface is standardized. So for example if there's a resolution service for URN namespace "abc" that is located at URL abc.org, and it accepts queries of the form GET http://abc.org/resolver/urn%3Aabc%3Axyz?request=metadata There's nothing wrong with that, because the "request=metadata" query is part of the URL passed to the resolution service, and not part of the URN. If a browser or other client were presented with a URN+query like "urn:abc:xyz?foo=bar" it would first have to query the resolution server, perhaps using a URL like: GET http://abc.org/resolver/urn%3Aabc%3Axyz?request=locations (note that foo=bar is omitted) And then, having found one or more suitable locations, the client could send the query over HTTP to a URL obtained from the resolution server: GET http://example.com/location-of-resource?foo=bar From L.Svensson@dnb.de Thu Dec 19 22:42:47 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 CB75B1ADFF4 for ; Thu, 19 Dec 2013 22:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OGzFkjqXgWZ for ; Thu, 19 Dec 2013 22:42:46 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id CBA721ADFD7 for ; Thu, 19 Dec 2013 22:42:45 -0800 (PST) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id A22947EEEC for ; Fri, 20 Dec 2013 07:42:42 +0100 (CET) From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: urn-wg meeting at IETF 89? (was: RE: Re: [urn] Names and operatiions on named objects) Thread-Index: Ac7841HxD6a4i+VNRmqPzy/EW1K+zg== Date: Fri, 20 Dec 2013 06:42:40 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA43BE786@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.76] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [urn] urn-wg meeting at IETF 89? (was: RE: Re: Names and operatiions on named objects) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 06:42:48 -0000 On December 4, 2013, Juha wrote: =20 > On 4.12.2013 5:06, Peter Saint-Andre wrote: > > I'm still working to fully understand this thread. In the meantime, I > > have a few comments inline. >=20 > I'll try to answer the questions below. Sometimes one face to face > meeting could be worth many emails; I don't think that there is that > much disagreement between us, but it seems that I have not been able to > explain clearly enough the expectations the libraries have. Not being a > native English speaker doesn't help :-(. Independent of language issues: My impression, too, is that an F2F could he= lp making the positions clearer. This is even more so if we consider Keith'= s comments from December 4. I could possibly get funding to go to London fo= r IETF 89 if there will be a urn meeting. Are there any plans? Best, Lars=20 From andy@hxr.us Fri Dec 20 07:29:07 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 B62101ADF89 for ; Fri, 20 Dec 2013 07:29:07 -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 HXwpzWJx5Mtb for ; Fri, 20 Dec 2013 07:29:05 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id A4FB21ADF82 for ; Fri, 20 Dec 2013 07:29:05 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id hz1so2751853pad.40 for ; Fri, 20 Dec 2013 07:29:03 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=t4MkgQnbbNjb7N1bjhLkSZqcyaO8oMO7qkjFI/J3dqs=; b=FuiE+pMoBeaFOlNRRDs8VYuvU2Ul5sgot9rWThZS15QJYXN+Woiq3bovv9vLJCD0lv biLSikxygz5rFcO1WoXR5RNjqc1xGIn1obAcMz4cAFu3uMmeAJpsB2z+B3NICdzcuEmd uV06UdaAsi9h9aL+/WGR4RSAlU2WHID7cbm0ksNTiLVYjU6K5GShRUO7/uPwjGzSC+vv w/5I4VX9BD8aeIcpFjjlSfZolGJ/RkuuotO42tnCoc+bRodljJp0hlNx9ISSYwQLxDHE Vbd6NisPkDmW0PZmgr9noKIVLjJ7CIG1RrQsYuls231ZYc1L+6+W75zX4ZVZ2HEkXBUm n6Cw== X-Gm-Message-State: ALoCoQm/7NY4x87pFeyr8JeE8rsVE63xr2MZUu8TQRNkFB2IVUDbe0Uq+wLOgQP9ghSEzMWr06Vi MIME-Version: 1.0 X-Received: by 10.68.173.132 with SMTP id bk4mr9061110pbc.169.1387553343392; Fri, 20 Dec 2013 07:29:03 -0800 (PST) Received: by 10.68.16.196 with HTTP; Fri, 20 Dec 2013 07:29:03 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA43BE786@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFA43BE786@dnbf-ex1.AD.DDB.DE> Date: Fri, 20 Dec 2013 10:29:03 -0500 Message-ID: From: Andrew Newton To: "Svensson, Lars" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "urn@ietf.org" Subject: Re: [urn] urn-wg meeting at IETF 89? (was: RE: Re: Names and operatiions on named objects) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 15:29:07 -0000 Lars, At present there are no plans for a session in London. Or hope was to have this all wrapped up by then. But plans can change. Let me discuss it with our AD and document authors. -andy, co-chair On Fri, Dec 20, 2013 at 1:42 AM, Svensson, Lars wrote: > On December 4, 2013, Juha wrote: > >> On 4.12.2013 5:06, Peter Saint-Andre wrote: >> > I'm still working to fully understand this thread. In the meantime, I >> > have a few comments inline. >> >> I'll try to answer the questions below. Sometimes one face to face >> meeting could be worth many emails; I don't think that there is that >> much disagreement between us, but it seems that I have not been able to >> explain clearly enough the expectations the libraries have. Not being a >> native English speaker doesn't help :-(. > > Independent of language issues: My impression, too, is that an F2F could = help making the positions clearer. This is even more so if we consider Keit= h's comments from December 4. I could possibly get funding to go to London = for IETF 89 if there will be a urn meeting. Are there any plans? > > Best, > > Lars > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn