From nobody Sun Aug 3 11:36:36 2014 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 3D7231A0B04 for ; Sun, 3 Aug 2014 11:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 E2jf2zZHYpp8 for ; Sun, 3 Aug 2014 11:36:32 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4711A0194 for ; Sun, 3 Aug 2014 11:36:32 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XE0Z5-000EFU-Iu for urn@ietf.org; Sun, 03 Aug 2014 14:31:27 -0400 Date: Sun, 03 Aug 2014 14:36:31 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <980F023C1C23086B74A5FD42@[192.168.1.128]> 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 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/zxgKRkzJD556JmiThxRr3hZANa8 Subject: [urn] Where I think we stand 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: Sun, 03 Aug 2014 18:36:35 -0000 Hi. I have read, but deferred responding to, the notes posted in the last two weeks in the hope of getting a revised version of the "separation" document together to reflect the "separate semantics but preserve syntax and URN identity as part of the URI family" conclusion I think we reached in Toronto. As a preview, I've changed the tentative title to reflect that change: it now "URN Semantics Separate from Generic URIs". If anyone has a better idea, please suggest it. I'm going to describe it as "the separation draft" below and for the time being. The working draft version is now in the hands (or at least mailboxes) of Andy, Barry, and Peter. I'll post it as soon as they give me the go-ahead or minutes are posted that I can check the changes against. Unless they advise/instruct otherwise, the next version will be draft-ietf-urnbis-urns-are-not-uris-02 even though that is not what it about any more. One of my conclusions from both the recent email threads and the Toronto discussions is that there is considerable disagreement among usually-sensible people about what 3986 actually says. Some of us believe the comparison "ladder" is sequential and normative with the only important choice being how far one goes up it, others that it is just a list of example types of comparisons about which applications can reasonably pick and choose. Some of us see some of the examples as restrictive, others as just examples and so on. Either as a result of those differences or for other reasons, some of us see 3986 as semantic-laden, others see it as containing almost no normative semantics but merely discussions of how some fields might be used. The observation that many (perhaps most) implementations of generic URIs do not pay much attention to 3986's semantic strictures (or specific URN syntax strictures there), but instead either rely on 3986 syntax only or on syntax closer to the "scheme:" model doesn't "prove" those constraints are not present (or that they are), only that we are even more justified than we might be otherwise in pushing them aside (if they exist) rather than feeling constrained by them. I don't see any way to resolve those differences in readings other than to make them irrelevant (which the "don't worry about the semantics" approach seems to me about) or to do a complete revision of 3986 that would eliminate any ambiguity. To me, there are three problems with the latter: it is far out of scope for this WG, it would (at best) take a long time, and it would require dealing with other groups who want to reinterpret or obsolete 3986. Perhaps the important thing is that, if one believes that 3986 imposes constraints on things that the WG believes need to be done with URN, then the separation draft is important. If it does not, then it is at worst harmless. As was pointed out in Toronto, we don't need to publish the thing, only to have it handy for later consideration of whether it is needed and as a ready defensive measure if someone claims that another URNbis document is unacceptable because it somehow violates 3986. I'll respond separately to Keith's and Leslie's later "Preferences" notes. john From nobody Sun Aug 3 12:21:03 2014 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 2DD4E1ABB2D for ; Sun, 3 Aug 2014 12:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 kPJbd5fQ1GZ5 for ; Sun, 3 Aug 2014 12:20:59 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897031ABB18 for ; Sun, 3 Aug 2014 12:20:59 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XE1G0-000EJz-SM; Sun, 03 Aug 2014 15:15:48 -0400 Date: Sun, 03 Aug 2014 15:20:52 -0400 From: John C Klensin To: Keith Moore , "Leslie Daigle (TCE)" , urn@ietf.org Message-ID: In-Reply-To: <53D62231.9020602@network-heretics.com> References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE> <53D27424.2010802@thinkingcat.com> <53D277EA.30601@gmx.de> <53D4ABAF.5040303@it.aoyama.ac.jp> <53D62231.9020602@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/fNz6nhfjcz2N38bO2owMrK_RXUk Subject: Re: [urn] Preferences and Choice matrix 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: Sun, 03 Aug 2014 19:21:02 -0000 --On Monday, 28 July, 2014 06:13 -0400 Keith Moore wrote: > On 07/27/2014 03:35 AM, "Martin J. D=C3=BCrst" wrote: >> I actually think it's utterly consistent with RFC 3986. RFC >> 3986 only says that it's "scheme definable". This means that >> a scheme can define what it wants. >>=20 > Yes, 3986 allows a scheme to define what it wants. The > reason that "?" should not have a namespace-specific meaning > is not because 3986 prohibits it. >=20 > Some reasons that "?" should not have a namespace-specific > meaning are: >... Can I encourage you to be a little bit more specific about what you are talking about and specifically what you mean by "meaning"? For example, I don't have much problem with saying "ok, there are things that, for lack of a better term, we will call 'queries'. From the standpoint of syntax the query collection starts with "?" and continues to the end of the URI string or the first occurrence of '#'. After that, their interpretation is pretty much an NID problem". Up to the last sentence that is, I think, pretty much what 3986 says. The last sentence is problematic is one believes that 3986 makes query interpretation a per-scheme problem that can't be delegated to NID registrations. =20 That interpretation is more than sufficient to make generic URI parsers, and even more specific generic URN parsers feasible. Where things get complicated is when wants to specify syntax or interpretation/semantics _within_ the query string. I can see doing that for at least one more layer on an "all-URNs" basis, but believe we would have to be very careful about extensibility. Proposals to create a closed list of keywords with "all-URN" interpretations scare me because I don't think we can get that right in a single attempt. But, if one can specify that on a per-NID basis, I don't see any problem even though I personally think it would be desirable to push a level further down (see below). Similarly, in a world of generalized URNs, I think one needs to be very careful about rules about what is included in URN equality or about the context in which something is evaluated. If those things are specified for all URNs (or all URIs), then I think we are likely to get into trouble given some of the examples Juha, Lars, and others have given. On the other hand, if they are pushed down to the NID level, then the registry (or some information without the query string itself) has to be consulted before performing those interpretations. That isn't impossible, but it would certainly be inconvenient for many purposes (that statement is intended to be consistent with Leslie's "not only tricky, it's likely to lead to heartbreak", which which I agree. One could pretty much substitute "fragment/ #" or "/" with some appropriate words for "query / ?" above without changing much, if anything. --On Wednesday, 30 July, 2014 11:11 -0400 "Leslie Daigle (TCE)" wrote: (paragraphs rearranged for my convenience) > Thumbwrestling about interpretations of RFC3986 is distracting > from the hard problem, IMO. Agreed. See my prior note about the new version of the separation draft. In retrospect, the Toronto meeting was disappointing because we ended up spending almost all of our time on that issue and hence couldn't get to the ones that you and Keith are now raising. > Getting beyond the meta, I'd like to see actual proposals for > how to handle facets (whether using the "?" and "#" or not) in > a way that works consistently across all persistent > identifiers. > I don't have a proposal to kick off the discussion, as I am a > self-admitted skeptic :-) Various of us have tried to identify types of URNs and, in some cases, the differences among their requirements. At other times, we have tried to predict the future, both in terms of requirements and in terms of whether new types will be discovered. Against that background, the only thing I know how to propose is fully general, e.g., the four-tuple Service Request described in Appendix B of draft-ietf-urnbis-urns-are-not-uris-01 and some earlier notes. I hope we can be less general than that, but I'm not convinced yet, especially if strong equality comparisons for URNs (high on the "fewer false negatives" ladder but without relying on comparison of retrieved content are desired. It would, FWIW, be completely rational to use "?" to introduce service requests that are interpreted "outside" the URN and URN comparisons and "/" for ones that are interpreted "inside" the URN and that count in comparisons if that distinction were sufficient. If it were and we went down that path, the four-tuple would drop to a three-tuple. However, to remove some of the noise from that discussion, I suggest it would be useful to concentrate on what we want those Service Requests to be able to do, specify, and how and where they are interpreted, rather than on their syntax. > To further remove noise from that discussion, I think having > the discussion in the abstract -- e.g., for a new > [UR]identifier, as Joe Hildebrand suggested at the meeting > last week -- might be helpful. Works for me with one qualification, which is almost the same qualification I would apply to "use '/' and not '?'". I believe we are stretching the patience of those who have been waiting for us to bring this work to a useful and usable conclusion but who have been assigning and using millions of URNs in the meantime. The result of pushing them too far is fairly clear -- we end up with a forked standard published by a group that has far more credibility in parts of the URN-using community than the IETF does. Except that most of that community it far too polite, I think the effect of any "don't use URNs, use URXs or XXNs instead and you can start converting your millions of URNs now" would be a lot of rude language and precisely that form. Put differently, if thinking about this as a new URI type helps us move things forward, that is fine, but an actual proposal that URNs, or URNs beyond what 2141 allows, be actually replaced by such a type, would be likely to be ignored in the marketplace (or worse). john =20 From nobody Tue Aug 5 08:50:37 2014 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 BA1261B2A3C for ; Tue, 5 Aug 2014 08:50:35 -0700 (PDT) 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 G4q7n6quIE8D for ; Tue, 5 Aug 2014 08:50:34 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775911B2A28 for ; Tue, 5 Aug 2014 08:50:34 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id r10so1568580pdi.20 for ; Tue, 05 Aug 2014 08:50:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=7l9ZmvI1oZotl56niagXNW8vQyTAYa0Gl2NlQY+Ho8M=; b=Fr+MLSNSwa46YmJq3bPJmgf1zrflnPBX0V5ivqXHEZxRYdpHPeMsvrIZNsB9MxAK+x PODa1EQ79FjvAttaqXYGZev1nXjNfovd2fZF3doTWuYzrXbbyKvbulFsjCD/CI1Q4KyP uHcvtriU1420kYIQnVkDRipel4FaZexjA51E7l8j4f5KzGCgiG3M2psF5w6ub4IpylgX 3oS8QdihlDUWjVeZAmP0j5QmkRAGi2iPQuioxMuLTlsmI8qa8/HQvOTN1skayX1qy9NR MBUQYTYYT/ZCeMIS8X7qfHvqRxPaPcINUBmkJMz34APQ2dabrrEADmwrNqN1WmyayPFV ILsQ== X-Gm-Message-State: ALoCoQlIsDTboBvlWDkPERSLphIvfB85vOMECvb0KKBAkPbAWCkqNby83RNztjRf7y31aCuNcoIn MIME-Version: 1.0 X-Received: by 10.68.93.101 with SMTP id ct5mr5287479pbb.27.1407253834099; Tue, 05 Aug 2014 08:50:34 -0700 (PDT) Received: by 10.66.27.5 with HTTP; Tue, 5 Aug 2014 08:50:34 -0700 (PDT) X-Originating-IP: [192.149.252.11] Date: Tue, 5 Aug 2014 11:50:34 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/pCv0uIu_I_puIvUVDRrFMWy8DxA Subject: [urn] Consensus Question Regarding Direction of Work 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: Tue, 05 Aug 2014 15:50:35 -0000 During our recently completed meeting in Toronto at IETF 90, we achieved necessary consensus from the meeting participants to focus our energies on the semantics of the components of URNs with a hopeful goal of keeping syntax compatible with URIs. In other words, the separation of URNs from URIs is to be about semantics instead of syntax (the implication being that we are not wholly separating URNs from URIs). The driving mechanism for this work will be a revision to the separation Internet-Draft as mentioned by John Klensin. That draft may or may not turn into an RFC depending on the needed changes to 2141bis. As is IETF practice, I am seeking input from individuals on this mailing list regarding this decision. Specifically, I am seeking objections that have not been previously raised. -andy co-chair From nobody Tue Aug 5 09:05:14 2014 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 C6EF11B2A60 for ; Tue, 5 Aug 2014 09:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 JRo8cruMeny3 for ; Tue, 5 Aug 2014 09:05:03 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCEA1B2A35 for ; Tue, 5 Aug 2014 09:05:02 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s75G4pw4028148; Tue, 5 Aug 2014 17:04:51 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s75G4nAQ018707; Tue, 5 Aug 2014 17:04:49 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s75G4o4K006846; Tue, 5 Aug 2014 17:04:50 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s75G4nC3006842; Tue, 5 Aug 2014 17:04:49 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Andrew Newton References: From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 05 Aug 2014 17:04:49 +0100 In-Reply-To: (Andrew Newton's message of "Tue\, 5 Aug 2014 11\:50\:34 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/4-KTHcwAwDh_JeN3cn4HYe5dIZ8 Cc: "urn@ietf.org" Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Tue, 05 Aug 2014 16:05:10 -0000 Andrew Newton writes: > During our recently completed meeting in Toronto at IETF 90, we > achieved necessary consensus from the meeting participants to focus > our energies on the semantics of the components of URNs with a hopeful > goal of keeping syntax compatible with URIs. That's hopeful. > ... > I am seeking input from individuals on this mailing list regarding > this decision. Specifically, I am seeking objections that have not > been previously raised. I support this decision. I continue to think that the key to making progress is a careful focus on what it is that the constituency seeking changes need URNs to _do_ for them, and that pretty much accords with the consensus you report above. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Tue Aug 5 12:48:00 2014 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 C89F21A0173 for ; Tue, 5 Aug 2014 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 pU2yiNnk9aN3 for ; Tue, 5 Aug 2014 12:47:57 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAED1A0158 for ; Tue, 5 Aug 2014 12:47:56 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id b7f21o0031HzFnQ5E7nw4K; Tue, 05 Aug 2014 19:47:56 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta14.westchester.pa.mail.comcast.net with comcast id b7nw1o0071KKtkw3a7nwgs; Tue, 05 Aug 2014 19:47:56 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s75JlqaZ001519 for ; Tue, 5 Aug 2014 15:47:56 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s75I3IM2007097; Tue, 5 Aug 2014 14:03:18 -0400 Date: Tue, 5 Aug 2014 14:03:18 -0400 Message-Id: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org In-reply-to: (andy@hxr.us) References: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407268076; bh=wj9eetKW257h4sg1lbp4QdFMQ6fucXz2vVqXH+2lfag=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=KyUc3gXL6+ZiWQaoF0f854/TJEL/4p6bEerMndKDIC3C6UfrQmnpeiky7kGgiub09 ie4UXVuvXwsz5/9iAbtJXh5Ed/urrMa1pHM8EiTnqfULnobZLtWp+1DgVPXEAuua+8 BpqGII0j40H/Zu8ehZxSmddb9XfTfLbv3xP/qHf5+WOKCiU62aFZ20lUZGdlbE8yGb 9JfKLSFRU9TSvk7RONPcJFmdNiV28ChXJQaZpcD/Ya4QGeUhnm98o+9PBl1jjK+LQH y8eBnWYLFgODK0esbT9Yv7GwPtPyCN7sqJpiDK1nsLUX8doKcBCjdjk2MDZbxdGL2K F8rZ58ako+wpQ== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1FqYIqYWfXLSKBbECYMG6XgiUUs Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Tue, 05 Aug 2014 19:47:59 -0000 > From: Andrew Newton > > During our recently completed meeting in Toronto at IETF 90, we > achieved necessary consensus from the meeting participants to focus > our energies on the semantics of the components of URNs with a hopeful > goal of keeping syntax compatible with URIs. In other words, the > separation of URNs from URIs is to be about semantics instead of > syntax (the implication being that we are not wholly separating URNs > from URIs). I agree that is a good way to progress. Maintaining syntactic compatibility is an important feature, but we have a great deal more freedom regarding semantics. As Henry Thompson said, it's important to get input regarding "what it is that the constituency seeking changes need[s] URNs to _do_ for them". Dale From nobody Wed Aug 6 01:02:29 2014 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 3EF341B2CC7 for ; Wed, 6 Aug 2014 01:02:26 -0700 (PDT) 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 JVNIcwJemb8f for ; Wed, 6 Aug 2014 01:02:20 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872381B2CC0 for ; Wed, 6 Aug 2014 01:02:18 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s7682Hc3027526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 6 Aug 2014 11:02:18 +0300 Message-ID: <53E1E107.1080302@helsinki.fi> Date: Wed, 06 Aug 2014 11:02:15 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: urn@ietf.org References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> In-Reply-To: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/nC4JXpwY7PTOa7Sg3_WrlLmnUHo Subject: Re: [urn] Consensus Question Regarding Direction of Work 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, 06 Aug 2014 08:02:26 -0000 Hello Andy, I am glad that the meeting in Toronto was productive. On 5.8.2014 21:03, Dale R. Worley wrote: >> From: Andrew Newton >> >> During our recently completed meeting in Toronto at IETF 90, we >> achieved necessary consensus from the meeting participants to focus >> our energies on the semantics of the components of URNs with a hopeful >> goal of keeping syntax compatible with URIs. In other words, the >> separation of URNs from URIs is to be about semantics instead of >> syntax (the implication being that we are not wholly separating URNs >> from URIs). > I agree that is a good way to progress. Maintaining syntactic > compatibility is an important feature, but we have a great deal more > freedom regarding semantics. + 1. It should be possible to achieve what the developers of the URN-based systems need just by adjusting semantics. Accommodating semantic requirements of the identifier systems expressed as URNs is, at least in principle, easy: Namespace Specific String should contain only the identifier itself (in an encoded form, if necessary); nothing more, nothing less. > > As Henry Thompson said, it's important to get input regarding "what it > is that the constituency seeking changes need[s] URNs to _do_ for > them". To name the two most important practical things, we need to be able to - use URI query to pass resolution related parameters to URN resolvers, and - use URI fragment to enable citing / referencing of identified resources. This can be done iff we agree that query and fragment are not part of the NSS (that is, in the URN context they do not identify anything). As an extra bonus, alignment of the URN syntax with the URI syntax should remove the impression that URNs are out of date or deprecated by URIs. Juha > > Dale > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Wed Aug 6 03:39:00 2014 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 58B1E1B290B for ; Wed, 6 Aug 2014 03:38:57 -0700 (PDT) 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 ri0iJ6k4qmAQ for ; Wed, 6 Aug 2014 03:38:54 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CF41B290E for ; Wed, 6 Aug 2014 03:38:53 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s76AcqSU001291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 6 Aug 2014 13:38:52 +0300 Message-ID: <53E205BA.8060300@helsinki.fi> Date: Wed, 06 Aug 2014 13:38:50 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: urn@ietf.org References: <53CCE38B.7070609@it.aoyama.ac.jp> <4351aa24205e455e88c5c31a98257b62@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: <4351aa24205e455e88c5c31a98257b62@BL2PR02MB307.namprd02.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/aTgTrp7hJ62AliXMSNECrGmaMFM Subject: Re: [urn] Query choices 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, 06 Aug 2014 10:38:57 -0000 Hello, On 22.7.2014 5:43, Larry Masinter wrote: > RFC 2141 URN Syntax is standards track, so the bar for updating > should follow the rules for updating standards track document: > based on implementation experience. If there is implementation > experience with using ? in URNs, which would justify C, D, or E, > please cite it. If there is none, stick with B. There are implementation experiences from other persistent identifier systems. For instance, with ARK the users can request from the resolver descriptive metadata about the resource by adding "?" to the ARK, or find out what the preservation commitment of the organization holding the document is by adding "??". DOI and Handle are also using URI query, but services available and syntax applied for requesting them are not the same ARK has implemented. There are no implementation experiences from URN community, mainly since the URN syntax does not allow us to use URI query, and implementers have decided to wait until the syntax is modernized. As a rule existing URN resolvers are "dumb", they support only default service (mapping from URN to single URL). There are no widely implemented means of passing service related parameters to resolvers. Possibility of using URI query for passing resolution related parameters to the resolvers may change the situation to the better quite soon. If there is no agreement on query usage in URN syntax, the implementers may run out of patience and follow the example of ARK and Handle/DOI. Within the PID community we have discussed a lot about interoperability of persistent identifier systems. Aligning query related principles and practices (as far as possible / sensible) is one step into this direction. Juha > > Larry > -- > http://larry.masinter.net > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Wed Aug 6 10:17:24 2014 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 12E491A0364 for ; Wed, 6 Aug 2014 10:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 aWm9BckydT3c for ; Wed, 6 Aug 2014 10:17:19 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA141A037D for ; Wed, 6 Aug 2014 10:17:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by gateway1.nyi.internal (Postfix) with ESMTP id DCC3A2262C for ; Wed, 6 Aug 2014 13:17:16 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 06 Aug 2014 13:17:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=mPPzYUoedLEmA5DtNrEgJn Ceqfw=; b=Ic9cGdLLkmu2JRUfVt2a745B0UJP6nkKNP+Q2f70c439wQqncRowZB O4KVON124ItWMcrlwZ1MFkC2xfdZ8lNMi1JvVxZcISopTFyV35AabE01Oky4RxrV MkkFBx//P9rczHdb2qZUDmJmNRdGTJ0q0oIt5FBn2yKVnU4G6O18Q= X-Sasl-enc: quMWCxdICcWEd1UiCBZn9iUVCs+EIUn7KHp/e+dpPrDD 1407345436 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D414C68015B; Wed, 6 Aug 2014 13:17:15 -0400 (EDT) Message-ID: <53E2630B.6000002@network-heretics.com> Date: Wed, 06 Aug 2014 13:16:59 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> In-Reply-To: <53E1E107.1080302@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/TwsP9NLCQFWbMbKwD_Cc3k4Iqcs Subject: Re: [urn] Consensus Question Regarding Direction of Work 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, 06 Aug 2014 17:17:22 -0000 On 08/06/2014 04:02 AM, Juha Hakala wrote: > Hello Andy, > > I am glad that the meeting in Toronto was productive. > > On 5.8.2014 21:03, Dale R. Worley wrote: >>> From: Andrew Newton >>> >>> During our recently completed meeting in Toronto at IETF 90, we >>> achieved necessary consensus from the meeting participants to focus >>> our energies on the semantics of the components of URNs with a hopeful >>> goal of keeping syntax compatible with URIs. In other words, the >>> separation of URNs from URIs is to be about semantics instead of >>> syntax (the implication being that we are not wholly separating URNs >>> from URIs). >> I agree that is a good way to progress. Maintaining syntactic >> compatibility is an important feature, but we have a great deal more >> freedom regarding semantics. > > + 1. > > It should be possible to achieve what the developers of the URN-based > systems need just by adjusting semantics. Accommodating semantic > requirements of the identifier systems expressed as URNs is, at least > in principle, easy: Namespace Specific String should contain only the > identifier itself (in an encoded form, if necessary); nothing more, > nothing less. I agree with the last sentence. >> >> As Henry Thompson said, it's important to get input regarding "what it >> is that the constituency seeking changes need[s] URNs to _do_ for >> them". > > To name the two most important practical things, we need to be able to > - use URI query to pass resolution related parameters to URN > resolvers, and I understand the desire to pass parameters to resolvers, but (a) why does this need to use URI query syntax, and (b) why does this need to be bundled with the URN at all? (since it's not referencing a portion of the resource, but really, a completely different resource) Or maybe I misunderstand what you mean by "pass parameters to resolvers"? Broadly speaking, I can imagine two different kinds of parameters: 1) parameters that identify some attribute of a resource that essentially narrows the scope to a portion of the resource - e.g. a particular version, edition, chapter, language, page range, time code range, etc. of a resource that exists in multiple versions (all grouped under this URN) and/or for which it makes sense for a specific portion to be referenced. 2) parameters that ask the resolver to produce some different resource than that named by the URN - e.g. a description of the resource rather than the resource itself, or a related resource The first kind of parameter is what I've been thinking of as a "facet". The combination of the URN and the parameter(s) still refer to either the entire resource or some narrowed portion of what is included in the resource. The second kind of parameter turns the original URN into a name for something else entirely, even though at some level both kinds of parameter end up just being passed to the resolver for interpretation. I think it might be useful to distinguish between these two, both in discussions and in syntax. > - use URI fragment to enable citing / referencing of identified resources. Again, why does this need to overload URI fragment syntax? > This can be done iff we agree that query and fragment are not part of > the NSS (that is, in the URN context they do not identify anything). I think we should agree on that in any event. But again, defining what is or is not "part of" the URN or NSS might less important than describing how systems should actually process such identifiers. > As an extra bonus, alignment of the URN syntax with the URI syntax > should remove the impression that URNs are out of date or deprecated > by URIs. That impression, I believe, has nothing to do with syntax, and everything to do with differences in architectural philosophy. It's possible that trying to shoehorn URNs into URI syntax will actually cause more confusion and help to further the arguments that some people make that URNs are not needed. But I think we should focus primarily on what makes sense from a protocol perspective and try to not worry too much about philosophical /political battles. Keith From nobody Wed Aug 6 10:23:46 2014 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 D660B1A035E for ; Wed, 6 Aug 2014 10:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 P56_6IsjTYwK for ; Wed, 6 Aug 2014 10:23:39 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244A91A0B03 for ; Wed, 6 Aug 2014 10:23:39 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway1.nyi.internal (Postfix) with ESMTP id 25FDB223E7 for ; Wed, 6 Aug 2014 13:23:21 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 06 Aug 2014 13:23:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=rRBefEPUJjxgYg50Eckaok v3HZY=; b=G7+9MDd9cNlBXz7ooA6KruKTfunNKJivN4xg+giP72COmXVEEjzagr 25zBm7/LfqypjmBRbsdq2JVI2csvPyUiC95I+JlFbYijL2UsEl7DxC/T4fAsz/QK 3gw72zgdPYiyo5HN9/+Xh2MuioBGY7SdeRun20kv8B5Qv6O84Yd6k= X-Sasl-enc: uIELR+IIuPMWAoaJAoTYaNFrzW5RxMRuggySe3RZfYBu 1407345800 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 66764680109; Wed, 6 Aug 2014 13:23:20 -0400 (EDT) Message-ID: <53E26478.8050702@network-heretics.com> Date: Wed, 06 Aug 2014 13:23:04 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <53CCE38B.7070609@it.aoyama.ac.jp> <4351aa24205e455e88c5c31a98257b62@BL2PR02MB307.namprd02.prod.outlook.com> <53E205BA.8060300@helsinki.fi> In-Reply-To: <53E205BA.8060300@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/w9jhIUS_rMr-m9eJk3sJzYVkcdQ Subject: Re: [urn] Query choices 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, 06 Aug 2014 17:23:42 -0000 On 08/06/2014 06:38 AM, Juha Hakala wrote: > If there is no agreement on query usage in URN syntax, the > implementers may run out of patience and follow the example of ARK and > Handle/DOI. I fully sympathize with the desire for to have this URN work finished. But I don't think that's an argument, by itself, for doing things the way that DOIs or anybody else does things. We should do what makes good technical sense for URNs, not merely try to follow others' examples. Keith From nobody Wed Aug 6 13:54:41 2014 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 B4D991A0294 for ; Wed, 6 Aug 2014 13:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 tzF7Bs_vX1qZ for ; Wed, 6 Aug 2014 13:54:37 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 9898C1A028E for ; Wed, 6 Aug 2014 13:54:37 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta15.westchester.pa.mail.comcast.net with comcast id bUPk1o0011ap0As5FYudXa; Wed, 06 Aug 2014 20:54:37 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id bYtb1o00G1KKtkw3iYtbBX; Wed, 06 Aug 2014 20:53:36 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s76KrZMW011176; Wed, 6 Aug 2014 16:53:35 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s76KrYFJ011175; Wed, 6 Aug 2014 16:53:34 -0400 Date: Wed, 6 Aug 2014 16:53:34 -0400 Message-Id: <201408062053.s76KrYFJ011175@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Keith Moore In-reply-to: <53E2630B.6000002@network-heretics.com> (moore@network-heretics.com) References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407358477; bh=FXvKHsM3WFnvKqbETviISazzSpttGfvDC7J61swNrAw=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=H2oTRo7EI6vIl62qHW8PrnbKCkTEKggNwU5RH4wkkblPLr9jKJM8YoYArQPJdJYmi W3LxIGHAyZZ+uWhSCSJUX8esIQlaGsaaS6Thi2Cmcy5IYqZIJQqT3aX4xt4n7KgF+b 8qV3XbWpz81eVi5Hek7I5qdzGE3e12zp4rL/aBAXJMFhPPR45q8LPaHxKO2fISofV3 3I2g1MYvoZAssM0LAZSQb7LFzEcm1TE3jZcUkeHwQNfdLzOjEloAbX9lR/XNjS7fe+ P/Z8++xRbyUZMy4Rdlg5Pv51HDQjp9OuYiqIJdsbDwpcU7ktr9mwL8oDzkitf1ObZU krX2SrDBZXh5w== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/0CkZRN6wGA1xHexKhzloojeEx6c Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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, 06 Aug 2014 20:54:39 -0000 > From: Keith Moore > > - use URI fragment to enable citing / referencing of identified resources. > > Again, why does this need to overload URI fragment syntax? I believe that what Juha means is that if urn:isbn:1234 is the name of a book, then urn:isbn:1234#page7 can be the name of a page of the book. Currently, using '#' at all with URNs is not syntactally allowed by the URN RFC, though it's within the syntax looking at them as URIs (and hence is unlikely to cause ugly compatibility problems). I think the tricky part is that currently the effect of fragment identifiers is entirely defined within the media type definition. Whereas, one wants to be able to define all manifestations of the resource to have "#act2scene3" refer to the same logical point in the resource (from the human point of view), which may not be operable within the interpretation of fragment identifiers that was defined by some particular manifestation's media type. Dale From nobody Wed Aug 6 14:48:44 2014 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 9A1F71B2897 for ; Wed, 6 Aug 2014 14:48:42 -0700 (PDT) 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 djXkcsO2yThC for ; Wed, 6 Aug 2014 14:48:39 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 379C11A02F1 for ; Wed, 6 Aug 2014 14:48:38 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s76LmVRl022738; Wed, 6 Aug 2014 22:48:31 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s76LmTm3009062; Wed, 6 Aug 2014 22:48:29 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s76LmUkr009499; Wed, 6 Aug 2014 22:48:30 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s76LmT7j009495; Wed, 6 Aug 2014 22:48:29 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Juha Hakala References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 06 Aug 2014 22:48:29 +0100 In-Reply-To: <53E1E107.1080302@helsinki.fi> (Juha Hakala's message of "Wed\, 06 Aug 2014 11\:02\:15 +0300") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/nLSQYUgZdfEJIIneIZ_qNA3_HUE Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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, 06 Aug 2014 21:48:42 -0000 Juha Hakala writes: > ... > On 5.8.2014 21:03, Dale R. Worley wrote: >> ... >> As Henry Thompson said, it's important to get input regarding "what it >> is that the constituency seeking changes need[s] URNs to _do_ for >> them". > > To name the two most important practical things, we need to be able to > - use URI query to pass resolution related parameters to URN resolvers, and > - use URI fragment to enable citing / referencing of identified resources. Trying to be careful here: those read to me as candidate solutions to unstated requirements, not the requirements themselves, which is what I intended to ask for. Would these be acceptable formulations of the _requirements_ (I'm guessing here, help me out): 1) Given a URN which identifies a publication, it should be possible to construct another URN which identifies specific aspects of the metadata for that publication, such that the right thing will happen if the resulting URN is resolved; 2) Given a URN which identifies a publication, it should be possible to construct another URN which identifies a specific sub-part of that publication. I'm assuming that the details of _how_ to do the above constructions wants to be included in URN namespace registrations. Examples would help. Not examples of _syntax_ so much, as examples of the requirements, e.g. for (2): "Given a urn:isbn:... URN which identifies a book, it should be possible to construct a URN which identifies a chapter of said book by number or name." and for (1) "Given a urn:isbn:... URN, it should be possible to construct a URN which can be used for retrieval of the name of the ISBN-registered publisher of the publication that the original URN identifies, given access to a conformant generic urn:isbn:.... resolution service." It would be helpful also to understand if those requirements have to be satisfied uniformly for _all_ URNs, or whether it's up to a URN namespace registration to specify whether, and if so how, (1) and/or (2) are to be achieved (possibly subject to some general guidelines for all URNs). Thanks, ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Wed Aug 6 15:24:35 2014 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 11AE11B28B8 for ; Wed, 6 Aug 2014 15:24:32 -0700 (PDT) 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 qlmsiqFxz5Uf for ; Wed, 6 Aug 2014 15:24:30 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBA01B28AA for ; Wed, 6 Aug 2014 15:24:29 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id et14so4180975pad.35 for ; Wed, 06 Aug 2014 15:24:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=UF5QFWSNT5AFz4gTiyWjCMaQlNzl9jnMHV+94keqmOI=; b=lgOuLSoTwCkVnP/Q4OYjU/ol6wwpKQQmuO27OOgnDYQa4Rv95x8q5iwq6B4rYYb45m gApmaD7gyobe+qaRZ9XDn0I5A11X7FUzwmQMb2sx4V7U2QKU9YUP1k09FvnpWyNJkpQF z8uya5U3iq0eFUUOd085yVnUgnALstq6iF8WSVhLBA3PjoPlMOVUUe4sQE7gO3N3GMWS 8IlF0JLoptbS0SuAFkoqe3dpxBd+96UeFYn+dRgojXtmMk6JnwH/p0euxj06Cn/Xhgq9 bUCd7rovUGlHjFe3vGPOLnqbqquxz1DeHVtgPMoMW6OCnj9Q8wNX1O1B3TlzUOXDAXGN sztw== X-Gm-Message-State: ALoCoQkC3NjwuVv6gSJU3q/K5hBnZs4gNehXO5qDwvAXhCjw2mmj90ZsLt5CPKo1dPrK1v+xzf+G MIME-Version: 1.0 X-Received: by 10.70.48.175 with SMTP id m15mr13959295pdn.78.1407363869183; Wed, 06 Aug 2014 15:24:29 -0700 (PDT) Received: by 10.66.27.5 with HTTP; Wed, 6 Aug 2014 15:24:29 -0700 (PDT) X-Originating-IP: [71.191.38.92] In-Reply-To: References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> Date: Wed, 6 Aug 2014 18:24:29 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/t_TUk3O7RKW0-r5dN5c_4Yz0fZw Subject: Re: [urn] Consensus Question Regarding Direction of Work 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, 06 Aug 2014 22:24:32 -0000 On Wed, Aug 6, 2014 at 5:48 PM, Henry S. Thompson wrote: > It would be helpful also to understand if those requirements have to > be satisfied uniformly for _all_ URNs, or whether it's up to a URN > namespace registration to specify whether, and if so how, (1) and/or > (2) are to be achieved (possibly subject to some general guidelines > for all URNs). I agree. But I'd appreciate if we could keep this thread dedicated to hearing from those with concerns regarding the direction this working group intends to take (not to pick on Henry though). I'll be working with the draft author on a structured discussion to help us get these types of answers. The revised draft will be our anchor point for discussion, and that will be come soon if no objections are raised. -andy co-chair From nobody Wed Aug 6 15:45:28 2014 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 D1A6D1B28AA for ; Wed, 6 Aug 2014 15:45:26 -0700 (PDT) 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 aHbkN0EOIR5Q for ; Wed, 6 Aug 2014 15:45:24 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 38A051B28DA for ; Wed, 6 Aug 2014 15:45:24 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s76MjL3L001805; Wed, 6 Aug 2014 23:45:21 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s76MjKKv010400; Wed, 6 Aug 2014 23:45:20 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s76MjLmR010610; Wed, 6 Aug 2014 23:45:21 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s76MjKLf010605; Wed, 6 Aug 2014 23:45:20 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Andrew Newton References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 06 Aug 2014 23:45:20 +0100 In-Reply-To: (Andrew Newton's message of "Wed\, 6 Aug 2014 18\:24\:29 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/wZGKLvSEFbFWK-p7fd6Bjpl9sgI Cc: "urn@ietf.org" Subject: Re: [urn] Consensus Question Regarding Direction of Work 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, 06 Aug 2014 22:45:27 -0000 Andrew Newton writes: > But I'd appreciate if we could keep this thread dedicated to hearing > from those with concerns regarding the direction this working group > intends to take (not to pick on Henry though). Not to be awkward, but if the direction the working group intends to take is substantially determined along the following lines (quoting from [1]): To name the two most important practical things, we need to be able to - use URI query to pass resolution related parameters to URN resolvers, and - use URI fragment to enable citing / referencing of identified resources. This can be done iff we agree that query and fragment are not part of the NSS (that is, in the URN context they do not identify anything). then I'm _not_ happy with its direction. A working group to address requirements on URNs not currently (perceived) to be met is one thing. A working group to implement a particular pair of solutions is quite another. Either way, I've made my position clear, I won't pursue this further ht [1] http://www.ietf.org/mail-archive/web/urn/current/msg02429.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Wed Aug 6 22:36:15 2014 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 465C21A0ACE for ; Wed, 6 Aug 2014 22:36:13 -0700 (PDT) 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 l361d_bQZTXG for ; Wed, 6 Aug 2014 22:36:10 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF0D1A0ABA for ; Wed, 6 Aug 2014 22:36:08 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s775a77N030501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Aug 2014 08:36:08 +0300 Message-ID: <53E31045.3080704@helsinki.fi> Date: Thu, 07 Aug 2014 08:36:05 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/jmaT1PguzN5VdKI3ytb1C8H-_4Q Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 05:36:13 -0000 Hello Henry, On 7.8.2014 0:48, Henry S. Thompson wrote: > Juha Hakala writes: > > >> To name the two most important practical things, we need to be able to >> - use URI query to pass resolution related parameters to URN resolvers, and >> - use URI fragment to enable citing / referencing of identified resources. > Trying to be careful here: those read to me as candidate solutions to > unstated requirements, not the requirements themselves, which is what > I intended to ask for. > > Would these be acceptable formulations of the _requirements_ (I'm > guessing here, help me out): > > 1) Given a URN which identifies a publication, it should be possible > to construct another URN which identifies specific aspects of the > metadata for that publication, such that the right thing will > happen if the resulting URN is resolved; RFC 2483 specifies URI to URC service, which: ... allows the client to obtain a description of the resource identified by a URI, as opposed to the resource itself or simply the resource's URLs. The description might be a bibliographic citation, a digital signature, or a revision history. This memo does not specify the content of any response to a URC request. That content is expected to vary from one server to another. So, we might have a requirement to support URI to URC, but in an updated form so that it is possible to specify the metadata format. IMO there is no need to go further and allow retrieval of individual metadata elements. It is my intention to revise RFC 2483 since several relevant services are missing from it, and we also need a simple mechanism for specifying additional services and service parameters (such as metadata formats to URI to URC). The implementer community has a requirement for these additional services missing from RFC 2483, but more urgently, we need a simple mechanism for passing service parameters to resolvers. DDDS, specified in RFCs 3401-3404, has for some reason not been implemented in URN resolvers. Instead, the community developing these applications wishes to follow the example of ARK and Handle/DOI communities - use query for sending service requests to resolvers. > > 2) Given a URN which identifies a publication, it should be possible > to construct another URN which identifies a specific sub-part of > that publication. This requirement has to do with identifier assignment policies which differ from one namespace to the next. I don't think that IETF or URNBIS can change the existing identification practices. You just have to accept them, since that's how the URN system has been designed. It was a brilliant idea to establish namespaces which each apply the rules of the registered identifier system. But that means that while there are some namespaces where it may be possible to meet this requirement, there are also some where it is not possible. It is important to make a difference between logical and physical components of publications. URNBIS has agreed earlier that identification of logical components will be based on namespace specific principles and practices. For instance, in the ISBN namespace, separate ISBNs can be given both to The Lord of the Rings as a whole, and to the three parts (when they are published individually). But it is not possible to assign ISBNs to individual chapters, unless they are published separately. Two or more identifier systems may be used in parallel to identify all logical components needed. An example of this is that ISSN is used for identification of serials, but DOI for identification of individual articles. Or, we have ISBN for a digitized book, but NBNs for page images. URI fragments may or may not have anything to do with the logical structure of the work. Therefore it is very unclear from the start what fragments might identify. On the other hand, users may want to use them for citing and referencing purposes. We can allow this by saying that when used in the URN context they do not identify anything ( of URN implementers). Then we avoid also two further problems: - mixing identification of logical and physical components of a publication in one URN - extending the scope of existing identifiers beyond what is acceptable > > I'm assuming that the details of _how_ to do the above constructions > wants to be included in URN namespace registrations. IETF has decided to allow also namespaces which do not support any resolution services. If one or more services are supported, they may be listed to registration requests, alongside an explanation of the process. But is should be noted that maintaining this information would be cumbersome; services supported depend mainly on the technical infrastructure within which identifiers are used. So when for instance digital preservation systems become common in a few years time, a lot of new resolution services will be available for many identifier systems. Namespace registrations should include the scope of the system (what can be identified). > > Examples would help. Not examples of _syntax_ so much, as examples of > the requirements, e.g. for (2): > > "Given a urn:isbn:... URN which identifies a book, it should be > possible to construct a URN which identifies a chapter of said book > by number or name." Requirements concerning the identification policies (especially as regards logical components of resources) are usually maintained by the identifier user communities in manuals and user guides. IETF does not need to go into this area, and it certainly cannot make requirements which are in conflict with existing practices. What IETF should do is to allow usage of URI fragment for indicating (not identifying) physical components of identified resources. > > and for (1) > > "Given a urn:isbn:... URN, it should be possible to construct a > URN which can be used for retrieval of the name of the > ISBN-registered publisher of the publication that the original URN > identifies, given access to a conformant generic > urn:isbn:.... resolution service." Given the background provided in RFC 2483, we could perhaps say something like this: URN resolver should be able to resolve urn + (valid) service request into appropriate URI and pass it on to a server which can provide the service required. For instance, if resolver receives a URN with a query containing URI to URC request, the resolver should convert that request into e.g. SRU search, and send it to a bibliographic database which is able to deliver metadata about the resource to the client application. > > It would be helpful also to understand if those requirements have to > be satisfied uniformly for _all_ URNs, or whether it's up to a URN > namespace registration to specify whether, and if so how, (1) and/or > (2) are to be achieved (possibly subject to some general guidelines > for all URNs). IMO nothing applies to all URNs. If a URN is not actionable, then nothing we say about services is relevant. And if URN does not identify a publication but (for instance) a person, there are neither logical or physical components to identify / indicate. As regards query, we cannot carve in stone the services and service parameters supported by a namespace. There are services (for instance, retrieve the original version of this digital document) which cannot be supported now, but which will become very relevant (and possible) in a few decades. Best regards, Juha > > Thanks, > > ht -- 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 nobody Wed Aug 6 23:05:04 2014 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 5E3F31ADDB5 for ; Wed, 6 Aug 2014 23:05:00 -0700 (PDT) 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 i0yERx3tgdtb for ; Wed, 6 Aug 2014 23:04:58 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423461AD62A for ; Wed, 6 Aug 2014 23:04:57 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s7764kZC008578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Aug 2014 09:04:47 +0300 Message-ID: <53E316FC.4090903@helsinki.fi> Date: Thu, 07 Aug 2014 09:04:44 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dale R. Worley" , Keith Moore References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <201408062053.s76KrYFJ011175@hobgoblin.ariadne.com> In-Reply-To: <201408062053.s76KrYFJ011175@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/EIWoVSUEhQH3_sSt5lc6szutKdg Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 06:05:00 -0000 Hello, On 6.8.2014 23:53, Dale R. Worley wrote: >> From: Keith Moore >>> - use URI fragment to enable citing / referencing of identified resources. >> Again, why does this need to overload URI fragment syntax? > I believe that what Juha means is that if urn:isbn:1234 is the name of > a book, then urn:isbn:1234#page7 can be the name of a page of the > book. Currently, using '#' at all with URNs is not syntactally > allowed by the URN RFC, though it's within the syntax looking at them > as URIs (and hence is unlikely to cause ugly compatibility problems). Correct, except that although urn:isbn: is the name / identifier of a book, urn:isbn:#page7 cannot be the name / identifier of page 7. The identifier (namespace specific string) is the same in both examples. In the latter URN there is a fragment after NSS indicating a certain location within the document, but the two URNs are still lexically equivalent. Of course, you could do something like urn:xxxx: but IMO this is not a good idea (see below). Within the URN system namespaces, the rules of identifier systems apply. These rules may or may not agree with URI Generic Syntax. The important thing is that the ISBN user manual overrides what RFC 3986 says about the role of fragments in identification. The good thing is that this mismatch between RFC 3986 and ISBN rules relate only to semantics, not syntax. > > I think the tricky part is that currently the effect of fragment > identifiers is entirely defined within the media type definition. > Whereas, one wants to be able to define all manifestations of the > resource to have "#act2scene3" refer to the same logical point in the > resource (from the human point of view), which may not be operable > within the interpretation of fragment identifiers that was defined by > some particular manifestation's media type. Yes, we need to keep identification of logical parts of resources and usage of URI fragment apart. Even if the logical structure of a document happens to match the physical one, it is better to avoid URI fragment usage, since the next (migrated) version of the document may not have the same encoding any more. Fragments are tied to a single manifestation of a resource and do not live longer than that manifestation (whereas the work itself may live much longer in various migrated forms). Juha > > Dale -- 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 nobody Thu Aug 7 00:23:37 2014 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 3E9D61B2855 for ; Thu, 7 Aug 2014 00:23:35 -0700 (PDT) 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 KTNDx_FontM6 for ; Thu, 7 Aug 2014 00:23:32 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8761B27E0 for ; Thu, 7 Aug 2014 00:23:31 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s777NT3A024370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Aug 2014 10:23:30 +0300 Message-ID: <53E3296F.1020407@helsinki.fi> Date: Thu, 07 Aug 2014 10:23:27 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> In-Reply-To: <53E2630B.6000002@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/7NbFYodsEFJr2qvYaV8MT5toIGo Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 07:23:35 -0000 Hello Keith, On 6.8.2014 20:16, Keith Moore wrote: > On 08/06/2014 04:02 AM, Juha Hakala wrote: >> >> To name the two most important practical things, we need to be able to >> - use URI query to pass resolution related parameters to URN >> resolvers, and > > I understand the desire to pass parameters to resolvers, but (a) why > does this need to use URI query syntax, and (b) why does this need to > be bundled with the URN at all? (since it's not referencing a > portion of the resource, but really, a completely different resource) Based on the implementer experiences of other persistent identifier communities, using query for this purpose seems to be a simple and efficient means for making service requests. Moreover, implementing some other method would make it more difficult to make ARK / Handle / URN resolvers interoperable. Once this kind of usage of query in the URN context is approved, there is a need to specify syntax (e.g. ?s=URC) the implementers should use in order to guarantee maximum interoperability between different resolver applications. > > Or maybe I misunderstand what you mean by "pass parameters to > resolvers"? Broadly speaking, I can imagine two different kinds of > parameters: > > 1) parameters that identify some attribute of a resource that > essentially narrows the scope to a portion of the resource - e.g. a > particular version, edition, chapter, language, page range, time code > range, etc. of a resource that exists in multiple versions (all > grouped under this URN) and/or for which it makes sense for a specific > portion to be referenced. Like URI fragment, query does not identify anything and it cannot / should not be used for this purpose. > > 2) parameters that ask the resolver to produce some different resource > than that named by the URN - e.g. a description of the resource rather > than the resource itself, or a related resource Yes, we want to use query to help us to implement services specified in RFC 2483 (and other services which have not been specified yet. > > The first kind of parameter is what I've been thinking of as a > "facet". The combination of the URN and the parameter(s) still refer > to either the entire resource or some narrowed portion of what is > included in the resource. > > The second kind of parameter turns the original URN into a name for > something else entirely, even though at some level both kinds of > parameter end up just being passed to the resolver for interpretation. Since query is not part of the NSS, the original URN and the URN with query identify the same thing (that is, they are lexically equivalent). In many URN namespaces, it is impossible to extend the scope of the identifier in the manner URI query would require. But even if the namespace were so liberal as to approve query usage in identification, "name for something else entirely" would become a major problem. In my opinion, saying that URI query identifies something just cannot be right in any context. Also, while NSS is unique and persistent, query will not be. Services and service parameters come and go; at the moment it would make sense to require metadata about a book in MARC 21 format from a library system, but in 20 years time the format will have changed. > > I think it might be useful to distinguish between these two, both in > discussions and in syntax. Yes - we only need to discuss about the latter in the URN context. > >> - use URI fragment to enable citing / referencing of identified >> resources. > > Again, why does this need to overload URI fragment syntax? I do not think that allowing the use of fragments with URNs overloads the URI fragment syntax. People are already using URLs and fragments to cite / refer to digital documents. Using URN + fragment for this purpose is less error prone, although citing / referencing digital resources like this assumes that the identified manifestation of the resource will remain available for a long time. Depending on the MIME type of the resource (and organizational set-up of the document repository) that may be a wrong assumption. Citing / referencing digital documents so that the links will be truly persistent is difficult. The best solution will eventually be to create from a reference a link to the metadata record of the work (which should contain links to all the physical manifestations, from the earliest one to more modern migrated versions). Any location information should be based on logical fragments such as chapters, not physical fragments such as pages. Juha > >> This can be done iff we agree that query and fragment are not part of >> the NSS (that is, in the URN context they do not identify anything). > > I think we should agree on that in any event. But again, defining > what is or is not "part of" the URN or NSS might less important than > describing how systems should actually process such identifiers. > >> As an extra bonus, alignment of the URN syntax with the URI syntax >> should remove the impression that URNs are out of date or deprecated >> by URIs. > > That impression, I believe, has nothing to do with syntax, and > everything to do with differences in architectural philosophy. It's > possible that trying to shoehorn URNs into URI syntax will actually > cause more confusion and help to further the arguments that some > people make that URNs are not needed. But I think we should focus > primarily on what makes sense from a protocol perspective and try to > not worry too much about philosophical /political battles. > > Keith > -- 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 nobody Thu Aug 7 06:53:50 2014 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 7A9B21B2B2C for ; Thu, 7 Aug 2014 06:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 o2D1gdUTmt0C for ; Thu, 7 Aug 2014 06:53:47 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14771B2B36 for ; Thu, 7 Aug 2014 06:53:44 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by gateway1.nyi.internal (Postfix) with ESMTP id DC1BA2265B for ; Thu, 7 Aug 2014 09:53:43 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 07 Aug 2014 09:53:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=tzbez+juiEbqpIwQCAj4ST a5QME=; b=JgRCTHAa1Z7OTSIFakGsnCmF1cjFlz9EGM0qeuZKmoc+LkBUyfoa2w ajQ4xI3uQPq0uLrfGtYwTgjKmNIU8byvsNftyuokNSxd7n9ZyUZlacPhJZL6c7JP 8O4GoW3kKt3I6/YHxAINE9n0utJDwtgFjYyCSBt3ZNFyclZURLwIo= X-Sasl-enc: EYynIP8XspdhHMyslWM25eQK3tOyGrU/C2nRApjOVL7S 1407419622 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 670BB6800E5; Thu, 7 Aug 2014 09:53:42 -0400 (EDT) Message-ID: <53E384D3.4040804@network-heretics.com> Date: Thu, 07 Aug 2014 09:53:23 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Juha Hakala , "Dale R. Worley" References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <201408062053.s76KrYFJ011175@hobgoblin.ariadne.com> <53E316FC.4090903@helsinki.fi> In-Reply-To: <53E316FC.4090903@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/jL9V-ZVph2SI69fwIAtfOA-hHUc Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 13:53:49 -0000 On 08/07/2014 02:04 AM, Juha Hakala wrote: > Hello, > > On 6.8.2014 23:53, Dale R. Worley wrote: >>> From: Keith Moore >>>> - use URI fragment to enable citing / referencing of identified >>>> resources. >>> Again, why does this need to overload URI fragment syntax? >> I believe that what Juha means is that if urn:isbn:1234 is the name of >> a book, then urn:isbn:1234#page7 can be the name of a page of the >> book. Currently, using '#' at all with URNs is not syntactally >> allowed by the URN RFC, though it's within the syntax looking at them >> as URIs (and hence is unlikely to cause ugly compatibility problems). > > Correct, except that although urn:isbn: is the name / identifier > of a book, urn:isbn:#page7 cannot be the name / identifier of > page 7. The identifier (namespace specific string) is the same in both > examples. In the latter URN there is a fragment after NSS indicating a > certain location within the document, but the two URNs are still > lexically equivalent. Ok, first, I propose that we talk in terms of "extended URNs" that consist of a URN + an optional modifier. Something like: extended-urn = urn [ modifiers ] modifiers = *( "/" facet-name "=" value ) *( "?" string ) [ "#" string ] The precise details of the syntax aren't important for the moment. What's important is that: - an extended URN consists of a URN + zero or more modifiers - every URN is an extended URN, but an extended URN that includes a modifier is necessarily a URN - an extended URN is a URI, and can potentially be used anywhere a URI can be used So using the example above: "urn:isbn:1237#page7" would be an extended URN. That extended URN contains an embedded URN "urn:isbn:1237". The "#page7" modifier is "part of" the extended URN, but not "part of" the URN. (Whether or not it's a good idea to use "#" with URNs in this way, or to use the idea of HTML-style fragment identifiers to name pages, are separate questions.) (And I'm not entirely happy with the name "extended URN" but it's the best I could think of for the moment.) > > Of course, you could do something like urn:xxxx: but IMO > this is not a good idea (see below). > > Within the URN system namespaces, the rules of identifier systems > apply. These rules may or may not agree with URI Generic Syntax. The > important thing is that the ISBN user manual overrides what RFC 3986 > says about the role of fragments in identification. URN namespaces should not be able to redefine URI syntax on a per-namespace basis. A parser must be able to recognize where a URI ends (even in, say, an email message or text document) without knowing the syntax of each separate URI namespace. If 3986 needs to be overridden for all URNs, or to accommodate extended URNs, fine. But it must not be a namespace-specific syntax. Furthermore, the meaning of fragment syntax must not be namespace-specific, because this would again require that clients know details of individual URN namespaces. Fragment syntax must have the same meaning across all URNs. Actually I think fragment syntax should have the same meaning across all URIs, that this is already defined (for better or worse) as being specific to the media type, and that this is too well-established to change it. At the very least we need to consider not only the desire of people to include fragment-like specifiers with URNs but also the potential impact on all of the software that currently exists that processes URIs. > The good thing is that this mismatch between RFC 3986 and ISBN rules > relate only to semantics, not syntax. > >> >> I think the tricky part is that currently the effect of fragment >> identifiers is entirely defined within the media type definition. >> Whereas, one wants to be able to define all manifestations of the >> resource to have "#act2scene3" refer to the same logical point in the >> resource (from the human point of view), which may not be operable >> within the interpretation of fragment identifiers that was defined by >> some particular manifestation's media type. > > Yes, we need to keep identification of logical parts of resources and > usage of URI fragment apart. Even if the logical structure of a > document happens to match the physical one, it is better to avoid URI > fragment usage, since the next (migrated) version of the document may > not have the same encoding any more. Fragments are tied to a single > manifestation of a resource and do not live longer than that > manifestation (whereas the work itself may live much longer in various > migrated forms). I think we are going to have to reconcile ourselves to the fact that "extended URNs" have no assurance of persistence even though the URNs embedded in them do. So it doesn't violate any persistence rules to use an extended URN with an HTML-style fragment. (This makes me uncomfortable, as I think that no matter what we write in our RFCs, ordinary users are going to miss the subtle distinction between a URN and an extended URN. They're still going to think of the modifiers as "part of the URN". But I think there's too much demand to be able to use modifiers with URNs in ways that that result in the combinations of the two being non-persistent. We could of course define a different URI scheme, say "xurn:", to make the difference more apparent. But I think people would still get URNs and XURNs confused, and use the wrong prefix, and software would end up treating both the same.) Keith From nobody Thu Aug 7 07:39:44 2014 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 4B7461B2B9A for ; Thu, 7 Aug 2014 07:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 wTe_wurKykX7 for ; Thu, 7 Aug 2014 07:39:41 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A9B1B2B8D for ; Thu, 7 Aug 2014 07:39:39 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by gateway1.nyi.internal (Postfix) with ESMTP id 1920022C0D for ; Thu, 7 Aug 2014 10:39:35 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 07 Aug 2014 10:39:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=sTJTGxOtgZeqJaOPMnA2R3 HRtMg=; b=m4G6dcC5fa64QWerzRbUHq1gQA8efrk5H4hOtf423gqHpFX26y6O3K tPD8px2PGVosVq7gh+28864/S1RMrGAKo1k/eZNSVMBgyF4lEBNyul9FNJKg0iPY 0uj2C9T0wDSW40tMZIVn9R90wVwX/hypoXu3vrlDiMCtEYQZ1K8pY= X-Sasl-enc: TFIZe0xHOpXldW+JCyPfbSrBM+6BnTUWuJd597HbGTdz 1407422373 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 28E2DC00003; Thu, 7 Aug 2014 10:39:33 -0400 (EDT) Message-ID: <53E38F91.7080100@network-heretics.com> Date: Thu, 07 Aug 2014 10:39:13 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Juha Hakala , "Dale R. Worley" References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <201408062053.s76KrYFJ011175@hobgoblin.ariadne.com> <53E316FC.4090903@helsinki.fi> <53E384D3.4040804@network-heretics.com> In-Reply-To: <53E384D3.4040804@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FjEixWJI5-VkgJxvARh74nHaPGk Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 14:39:42 -0000 Oops....I just noticed an important error in the text below. On 08/07/2014 09:53 AM, Keith Moore wrote: > Ok, first, I propose that we talk in terms of "extended URNs" that > consist of a URN + an optional modifier. Something like: > > extended-urn = urn [ modifiers ] > > modifiers = *( "/" facet-name "=" value ) *( "?" string ) [ "#" string ] > > The precise details of the syntax aren't important for the moment. > What's important is that: > > - an extended URN consists of a URN + zero or more modifiers > - every URN is an extended URN, but an extended URN that includes a > modifier is necessarily a URN the above line should be: - every URN is an extended URN, but an extended URN that includes a modifier is NOT a URN Keith From nobody Thu Aug 7 07:45:22 2014 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 A46911B2B8B for ; Thu, 7 Aug 2014 07:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 8z19oLh2KrLp for ; Thu, 7 Aug 2014 07:45:12 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA88B1B29F0 for ; Thu, 7 Aug 2014 07:45:12 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway1.nyi.internal (Postfix) with ESMTP id B38EA21F30 for ; Thu, 7 Aug 2014 10:45:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 07 Aug 2014 10:45:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=oU1ahm9TEU49+94H0RmYyb MjMJ4=; b=AW5DHFEx+J0ZwW5bGXNLOCZt2OJVh345DBm4x5ai5mYQTJN74zuuhn cU+n6vx2AxLFkjRaQzH1WZDtJSinNfX3vOsveyQ5TmZ55qajXAizWIR04NRsJIRA QPcU5V6G74xxF0sjtk0h911ErDFbgLD37H1Gq5kuGqhjbTwyxG3eA= X-Sasl-enc: hpFj/WYStQWvddizeskDieSmuwMAIOCG3Zm2vn8GhRco 1407422709 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 69F41C007AA; Thu, 7 Aug 2014 10:45:07 -0400 (EDT) Message-ID: <53E390DF.6000305@network-heretics.com> Date: Thu, 07 Aug 2014 10:44:47 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <53E3296F.1020407@helsinki.fi> In-Reply-To: <53E3296F.1020407@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1OJKTPJRrjIE_9fI2fRY66uEBe4 Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 14:45:17 -0000 On 08/07/2014 03:23 AM, Juha Hakala wrote: > Hello Keith, > > On 6.8.2014 20:16, Keith Moore wrote: >> On 08/06/2014 04:02 AM, Juha Hakala wrote: > > > >>> >>> To name the two most important practical things, we need to be able to >>> - use URI query to pass resolution related parameters to URN >>> resolvers, and >> >> I understand the desire to pass parameters to resolvers, but (a) why >> does this need to use URI query syntax, and (b) why does this need to >> be bundled with the URN at all? (since it's not referencing a >> portion of the resource, but really, a completely different resource) > > Based on the implementer experiences of other persistent identifier > communities, using query for this purpose seems to be a simple and > efficient means for making service requests. Moreover, implementing > some other method would make it more difficult to make ARK / Handle / > URN resolvers interoperable. I don't think this is a good enough reason to overload query syntax. Or perhaps I should rephrase the question: Why is it more important to use URI query syntax to pass parameters to URN resolvers, than it is to be able to use URI query syntax to pass messages to the resources named by those URNs? Because we know from vast experience that it's tremendously useful to be able to bundle a URI that identifies a resource with a message that gets passed to that resource and which potentially affects the information returned by that resource. It's probably not a stretch to estimate that nearly every web server provides access to a few resources that work this way. To me it also seems incredibly shortsighted to define query syntax with URNs in such a way as to preclude being able to bundle a message to be passed to the resource, with the URN. That would essentially be saying that it's more important to optimize URNs to work with fixed/physical media resources than to optimize URNs to work with network-connected resources... which is indeed odd considering that URNs were created primarily for the latter purpose. Or to put it another way: URI syntax (as defined and in practice) really limits the number of modifiers with which URIs can be bundled, and doesn't leave much room for extensibility. Do we really want to restrict the use of "?" with URNs in such a way that the only thing that can be done with it is to pass parameters to a resolver? I think I understand why people want to bundle resolver queries with URNs, but I also think that that's about the least compelling use case I can think of for attaching modifiers to a URN. Certainly it seems less compelling than wanting to narrow the resource being named to a particular facet of that resource like chapter or edition or language or timecode range, and less compelling than wanting to include a message/query to be sent to the resource. Still, I don't want to say "you cannot bundle a resolver query with a URN". I am just saying "please, let's define a way to do that, that doesn't prevent other kinds of modifiers to be bundled with URNs". So I think we should try to define URN modifiers in such a way that there's some room for expansion, as we will surely discover new compelling use cases in the future. Simply redefining "?" and "#" to have different meanings than for other URIs, while being consistent with syntax for other URIs, won't leave room for expansion. I want us to define an extensible syntax for URN modifiers, such that a client can tell which modifiers are resolver queries, which ones are facets that narrow the resource being named, and so forth. And I want to do it in such a way that doesn't break existing things that understand URIs. > > Once this kind of usage of query in the URN context is approved, there > is a need to specify syntax (e.g. ?s=URC) the implementers should use > in order to guarantee maximum interoperability between different > resolver applications. > >> >> Or maybe I misunderstand what you mean by "pass parameters to >> resolvers"? Broadly speaking, I can imagine two different kinds of >> parameters: >> >> 1) parameters that identify some attribute of a resource that >> essentially narrows the scope to a portion of the resource - e.g. a >> particular version, edition, chapter, language, page range, time code >> range, etc. of a resource that exists in multiple versions (all >> grouped under this URN) and/or for which it makes sense for a >> specific portion to be referenced. > > Like URI fragment, query does not identify anything and it cannot / > should not be used for this purpose. I was just talking about use cases for passing parameters to resolvers. I wasn't speaking in terms of query syntax. I don't think it's a good idea to use query syntax for either of these use cases. > >> >> 2) parameters that ask the resolver to produce some different >> resource than that named by the URN - e.g. a description of the >> resource rather than the resource itself, or a related resource > > Yes, we want to use query to help us to implement services specified > in RFC 2483 (and other services which have not been specified yet. I also want people to be able to implement those services. That doesn't mean that I think it's a good idea to use query syntax for this purpose. > >> >> The first kind of parameter is what I've been thinking of as a >> "facet". The combination of the URN and the parameter(s) still >> refer to either the entire resource or some narrowed portion of what >> is included in the resource. >> >> The second kind of parameter turns the original URN into a name for >> something else entirely, even though at some level both kinds of >> parameter end up just being passed to the resolver for interpretation. > > Since query is not part of the NSS, the original URN and the URN with > query identify the same thing (that is, they are lexically equivalent). Well, no. They both contain the same URN, but it's misleading at best to say that the two are equivalent. You should not, for instance, treat them as equivalent for the purpose of caching the result. Equivalence is probably not a very useful concept when talking about extended URNs. You can compare the URNs embedded in them, and that might occasionally be useful. But comparing two extended URNs in their entirety probably won't be useful for much. > > In many URN namespaces, it is impossible to extend the scope of the > identifier in the manner URI query would require. But even if the > namespace were so liberal as to approve query usage in identification, > "name for something else entirely" would become a major problem. In my > opinion, saying that URI query identifies something just cannot be > right in any context. This probably a minor point, but I disagree. It's reasonable to say that an HTTP URL with a query identifies something, and it's as reasonable to say that a URN with a query identifies something. It's not reasonable to assume in either case that the binding between the URI and what is identified, is persistent. > > Also, while NSS is unique and persistent, query will not be. Services > and service parameters come and go; at the moment it would make sense > to require metadata about a book in MARC 21 format from a library > system, but in 20 years time the format will have changed. Agree. > >> >> I think it might be useful to distinguish between these two, both in >> discussions and in syntax. > > Yes - we only need to discuss about the latter in the URN context. Strongly disagree. I see too many uses of "?" to identify facets of resources with HTTP, to believe that it's unimportant to be able to specify facets with URNs. We need a way to do that with URNs, whether or not it uses "?". | I would be happy for URNs to accommodate both of the above use cases. But as far as I can tell, the former use case is much more compelling than the latter. > >> >>> - use URI fragment to enable citing / referencing of identified >>> resources. >> >> Again, why does this need to overload URI fragment syntax? > > I do not think that allowing the use of fragments with URNs overloads > the URI fragment syntax. The current meaning of fragment syntax is defined by the media type, and fragments are evaluated according to the rules of the media type. If you are proposing to do it differently for URNs, that's overloading the syntax. Now, having said that, I'll readily admit that HTML fragments are really poorly designed and not terribly useful. And I haven't seen fragments used frequently with other kinds of media, so I don't know how useful they are with other media types. But I think it's possible to do a better job than what was done with HTML. The point is, if we're going to change what fragment syntax means in the context of URNs, it's going to potentially break a lot of software out there that thinks it knows how to interpret "#" in the context of URIs. We need a really good reason to do this. At a minimum, we need to redefine fragments in a way that works a lot better than it does with HTML. One problem with HTML fragments is that because of how they're defined and implemented, they're inherently restricted to the context of a particular "file" or "page". The client generally has to download the entire "page" before it can search for the specific fragment that was requested. This works marginally well for relatively small text files, horribly for many other kinds of media, like large video programs. Another problem with HTML-style fragments is that they're restricted to regions of a document that don't overlap the boundaries of other portions of the document hierarchy. So while you can have a fragment that only consists of a portion of a paragraph, you can't have a fragment that consists of the end of one paragraph followed by the start of the next. Nor can you have two fragments that overlap each other unless one is a strict subset of the other. Nor can a fragment contain sections of multiple files, even though it's quite common to represent a single document as large numbers of HTML files. And fragment names are arbitrary - there's no controlled vocabulary for them so there's no portable way to talk about volumes or chapters or sections or pages or timecode ranges, etc. And there are many other limitations of HTML's way of defining fragments. So if we're going to redefine how fragments work in the context of URNs, let's do it in a way that makes them a lot more flexible and broadly applicable. At the very least it should be possible to pass a fragment identifier to a resolver, and for that resolver to be able to say "in order to find the specific fragment you're interested in, you need to download only this one file rather than all of the files associated with the resource". Or maybe "in order to find the fragment X, pass query parameter Y to the resource". And in the absence of any specific instructions from the resolver, fragment processing should fall back to the current behavior. Keith From nobody Thu Aug 7 08:03:47 2014 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 1A8E61B2BE8 for ; Thu, 7 Aug 2014 08:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 AdCS-8C0HsZj for ; Thu, 7 Aug 2014 08:03:29 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2DC11B2BF8 for ; Thu, 7 Aug 2014 08:03:13 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by gateway1.nyi.internal (Postfix) with ESMTP id EBF462328B for ; Thu, 7 Aug 2014 11:02:19 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 07 Aug 2014 11:02:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=LuYqupHyq8yKofGZ7tS7H8 o07po=; b=RjfhFoj06KZp73ypbjTLh22bW9xcTu/1EeJPPY25fRxcRGhakV0uyp s/Ilt3b69nsFryCq/YHqy5m2VcW4giYBYrzlDGL61WJiYdK73A68b4XxgHszcuZR s/mLtd2g90jX++JuXIcYrXdERkJwVuAjKbAinrawDwSoezpiMmZWg= X-Sasl-enc: ZyaRaxizuFBuYIS2N2rdFTvlvsoqfIaHiGvrzR4OXihO 1407423738 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 444AF68027A; Thu, 7 Aug 2014 11:02:18 -0400 (EDT) Message-ID: <53E394E6.5050908@network-heretics.com> Date: Thu, 07 Aug 2014 11:01:58 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <53E3296F.1020407@helsinki.fi> In-Reply-To: <53E3296F.1020407@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/rcAvzP7hsVziwQfPFmfajMUMUyE Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 15:03:41 -0000 On 08/07/2014 03:23 AM, Juha Hakala wrote: >> I understand the desire to pass parameters to resolvers, but (a) why >> does this need to use URI query syntax, and (b) why does this need to >> be bundled with the URN at all? (since it's not referencing a >> portion of the resource, but really, a completely different resource) > > Based on the implementer experiences of other persistent identifier > communities, using query for this purpose seems to be a simple and > efficient means for making service requests. Moreover, implementing > some other method would make it more difficult to make ARK / Handle / > URN resolvers interoperable. One more thing. I don't think it's at all necessary for URN modifier syntax to be consistent with ARK, Handle, DOI, etc. modifier syntax. Widespread existing practice, standards, and history dating to the beginning of the web, all consistently are that interpretation of "?" is specific to the URI scheme. A client implementation is going to treat each URI scheme separately. Once it identifies the beginning and end of a URI, the next thing it does is look at the scheme name, and from the scheme name it knows how to interpret the rest of the URI. There should be no expectation that the client code to handle URNs is the same as the code to handle Handles or other persistent identifiers. Even if there are resolvers that can handle multiple kinds of persistent identifiers (and I can certainly see that this would be useful), there's no reason to impose the same syntax rules on all of those identifiers. The URI scheme-specific code in each client can manage the details of parsing each kind of URI, identifying the relevant portions of each, and converting those data to a query to be sent to the resolver. I can see where it would be useful to agree on common vocabulary and semantics for different resolver query parameters across the different kinds of persistent URIs, but forcing all of those URIs into the same syntax seems like a bad idea. More broadly, the other persistent URI schemes, for better or worse, chose to go their own way rather than to be URN namespaces. Presumably they had their reasons for doing so, and I won't try to second-guess them. But it seems likely that at least some of them didn't want to adhere to quite the same set of constraints as are imposed on URNs, and maybe they wanted to impose some constraints that URNs don't impose. Or maybe they had somewhat different scopes in mind for what they were trying to name, a different set of goals than we had when defining URNs. Whatever their reasons, without at least some formal agreement from the maintainers of the other namespaces to conform to a common syntax, trying to align the syntax of URNs with those namespace seems like a bad idea. It has the potential to limit the extensibility of both URNs and those other kinds of identifiers. And I really think it's far too soon, and there is far too little experience, to try to impose strong constraints on the set of modifiers for identifiers for network-accessible resources. So if persistent identifier scheme xyx has defined "?" to mean one thing, I don't think we should consider that an imposition on URNs at all. We should do what makes the most sense for URNs, and sort out the differences at a lower layer. Keith From nobody Thu Aug 7 08:13:06 2014 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 48CC41B2C7D for ; Thu, 7 Aug 2014 08:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 5dibAUlynbjK for ; Thu, 7 Aug 2014 08:12:56 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 2363E1B2C09 for ; Thu, 7 Aug 2014 08:12:25 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta14.westchester.pa.mail.comcast.net with comcast id bqVC1o0031uE5Es5ErCR7f; Thu, 07 Aug 2014 15:12:25 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta16.westchester.pa.mail.comcast.net with comcast id brCR1o00Q1KKtkw3crCRVe; Thu, 07 Aug 2014 15:12:25 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s77FCOLr001185 for ; Thu, 7 Aug 2014 11:12:25 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s77FCOST001184; Thu, 7 Aug 2014 11:12:24 -0400 Date: Thu, 7 Aug 2014 11:12:24 -0400 Message-Id: <201408071512.s77FCOST001184@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org In-reply-to: (ht@inf.ed.ac.uk) References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407424345; bh=DTVm86wEfPuYlOtQ4DBckc0LBYfXUdbXnjjrDDPyxRw=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=imsXhF35LEm3keP8uItsHlKt/WqVSTEMRTIrM7cBmPDG7XVUdeTR5QCXFLU8DjX92 wdQ0fHVgWVznR6GwZJeiLKk0Kg0JpyX6UCQElEBPyU5DTRS5Kl3uckTdrGMkRcIlR2 c16hkqmi+QGaRCG50++VUR1le0Aa2BaZT7EZtpGQJyuR3fIp+jFp77Oi89gasa/tO4 Pt1XCaJiEHWvqv9G8CoDICgDGAJ5x7px2tTTEsDiiw3Qn23AyQEb0t6gE7Kdb5xdDQ 0ew/nDdbuh13uxHS+Ow6mtKl2FZAdsCDkxvz2o92IIiNoSJaewZDSIbA6UQpw5Pkw8 IIxhl3OG1XjeA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/TCXljQlUm4DbpcnHnqZqUenx5vc Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 15:12:58 -0000 > From: ht@inf.ed.ac.uk (Henry S. Thompson) > Would these be acceptable formulations of the _requirements_ (I'm > guessing here, help me out): > > 1) Given a URN which identifies a publication, it should be possible > to construct another URN which identifies specific aspects of the > metadata for that publication, such that the right thing will > happen if the resulting URN is resolved; > > 2) Given a URN which identifies a publication, it should be possible > to construct another URN which identifies a specific sub-part of > that publication. Let's also add that it would be desirable to: (3) Be able to algorithmically distinguish these "derived" URNs from their "base" URNs. (4) Algorithmically reverse these transformations, that is, to compute the "base" URN from the "derived" URN. Dale From nobody Thu Aug 7 08:15:26 2014 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 97B8C1B2A68 for ; Thu, 7 Aug 2014 08:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 GtOd5sbgza5S for ; Thu, 7 Aug 2014 08:15:23 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id A1A871B2CBF for ; Thu, 7 Aug 2014 08:15:15 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta08.westchester.pa.mail.comcast.net with comcast id br511o0050Fqzac58rFF0Z; Thu, 07 Aug 2014 15:15:15 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta08.westchester.pa.mail.comcast.net with comcast id brFE1o00c1KKtkw3UrFEAp; Thu, 07 Aug 2014 15:15:15 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s77FFE1V001329; Thu, 7 Aug 2014 11:15:14 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s77FFDfx001328; Thu, 7 Aug 2014 11:15:13 -0400 Date: Thu, 7 Aug 2014 11:15:13 -0400 Message-Id: <201408071515.s77FFDfx001328@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: ht@inf.ed.ac.uk (Henry S. Thompson) In-reply-to: (ht@inf.ed.ac.uk) References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407424515; bh=Wu+x8VZIir/87uAIpvUJhnlLu2l6Pxy69d6aTjLKm0s=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=iO3GCJ9JRK8UaHs1Tl8Gn6oR4GNAwU3PMjDRLmqRJqLpMWjY24DaHcqs/8wVANDzv x8GOWqpU40iA2O2jdWCpKBFjHUytBSweMMMaAdScKFcfzTBTHW1IcBk93Dfc6qiL0Q BmCxJlx4zSBb+5ZY5zcLd9dai1AsinyFg8F2CpJ/ocZ1iz40xehuuR6kWKici51gw6 0clmRU3WvMXVkDyyT/JCGV5lOgIhPkfnBauVqUDFvkmAiqZSRkAQA3U1bfeBZ5upZb fFZWeuuEqxL3DvR9Z1PW4wbU8O7PneB7emT+Y+4vFcj91pKXcBQrjbhhNwCYWHJ5Au o3e3FZWPQHW2Q== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/C5qiRMj40VF_wmvZVL0SohDdG7k Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 15:15:24 -0000 > From: ht@inf.ed.ac.uk (Henry S. Thompson) > Not to be awkward, but if the direction the working group intends to > take is substantially determined along the following lines (quoting > from [1]): > > To name the two most important practical things, we need to be able to > - use URI query to pass resolution related parameters to URN resolvers, and > - use URI fragment to enable citing / referencing of identified resources. > > This can be done iff we agree that query and fragment are not part of > the NSS (that is, in the URN context they do not identify anything). > > then I'm _not_ happy with its direction. A working group to address > requirements on URNs not currently (perceived) to be met is one > thing. A working group to implement a particular pair of solutions is > quite another. Beware that there might be a typographical error involved here. In the innermost quote, there is the word "iff". That means "if and only if", and in this context, it means "The only way that this can be done is if we agree that ...". But it may be a mistake, and the intention was "if". In that case, the sentence means "One way that this can be done is if we agree that ...". Dale From nobody Thu Aug 7 08:26:19 2014 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 F1CC61B2BF8 for ; Thu, 7 Aug 2014 08:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 tzQ_B6R-X2Qp for ; Thu, 7 Aug 2014 08:26:16 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFFB1B2BD5 for ; Thu, 7 Aug 2014 08:26:16 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id bpLT1o0021vXlb853rSGxZ; Thu, 07 Aug 2014 15:26:16 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta17.westchester.pa.mail.comcast.net with comcast id brSF1o00i1KKtkw3drSFiH; Thu, 07 Aug 2014 15:26:16 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s77FQFIt001942; Thu, 7 Aug 2014 11:26:15 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s77FQEN9001941; Thu, 7 Aug 2014 11:26:14 -0400 Date: Thu, 7 Aug 2014 11:26:14 -0400 Message-Id: <201408071526.s77FQEN9001941@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Juha Hakala In-reply-to: <53E31045.3080704@helsinki.fi> (juha.hakala@helsinki.fi) References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E31045.3080704@helsinki.fi> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407425176; bh=fbgV+VNwAmup2JM6BQVZWVYcRfDcp9qicMdwFBL0noo=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=UOekFMKL35hMewhKrrCuSYIOqI1wT0zNkEQq9z7SZGPkTBcXlTIBAGNsNfVi5ZCyw c/ojgeeVvKEVLSzY+jCUlFLlmelpCfuvendXNsQir+hUrNEuiI5k58SEy8Xi/VQsEt gOIHyi8kC86n2uOoUhDU9mxZ+S0RiF0QE/9AN4fDYbRHbhsTNwORm4WQwaDKOCXFIl ZJH0gA5g6mn6nWDKMuDZbDY3AeiHcFi8/mx/Hy1uvr7rvCEj/zf3w1FT+3lFwbY3Q7 MMmvwcnBWr1UNje0Fdfh5h3Sa533d+hG0MHpQQ98Oea3KVrePvQb/y+gZttrsRGd2J zsR8zFT+zz3aA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/10YOqXjlvjvq3tYwrOwl_wJZlLQ Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 15:26:19 -0000 > From: Juha Hakala > RFC 2483 specifies URI to URC service, which: > > ... allows the client to obtain a description of the resource > identified by a URI, as opposed to the resource itself or simply the > resource's URLs. The description might be a bibliographic citation, a > digital signature, or a revision history. This memo does not specify > the content of any response to a URC request. That content is > expected to vary from one server to another. > > So, we might have a requirement to support URI to URC, but in an updated > form so that it is possible to specify the metadata format. IMO there is > no need to go further and allow retrieval of individual metadata elements. > > It is my intention to revise RFC 2483 since several relevant services > are missing from it, and we also need a simple mechanism for specifying > additional services and service parameters (such as metadata formats to > URI to URC). > > The implementer community has a requirement for these additional > services missing from RFC 2483, but more urgently, we need a simple > mechanism for passing service parameters to resolvers. DDDS, specified > in RFCs 3401-3404, has for some reason not been implemented in URN > resolvers. Instead, the community developing these applications wishes > to follow the example of ARK and Handle/DOI communities - use query for > sending service requests to resolvers. The overall discussion seems to me to be confusing two issues: 1) Given a URN, there must be a way of obtaining metadata (and other related information) about the named object. There must be a way of providing resolution process with "service parameters". 2) Given a URN, there must be a way of constructing a character string (which is a URN, or perhaps an "extended URN"), which, when input to the resolution process, can obtain metadata and provide the resolution process with service parameters. Now, (2) -- if we decide to accept it -- is a requirement of *URN syntax and semantics*, and is within our remit. If we decide that (1) is sufficient, then we do not need to have (2) as a requirement, and how to satisfy (1) is not within our remit. In particular, if we would like to envision resolution services that are implemented by making HTTP GET requests, there is no particular reason that URNs have to look exactly like what is sent in the GET request, and (for example) the fact that using query parts in GET requests is useful to carry some bit of information does not imply that that bit of information must be in the URN in a query part. (Unless we add the requirement: 3) The URN must be enterable directly into an existing browser and cause the resource to be fetched.) There are a bunch of service mechanisms for URNs described in the RFCs mentioned above. As far as I know, none of them have been widely implemented. In regard to URN syntax and semantics, it does not seem to have been important in determining whether these service mechanisms are implemented. Dale From nobody Thu Aug 7 08:28:47 2014 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 696F11B2BF8 for ; Thu, 7 Aug 2014 08:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 Js_tWVPyxSCY for ; Thu, 7 Aug 2014 08:28:43 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 6316B1B2C25 for ; Thu, 7 Aug 2014 08:28:37 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA11.westchester.pa.mail.comcast.net with comcast id boET1o0061GhbT85BrUdhl; Thu, 07 Aug 2014 15:28:37 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta07.westchester.pa.mail.comcast.net with comcast id brUc1o00L1KKtkw3TrUcef; Thu, 07 Aug 2014 15:28:37 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s77FSaIY002042; Thu, 7 Aug 2014 11:28:36 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s77FSabS002041; Thu, 7 Aug 2014 11:28:36 -0400 Date: Thu, 7 Aug 2014 11:28:36 -0400 Message-Id: <201408071528.s77FSabS002041@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Juha Hakala In-reply-to: <53E316FC.4090903@helsinki.fi> (juha.hakala@helsinki.fi) References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <201408062053.s76KrYFJ011175@hobgoblin.ariadne.com> <53E316FC.4090903@helsinki.fi> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407425317; bh=/60QRu3VpzTfNB2YzQypd4zyKMb1fiRoEjpt9KxpTFw=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=OT/ZJS3mexOhwQLaD9d5wEMXbitAhonn0O0xvJPfa4XmUVnqSsEv2RLkWepT1nHl4 1uQ/9cnHKtHy45uJ5erznDBB1tZEiQdHV6kGxN2Uz2jqhvIjYwBnNx8KbpX7zGp9u8 W+eTVKe/RkNm+bz2jbvU7WwJgq4puMGHmX5ci68UO1U81my5AZOTn7N7KUg72JPe+0 bgasEv2Uu9pi6YKxqohhbftGw+fZDljV0pZKwrLtwoITf4MzC8cvmVGQWeDvaq148y iBR3Pgybo29nAXFFwaEBkeml4M4/yYAtkbq6mOzDjNXuk64cOYsqQtuFBPRi8rQF/w u98b68pilD4QQ== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/95cbxJI0GxxlFS_p9BnFsq0DHtU Cc: urn@ietf.org, moore@network-heretics.com Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 15:28:45 -0000 > From: Juha Hakala > Within the URN system namespaces, the rules of identifier systems apply. > These rules may or may not agree with URI Generic Syntax. The important > thing is that the ISBN user manual overrides what RFC 3986 says about > the role of fragments in identification. You speak of "rules of identifier systems" as if they are pre-existing. Can you explain the nature of "rules of identifier systems"? Can you amplify this into clear requirements on URN syntax and semantics? Dale From nobody Thu Aug 7 08:31:35 2014 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 745D81B2C47 for ; Thu, 7 Aug 2014 08:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 kGYkbW8oBqQH for ; Thu, 7 Aug 2014 08:31:33 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id D90A51B2C21 for ; Thu, 7 Aug 2014 08:31:32 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta10.westchester.pa.mail.comcast.net with comcast id boiL1o0040mv7h05ArXYwq; Thu, 07 Aug 2014 15:31:32 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta11.westchester.pa.mail.comcast.net with comcast id brXY1o00C1KKtkw3XrXYHd; Thu, 07 Aug 2014 15:31:32 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s77FVVZ4002232; Thu, 7 Aug 2014 11:31:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s77FVVnr002231; Thu, 7 Aug 2014 11:31:31 -0400 Date: Thu, 7 Aug 2014 11:31:31 -0400 Message-Id: <201408071531.s77FVVnr002231@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Juha Hakala In-reply-to: <53E3296F.1020407@helsinki.fi> (juha.hakala@helsinki.fi) References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <53E3296F.1020407@helsinki.fi> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407425492; bh=4r8R8eIviLUBMX1tK3ac8S1nNa9tA6HiqmP8VYzZuVA=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Vr7tT9lBCWFRzFr/3Kp8Qnf1GObRNcpL6tSJGLdyjlUa6hwHJLMuuhI9SEycAC+Qd XE3RLDE0EUQ0GoJfUs76KRX1ROJO4MkRMW76WRNvjTAkkwnpT0Y2TSIzdmNebtNl1a 96PXZAvAbv2bGF3ZZEBYFjeOnrnMzuP3pQ+k1IGMymq6KGV5JwSozrn8Xm2b4vNndt R693moYObzrBuW2VGqJz///4i+x9gCKqgHNA4/ufUzn8NGoIPubS2SzUx0uG0ooDhp qqDjrVTVyvlUB9nlLGw+6z0T98PGV+5+mMFpabNB5N/ohbIuxLQg/D3L6sVZO3hkek s2IT/TckE+otw== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/IlP0uhHKpKNoDbDwhwhbaexzf7g Cc: urn@ietf.org, moore@network-heretics.com Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 15:31:34 -0000 > From: Juha Hakala > Based on the implementer experiences of other persistent identifier > communities, using query for this purpose seems to be a simple and > efficient means for making service requests. That is an assertion about implementation convenience, not a requirement. > Moreover, implementing some other method would make it more > difficult to make ARK / Handle / URN resolvers interoperable. Can you state what this interoperability requirement is? Not knowing much about the subject, I would assume that ARK resolvers, handle resolvers, and URN resolvers would all have to be communicated with in different manners. Dale From nobody Thu Aug 7 10:34:59 2014 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 E43681A0083 for ; Thu, 7 Aug 2014 10:34:56 -0700 (PDT) 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 jDu5tYCDfvnz for ; Thu, 7 Aug 2014 10:34:53 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719D71A006C for ; Thu, 7 Aug 2014 10:34:51 -0700 (PDT) Received: from webmail-3.mappi.helsinki.fi (webmail-3.mappi.helsinki.fi [128.214.20.217]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s77HYbGa025271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2014 20:34:37 +0300 Received: from a88-114-99-137.elisa-laajakaista.fi (a88-114-99-137.elisa-laajakaista.fi [88.114.99.137]) by webmail.helsinki.fi (Horde Framework) with HTTP; Thu, 07 Aug 2014 20:34:35 +0300 Date: Thu, 07 Aug 2014 20:34:35 +0300 Message-ID: <20140807203435.Horde.pJHMTpPulJNNuDdE93z5qQ6@webmail.helsinki.fi> From: jehakala@mappi.helsinki.fi To: worley@ariadne.com References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <201408062053.s76KrYFJ011175@hobgoblin.ariadne.com> <53E316FC.4090903@helsinki.fi> <201408071528.s77FSabS002041@hobgoblin.ariadne.com> In-Reply-To: <201408071528.s77FSabS002041@hobgoblin.ariadne.com> User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/urn/QswQzPwC-Gk4V5CbJS1X1zA6pyk Cc: urn@ietf.org, moore@network-heretics.com Subject: [urn] Rules for identifier systems 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: Thu, 07 Aug 2014 17:34:57 -0000 Hi Dale, Quoting worley@ariadne.com: >> From: Juha Hakala > >> Within the URN system namespaces, the rules of identifier systems apply. >> These rules may or may not agree with URI Generic Syntax. The important >> thing is that the ISBN user manual overrides what RFC 3986 says about >> the role of fragments in identification. > > You speak of "rules of identifier systems" as if they are > pre-existing. Can you explain the nature of "rules of identifier > systems"? Can you amplify this into clear requirements on URN syntax > and semantics? These rules certainly exist, but they are always namespace specific. There are no written rules which apply to e.g. all the ISO identifiers, although you can safely assume that all these identifiers are both unique and persistent. That is of course just a beginning. In addition to the general principles included in the standard publication, there are usually user guides / manuals maintained by the international centre responsible of the standard and the user community. For instance, the ISSN manual is available here http://www.issn.org/understanding-the-issn/assignment-rules/issn-manual/ ISBN manual is available in several languages here: https://www.isbn-international.org/content/isbn-users-manual There are also loosely managed URN namespaces such as UUID which do not have (any) principles concerning what can be identified and by whom. But the URN system must accommodate even those traditional identifiers which are strictly managed. Allowing substantial changes in existing practices would be regarded as extremely disruptive by the communities affected. So I can say, for instance, that URN must not extend the scope of identifier systems (by for instance enabling ISBN assignment to physical fragments of books) and URN also must not allow people who are not entitled to do so by the community rules to assign ISBNs. From my point of view, a persistent problem in URNBIS is that while the IETF community is very familiar with e.g. URI syntax, few people outside the identifier communities are aware of the implications of using these identifiers in the URN context. We have had a fair amount of semantic misunderstandings as a result of that. Of course this is mainly my fault; I have frequently failed to make my intentions clear enough. Juha > > Dale From nobody Thu Aug 7 10:49:41 2014 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 1CA2A1A0135 for ; Thu, 7 Aug 2014 10:49:39 -0700 (PDT) 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 g5GK9f7xwx_2 for ; Thu, 7 Aug 2014 10:49:37 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553571A0016 for ; Thu, 7 Aug 2014 10:49:37 -0700 (PDT) Received: from webmail-3.mappi.helsinki.fi (webmail-3.mappi.helsinki.fi [128.214.20.217]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s77HnKZg008241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2014 20:49:20 +0300 Received: from a88-114-99-137.elisa-laajakaista.fi (a88-114-99-137.elisa-laajakaista.fi [88.114.99.137]) by webmail.helsinki.fi (Horde Framework) with HTTP; Thu, 07 Aug 2014 20:49:18 +0300 Date: Thu, 07 Aug 2014 20:49:18 +0300 Message-ID: <20140807204918.Horde.tj4KNGSs3dFfYOcx7Y8AJA3@webmail.helsinki.fi> From: jehakala@mappi.helsinki.fi To: worley@ariadne.com References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <201408071515.s77FFDfx001328@hobgoblin.ariadne.com> In-Reply-To: <201408071515.s77FFDfx001328@hobgoblin.ariadne.com> User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/urn/7z1WlPf7KnzY-1w_Wv3ScF7Py9c Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 17:49:39 -0000 Hello, Quoting worley@ariadne.com: >> From: ht@inf.ed.ac.uk (Henry S. Thompson) > >> Not to be awkward, but if the direction the working group intends to >> take is substantially determined along the following lines (quoting >> from [1]): >> >> To name the two most important practical things, we need to be able to >> - use URI query to pass resolution related parameters to URN >> resolvers, and >> - use URI fragment to enable citing / referencing of identified resources. >> >> This can be done iff we agree that query and fragment are not part of >> the NSS (that is, in the URN context they do not identify anything). >> >> then I'm _not_ happy with its direction. A working group to address >> requirements on URNs not currently (perceived) to be met is one >> thing. A working group to implement a particular pair of solutions is >> quite another. > > Beware that there might be a typographical error involved here. In > the innermost quote, there is the word "iff". That means "if and only > if", and in this context, it means "The only way that this can be done > is if we agree that ...". "iff" was intentional. The reason for this is that if fragment and query were part of NSS, URN would extend the scope of several existing identifier systems in an unacceptable manner (unacceptable from the point of view of rules for identifier assignment, as specified in user manuals etc). Of course there can be other methods for passing queries to resolvers. DDDS is already in place, but has not been implemented, which is why we need to consider an alternative. Some other DNS-based solutions may be developed in the future. Moreover, only a small set of pre-specified queries would be reserved for resolution service requests. People who have other ideas on how to use queries in the URN context would be welcome to do so, as long as they avoid reserved things (for instance, "s=" can be used to indicate service specification and "p=" service parameter. Juha > > But it may be a mistake, and the intention was "if". In that case, > the sentence means "One way that this can be done is if we agree that > ...". > > Dale > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Thu Aug 7 11:25:55 2014 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 3B5FA1A0386 for ; Thu, 7 Aug 2014 11:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, 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 wf-5sZ3YzLNa for ; Thu, 7 Aug 2014 11:25:49 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0201A0368 for ; Thu, 7 Aug 2014 11:25:48 -0700 (PDT) Received: from webmail-3.mappi.helsinki.fi (webmail-3.mappi.helsinki.fi [128.214.20.217]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s77IPmPZ028946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Aug 2014 21:25:48 +0300 Received: from a88-114-99-137.elisa-laajakaista.fi (a88-114-99-137.elisa-laajakaista.fi [88.114.99.137]) by webmail.helsinki.fi (Horde Framework) with HTTP; Thu, 07 Aug 2014 21:25:46 +0300 Date: Thu, 07 Aug 2014 21:25:46 +0300 Message-ID: <20140807212546.Horde.P6cY6C6pbAvcvqctbFg4vw9@webmail.helsinki.fi> From: jehakala@mappi.helsinki.fi To: Keith Moore References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <53E3296F.1020407@helsinki.fi> <53E390DF.6000305@network-heretics.com> In-Reply-To: <53E390DF.6000305@network-heretics.com> User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/urn/W_JxqUgZojEVIXcQDB-1hv3FlWw Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 18:25:52 -0000 Hello, Quoting Keith Moore : > On 08/07/2014 03:23 AM, Juha Hakala wrote: >> Hello Keith, >> >> >> >> Based on the implementer experiences of other persistent identifier >> communities, using query for this purpose seems to be a simple and >> efficient means for making service requests. Moreover, implementing >> some other method would make it more difficult to make ARK / Handle >> / URN resolvers interoperable. > > I don't think this is a good enough reason to overload query syntax. > > Or perhaps I should rephrase the question: Why is it more important > to use URI query syntax to pass parameters to URN resolvers, than it > is to be able to use URI query syntax to pass messages to the > resources named by those URNs? These things are not mutually exclusive. We need only a very small subset of all possible URN queries for service requests. There will be a lot of room for other kind of query usage. Because we know from vast experience > that it's tremendously useful to be able to bundle a URI that > identifies a resource with a message that gets passed to that > resource and which potentially affects the information returned by > that resource. It's probably not a stretch to estimate that nearly > every web server provides access to a few resources that work this > way. OK. > > To me it also seems incredibly shortsighted to define query syntax > with URNs in such a way as to preclude being able to bundle a > message to be passed to the resource, with the URN. That would > essentially be saying that it's more important to optimize URNs to > work with fixed/physical media resources than to optimize URNs to > work with network-connected resources... which is indeed odd > considering that URNs were created primarily for the latter purpose. It has never been an intention to prevent other query usages; all we ask is to be able to use query also for service requests. > > Or to put it another way: URI syntax (as defined and in practice) > really limits the number of modifiers with which URIs can be > bundled, and doesn't leave much room for extensibility. Do we > really want to restrict the use of "?" with URNs in such a way that > the only thing that can be done with it is to pass parameters to a > resolver? No, we certainly don't want to do that. I > think I understand why people want to bundle resolver queries with > URNs, but I also think that that's about the least compelling use > case I can think of for attaching modifiers to a URN. Certainly it > seems less compelling than wanting to narrow the resource being > named to a particular facet of that resource like chapter or edition > or language or timecode range, and less compelling than wanting to > include a message/query to be sent to the resource. Still, I don't > want to say "you cannot bundle a resolver query with a URN". I am > just saying "please, let's define a way to do that, that doesn't > prevent other kinds of modifiers to be bundled with URNs". That has been our intention all the time. That's why we need to specify query syntax for each resolution request that can be made. > > So I think we should try to define URN modifiers in such a way that > there's some room for expansion, as we will surely discover new > compelling use cases in the future. Simply redefining "?" and "#" > to have different meanings than for other URIs, while being > consistent with syntax for other URIs, won't leave room for > expansion. I want us to define an extensible syntax for URN > modifiers, such that a client can tell which modifiers are resolver > queries, which ones are facets that narrow the resource being named, > and so forth. And I want to do it in such a way that doesn't break > existing things that understand URIs. We have to consider carefully which kind of queries can / should be specified, and where. There are valid implementation needs which could be disruptive in some namespaces / application environments, but OK elsewhere. >> >> Since query is not part of the NSS, the original URN and the URN >> with query identify the same thing (that is, they are lexically >> equivalent). > > Well, no. They both contain the same URN, but it's misleading at > best to say that the two are equivalent. You should not, for > instance, treat them as equivalent for the purpose of caching the > result. Equivalence is probably not a very useful concept when > talking about extended URNs. You can compare the URNs embedded in > them, and that might occasionally be useful. But comparing two > extended URNs in their entirety probably won't be useful for much. This depends on how we define lexical equivalence. If the criterium is that two URNs are equivalent if they identify the same thing, then NSS is the only thing we need to consider, and we can ignore fragment and query when comparing URNs. In the current rfc2141bis lexical equivalence has been specified like this. If we include fragment and query in the comparison, things get very complicated. For instance, you can have one identifier which covers two different versions (difference being the mime type) of the same document. Two URNs which have fragments indicating exactly the same location within the identified versions of the document will not look identical, but they are lexically equivalent. You may also have URN with two different queries which retrieve the same bibliographic record from two databases. Again, these URNs look different but are lexically equivalent. I fully agree that equivalence is not a useful concept if we include fragment and query in the analysis. We are better off ignoring them. > >> >> In many URN namespaces, it is impossible to extend the scope of the >> identifier in the manner URI query would require. But even if the >> namespace were so liberal as to approve query usage in >> identification, "name for something else entirely" would become a >> major problem. In my opinion, saying that URI query identifies >> something just cannot be right in any context. > > This probably a minor point, but I disagree. It's reasonable to say > that an HTTP URL with a query identifies something, and it's as > reasonable to say that a URN with a query identifies something. It's > not reasonable to assume in either case that the binding between the > URI and what is identified, is persistent. It may be reasonable to say that URN with query identifies something else than the identified document from the IETF point of view, but I repeat, extending the scope of existing identifier systems like this is totally unacceptable and also impractical. URN:ISBN can be used to identify a book, but URN:ISBN extended with query cannot be used to identify a bibliographic record. Of course we could avoid all problems by specifying a new namespace for this extended URN, but then there would be two other problems: there are already identifiers for bibliographic records, and queries, unlike namespace specific strings, are not likely to be persistent. >>> >>>> - use URI fragment to enable citing / referencing of identified resources. >>> >>> Again, why does this need to overload URI fragment syntax? >> >> I do not think that allowing the use of fragments with URNs >> overloads the URI fragment syntax. > > The current meaning of fragment syntax is defined by the media type, > and fragments are evaluated according to the rules of the media > type. If you are proposing to do it differently for URNs, that's > overloading the syntax. No, I am suggesting that fragment is used with URNs exactly as they are used with URIs. No difference whatsover is needed for syntax or overall purpose. We only need to say that in the URN context fragment does not identify anything, to accommodate the existing identifier systems. Please note that URN + fragment is valid iff the identifier applies to single manifestation of a resource only. There will be plenty on namespaces where fragments cannot be used, because the identifier does not apply to any resources, is not resolvable, or applies to multiple resources (files). > > Now, having said that, I'll readily admit that HTML fragments are > really poorly designed and not terribly useful. And I haven't seen > fragments used frequently with other kinds of media, so I don't know > how useful they are with other media types. But I think it's > possible to do a better job than what was done with HTML. > > The point is, if we're going to change what fragment syntax means in > the context of URNs, it's going to potentially break a lot of > software out there that thinks it knows how to interpret "#" in the > context of URIs. We need a really good reason to do this. At a > minimum, we need to redefine fragments in a way that works a lot > better than it does with HTML. I sincerely hope that URNBIS does not need to touch this can of worms ;-). Juha > > One problem with HTML fragments is that because of how they're > defined and implemented, they're inherently restricted to the > context of a particular "file" or "page". The client generally has > to download the entire "page" before it can search for the specific > fragment that was requested. This works marginally well for > relatively small text files, horribly for many other kinds of media, > like large video programs. Another problem with HTML-style > fragments is that they're restricted to regions of a document that > don't overlap the boundaries of other portions of the document > hierarchy. So while you can have a fragment that only consists of > a portion of a paragraph, you can't have a fragment that consists of > the end of one paragraph followed by the start of the next. Nor can > you have two fragments that overlap each other unless one is a > strict subset of the other. Nor can a fragment contain sections of > multiple files, even though it's quite common to represent a single > document as large numbers of HTML files. And fragment names are > arbitrary - there's no controlled vocabulary for them so there's no > portable way to talk about volumes or chapters or sections or pages > or timecode ranges, etc. And there are many other limitations of > HTML's way of defining fragments. > > So if we're going to redefine how fragments work in the context of > URNs, let's do it in a way that makes them a lot more flexible and > broadly applicable. At the very least it should be possible to > pass a fragment identifier to a resolver, and for that resolver to > be able to say "in order to find the specific fragment you're > interested in, you need to download only this one file rather than > all of the files associated with the resource". Or maybe "in order > to find the fragment X, pass query parameter Y to the resource". And > in the absence of any specific instructions from the resolver, > fragment processing should fall back to the current behavior. > > Keith From nobody Thu Aug 7 11:28:43 2014 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 CC0881A03A0 for ; Thu, 7 Aug 2014 11:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 lTnb7wRHsjdM for ; Thu, 7 Aug 2014 11:28:41 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65D61A03A9 for ; Thu, 7 Aug 2014 11:28:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by gateway1.nyi.internal (Postfix) with ESMTP id C5AAC21DBB for ; Thu, 7 Aug 2014 14:28:22 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 07 Aug 2014 14:28:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=ksP0lh0fofSacBHQeEEREV DEEUs=; b=Xu1ddFvvvLFTqxDusfUnbzh6uXk6kqidTqmzyfSLHO/EgCnEXrNlcO faINlqZo/JheGEgBB2bnbVFnwYLZN7L3plpfo0YMPuABsD1DVOY0ny2pTYQUoZCO 0OlQuT0qZBTUOTcsWiuJChh863ulBnUcp9ZvHfCPgc5uekJip1Al0= X-Sasl-enc: pdmfmEFtUaR0GJSvDWBZqP3OnFX67T7LZA2q3iDN+hNv 1407436102 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 72E06C007AB; Thu, 7 Aug 2014 14:28:21 -0400 (EDT) Message-ID: <53E3C531.9050809@network-heretics.com> Date: Thu, 07 Aug 2014 14:28:01 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: jehakala@mappi.helsinki.fi, worley@ariadne.com References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <201408062053.s76KrYFJ011175@hobgoblin.ariadne.com> <53E316FC.4090903@helsinki.fi> <201408071528.s77FSabS002041@hobgoblin.ariadne.com> <20140807203435.Horde.pJHMTpPulJNNuDdE93z5qQ6@webmail.helsinki.fi> In-Reply-To: <20140807203435.Horde.pJHMTpPulJNNuDdE93z5qQ6@webmail.helsinki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MmzvNjoQVoHD1AsYuhwO6nR2MZk Cc: urn@ietf.org Subject: Re: [urn] Rules for identifier systems 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: Thu, 07 Aug 2014 18:28:43 -0000 On 08/07/2014 01:34 PM, jehakala@mappi.helsinki.fi wrote: > So I can say, for instance, that URN must not extend the scope of > identifier systems (by for instance enabling ISBN assignment to > physical fragments of books) and URN also must not allow people who > are not entitled to do so by the community rules to assign ISBNs. That seems reasonable. However, if there were a syntax and controlled vocabulary that allowed one to refer to, say, a chapter of a resource named by a URN, the meaning of that notation as applied to a URN with namespace isbn would be relatively unambiguous. But I think that as a practical necessity, even with such a controlled vocabulary, there's going to be a need to consult a resolution service to understand how to interpret something like a "chapter" relative to a network-accessible resource. So if the resolution service consulted for "isbn" basically said "chapter is not a defined term for this resource" or more likely "the only vocabulary terms that are supported by this service are x, y, and z", I think that would be sufficient. (And of course, someone using "urn:isbn:1234/chapter-number=3" wouldn't be assigning a new ISBN or even a new ISBN URN; they'd be generating an extended URN consisting of an ISBN URN and a chapter reference. Just as with a query or a fragment, the facet isn't "part of" the URN.) Or to put it differently: I think it would be a good idea to define a common vocabulary across all URNs to encourage some consistency among facet references associated with URNs. Of course not every facet will be applicable to every URN. "chapter" would rarely apply to a sound recording, and a timecode range would rarely apply to a text document. But architecturally speaking, those limitations should be presumed to be on a per-resource basis, rather than a per-NID basis. Even if some namespaces only assign URNs to certain kinds of media, that's not true for all namespaces. And the information about what facets are relevant for a particular resource should be supplied by a resolution service, rather than being wired into applications that process URNs. Keith From nobody Thu Aug 7 12:20:41 2014 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 DBCBC1A0AD7 for ; Thu, 7 Aug 2014 12:20:39 -0700 (PDT) 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_34=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 qnjQ3Y04a4Pv for ; Thu, 7 Aug 2014 12:20:37 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A7A1A0601 for ; Thu, 7 Aug 2014 12:20:36 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway1.nyi.internal (Postfix) with ESMTP id 49120200D9 for ; Thu, 7 Aug 2014 15:20:36 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 07 Aug 2014 15:20:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=9WhsXtTMdo6WlM+o0B97zq Ae6ko=; b=UN+ZqJ73O5oXQt5pB1aR0gLUfh9hZ8NLv02Yu6m4SJG3y4R5jcDtsp u4JR0OQqehqLNMnzmf5DbP2QF7PTxAxUwR7n2JDd8AlsvYOvyhzeun+2tJ8/au3w JY2vGcIoSMXxR9TcJNNC+e8DogLfDcEK/rrbFU+MQEVmfhBKb/vAQ= X-Sasl-enc: sD8NNWprmOL1NsyZy/9VlWODFEUBNj0kD23p127On0qx 1407439234 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 15D596801D8; Thu, 7 Aug 2014 15:20:31 -0400 (EDT) Message-ID: <53E3D162.7010506@network-heretics.com> Date: Thu, 07 Aug 2014 15:20:02 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: jehakala@mappi.helsinki.fi References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <53E3296F.1020407@helsinki.fi> <53E390DF.6000305@network-heretics.com> <20140807212546.Horde.P6cY6C6pbAvcvqctbFg4vw9@webmail.helsinki.fi> In-Reply-To: <20140807212546.Horde.P6cY6C6pbAvcvqctbFg4vw9@webmail.helsinki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/40UWB_awn_7adQ9ZxJn1zx8oERo Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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: Thu, 07 Aug 2014 19:20:40 -0000 On 08/07/2014 02:25 PM, jehakala@mappi.helsinki.fi wrote: > Hello, > > > Quoting Keith Moore : > >> On 08/07/2014 03:23 AM, Juha Hakala wrote: >>> Hello Keith, >>> >>> >>> >>> Based on the implementer experiences of other persistent identifier >>> communities, using query for this purpose seems to be a simple and >>> efficient means for making service requests. Moreover, implementing >>> some other method would make it more difficult to make ARK / Handle >>> / URN resolvers interoperable. >> >> I don't think this is a good enough reason to overload query syntax. >> >> Or perhaps I should rephrase the question: Why is it more important >> to use URI query syntax to pass parameters to URN resolvers, than it >> is to be able to use URI query syntax to pass messages to the >> resources named by those URNs? > > These things are not mutually exclusive. We need only a very small > subset of all possible URN queries for service requests. There will be > a lot of room for other kind of query usage. I'm not sure if this is what you have in mind or not, but: I really don't like the idea of trying to distinguish the two kinds of queries based on reserving certain keywords for resolution service requests. I think it will be very difficult to define all of the keywords that will ever be needed, and also difficult to avoid collisions with keywords used by existing resources. > >> To me it also seems incredibly shortsighted to define query syntax >> with URNs in such a way as to preclude being able to bundle a message >> to be passed to the resource, with the URN. That would essentially >> be saying that it's more important to optimize URNs to work with >> fixed/physical media resources than to optimize URNs to work with >> network-connected resources... which is indeed odd considering that >> URNs were created primarily for the latter purpose. > > It has never been an intention to prevent other query usages; all we > ask is to be able to use query also for service requests. I think it's difficult to do the latter, while using query syntax, without preventing the former. That's why I've been suggesting an alternate syntax, not using "?", for parameters to be passed to the resolver. Having said that, it occurs to me that we could have the resolution service tell the client how to process queries. It could say "for URN urn:foo:bar, parameters a, b, and c apply to the resolution service, and parameters c, d, and e apply to the resource" (overlap in the example is intentional). In the absence of such a statement, any query parameter for that URN would apply to the resource. But that still makes it difficult to standardize query parameters for resolution services without introducing the potential for a conflict with parameters used by existing resources. > >> I think I understand why people want to bundle resolver queries with >> URNs, but I also think that that's about the least compelling use >> case I can think of for attaching modifiers to a URN. Certainly it >> seems less compelling than wanting to narrow the resource being named >> to a particular facet of that resource like chapter or edition or >> language or timecode range, and less compelling than wanting to >> include a message/query to be sent to the resource. Still, I don't >> want to say "you cannot bundle a resolver query with a URN". I am >> just saying "please, let's define a way to do that, that doesn't >> prevent other kinds of modifiers to be bundled with URNs". > > That has been our intention all the time. That's why we need to > specify query syntax for each resolution request that can be made. I don't think we can reliably anticipate every resolution parameter that we're going to need. And I don't think we can use "normal" vocabulary for resolution parameters without colliding with query vocabulary already used for some set of resources. We could pick some syntax convention for resolution parameters that we believed was unlikely to conflict with existing query usage by resources. For example, we could insist that all resolution service parameters have names beginning with "@". So one could specify urn:foo:bar?@volume-number=2&@chapter-number=24 or urn:foo:bar?@request=urc (if it's not legal to use "@" there without percent-encoding it, pick a different character that is legal) For any legal character we pick, I expect that there's some web site that is using query parameters that begin with that character. But maybe that's not so bad, as long as such collisions are sufficiently rare. Most of those web sites will probably never have URNs assigned to them anyway. Question: which is better, and why? a) urn:foo:bar?@parameter1=value&@parameter2=value¶meter3=value or b) urn:foo:bar/parameter1=value/parameter2=value?parameter3=value (in both cases, parameter1 and parameter2 are interpreted by the resolution service, and parameter3 is interpreted by the resource) > >> >> So I think we should try to define URN modifiers in such a way that >> there's some room for expansion, as we will surely discover new >> compelling use cases in the future. Simply redefining "?" and "#" >> to have different meanings than for other URIs, while being >> consistent with syntax for other URIs, won't leave room for >> expansion. I want us to define an extensible syntax for URN >> modifiers, such that a client can tell which modifiers are resolver >> queries, which ones are facets that narrow the resource being named, >> and so forth. And I want to do it in such a way that doesn't break >> existing things that understand URIs. > > We have to consider carefully which kind of queries can / should be > specified, and where. There are valid implementation needs which could > be disruptive in some namespaces / application environments, but OK > elsewhere. Once we define these queries I don't think we can stop people from using them in contexts for which they make no sense, and/or for which the namespace thinks the query parameter isn't appropriate. The best we can do, I think, is have the resolution service indicate when that query parameter is an error, or is irrelevant and to be ignored, etc. That way, at least, attempts to combine queries with URNs for which the combination makes no sense, or is undefined, will fail when used. But I suspect there will be pressure to make some such queries work on a widespread basis even if some of the namespaces wish to discourage them. > >>> >>> Since query is not part of the NSS, the original URN and the URN >>> with query identify the same thing (that is, they are lexically >>> equivalent). >> >> Well, no. They both contain the same URN, but it's misleading at >> best to say that the two are equivalent. You should not, for >> instance, treat them as equivalent for the purpose of caching the >> result. Equivalence is probably not a very useful concept when >> talking about extended URNs. You can compare the URNs embedded in >> them, and that might occasionally be useful. But comparing two >> extended URNs in their entirety probably won't be useful for much. > > This depends on how we define lexical equivalence. If the criterium is > that two URNs are equivalent if they identify the same thing, then NSS > is the only thing we need to consider, and we can ignore fragment and > query when comparing URNs. Right. But two extended URNs that contain the same URNs but different modifiers do not necessarily refer to the same resource, even if they are defined relative to the same resource. If there's a need to compare two extended URNs for equivalence I think it has to take several things into account: - equivalence of base URN - if the modifiers can appear in different orders and order is irrelevant, sort the modifiers before comparing - perhaps some of those modifiers don't actually change the resource but are used for other purposes, so those should be ignored for comparison. and you have to query the resolution service to find out which modifiers are irrelevant for comparison. etc. > > In the current rfc2141bis lexical equivalence has been specified like > this. > > If we include fragment and query in the comparison, things get very > complicated. For instance, you can have one identifier which covers > two different versions (difference being the mime type) of the same > document. Two URNs which have fragments indicating exactly the same > location within the identified versions of the document will not look > identical, but they are lexically equivalent. You may also have URN > with two different queries which retrieve the same bibliographic > record from two databases. Again, these URNs look different but are > lexically equivalent. > > I fully agree that equivalence is not a useful concept if we include > fragment and query in the analysis. We are better off ignoring them. At least, as you say, it's very complicated to try to make it useful. > > >> >>> >>> In many URN namespaces, it is impossible to extend the scope of the >>> identifier in the manner URI query would require. But even if the >>> namespace were so liberal as to approve query usage in >>> identification, "name for something else entirely" would become a >>> major problem. In my opinion, saying that URI query identifies >>> something just cannot be right in any context. >> >> This probably a minor point, but I disagree. It's reasonable to say >> that an HTTP URL with a query identifies something, and it's as >> reasonable to say that a URN with a query identifies something. It's >> not reasonable to assume in either case that the binding between the >> URI and what is identified, is persistent. > > It may be reasonable to say that URN with query identifies something > else than the identified document from the IETF point of view, but I > repeat, extending the scope of existing identifier systems like this > is totally unacceptable and also impractical. Yes, but we're not "extending the scope of existing identifier systems", because these modifiers are not part of those identifiers. We're defining ways of bundling together identifiers and modifiers into a new kind of URI that just happens to begin with a URN. An "extended URN" is closer to being a way of expressing a kind of query than a resource name. You might say "but we don't want to define any modifiers that change the scope of identifiers". I don't think that will fly. There are far more valid and practical reasons that people want to do that, than there are reasons that people need a compact way to express things like "query the resolution service for URN x using parameters a, b, and c". If we build a language that allows people to bundle queries with URNs, it's going to be used for all kinds of different things that we didn't anticipate. If there's one thing that we understand about the Internet, it's that we can't control how people will use the protocols that we create. > URN:ISBN can be used to identify a book, but URN:ISBN extended with > query cannot be used to identify a bibliographic record. Of course it can. And it will. How could we stop it from happening? Keith From nobody Thu Aug 7 22:22:28 2014 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 902B31A02A0 for ; Thu, 7 Aug 2014 22:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.002 X-Spam-Level: X-Spam-Status: No, score=-3.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, 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 tXSWMlUOpVSI for ; Thu, 7 Aug 2014 22:22:22 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F054D1A028A for ; Thu, 7 Aug 2014 22:22:21 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s785MJ18013570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Aug 2014 08:22:20 +0300 Message-ID: <53E45E89.2040005@helsinki.fi> Date: Fri, 08 Aug 2014 08:22:17 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Keith Moore , jehakala@mappi.helsinki.fi References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <53E3296F.1020407@helsinki.fi> <53E390DF.6000305@network-heretics.com> <20140807212546.Horde.P6cY6C6pbAvcvqctbFg4vw9@webmail.helsinki.fi> <53E3D162.7010506@network-heretics.com> In-Reply-To: <53E3D162.7010506@network-heretics.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Ae6vPhZ8WZMgrC83thPN2qDHDQM Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work 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, 08 Aug 2014 05:22:25 -0000 Hi, On 7.8.2014 22:20, Keith Moore wrote: > > I'm not sure if this is what you have in mind or not, but: I really > don't like the idea of trying to distinguish the two kinds of queries > based on reserving certain keywords for resolution service requests. > I think it will be very difficult to define all of the keywords that > will ever be needed, and also difficult to avoid collisions with > keywords used by existing resources. We shall need keywords to define services, and 0-n parameters per service. RFC 2483 contains the initial set of services. 9 keywords are needed to cover them, from s=I2L to s=I2I. Parameters are more tricky; for instance URI to URC may need a lot of them (about 20 to start with) due to profileration of metadata formats. There is also a need to specify a few new services. But all in all, defining the keywords needed for current & currently foreseen services is manageable. The query syntax we've suggested (e.g. ?s=URC&p=MARC21) may already be used somewhere, but certainly not in the URN context. >> >> It has never been an intention to prevent other query usages; all we >> ask is to be able to use query also for service requests. > > I think it's difficult to do the latter, while using query syntax, > without preventing the former. That's why I've been suggesting an > alternate syntax, not using "?", for parameters to be passed to the > resolver. > > Having said that, it occurs to me that we could have the resolution > service tell the client how to process queries. It could say "for > URN urn:foo:bar, parameters a, b, and c apply to the resolution > service, and parameters c, d, and e apply to the resource" (overlap in > the example is intentional). In the absence of such a statement, any > query parameter for that URN would apply to the resource. But that > still makes it difficult to standardize query parameters for > resolution services without introducing the potential for a conflict > with parameters used by existing resources. When resolvers get smarter, we shall need a new service which will enable a client to ask from a resolver which services and service parameters it supports. Then the client would know what kind of resolution service requests can be met by the resolver. It should also be possible to harvest this information from servers into a data store which clients can use. Similar service, called Explain, is included in search protocols Z39.50 and SRU which the library community uses. > > I don't think we can reliably anticipate every resolution parameter > that we're going to need. And I don't think we can use "normal" > vocabulary for resolution parameters without colliding with query > vocabulary already used for some set of resources. This difficulty in anticipating which services and service parameters will be required is the main reason why we need a flexible mechanism for adding them. Revising RFC 2483 each time somebody needs to support e.g. a new metadata format for URI to URC is not viable. > > We could pick some syntax convention for resolution parameters that we > believed was unlikely to conflict with existing query usage by > resources. For example, we could insist that all resolution service > parameters have names beginning with "@". So one could specify > urn:foo:bar?@volume-number=2&@chapter-number=24 or > urn:foo:bar?@request=urc IMO we have already specified a syntax convention which is unlikely enough to conflict with existing usage. And the probability of such collisions in existing URN resolvers is 0. >> >> It may be reasonable to say that URN with query identifies something >> else than the identified document from the IETF point of view, but I >> repeat, extending the scope of existing identifier systems like this >> is totally unacceptable and also impractical. > > Yes, but we're not "extending the scope of existing identifier > systems", because these modifiers are not part of those identifiers. > We're defining ways of bundling together identifiers and modifiers > into a new kind of URI that just happens to begin with a URN. An > "extended URN" is closer to being a way of expressing a kind of query > than a resource name. > > You might say "but we don't want to define any modifiers that change > the scope of identifiers". I don't think that will fly. There are > far more valid and practical reasons that people want to do that, than > there are reasons that people need a compact way to express things > like "query the resolution service for URN x using parameters a, b, > and c". If we build a language that allows people to bundle queries > with URNs, it's going to be used for all kinds of different things > that we didn't anticipate. This is fine with me. What I am saying is that: 1. Many identifier communities have strict rules which specify what can be identified and by whom. 2. These rules apply to the namespace specific strings and only to them. 3. If we say that query and fragment are part of NSS, there is a problem. If they are not part of the NSS - that is, they do not identify anything - fine. And possibly: 4. Some namespaces may want to implement identifier assignment policies which allow the usage of query and / or fragment for identification. If so, they must be encoded so that they are part of the NSS. Alternatively, we may say that using queries and fragments for identification is forbidden in all namespaces, or we may be silent about this. > > If there's one thing that we understand about the Internet, it's that > we can't control how people will use the protocols that we create. > >> URN:ISBN can be used to identify a book, but URN:ISBN extended with >> query cannot be used to identify a bibliographic record. > > Of course it can. And it will. How could we stop it from happening? Based on what I say above, it is fine if people use URN:ISBN:?s=URC to retrieve metadata about a book. There is no need to prevent that. They may also use their own query syntax to retrieve the same metadata. But it is not OK to build a system where these extended URN:ISBNs are used as identifiers for bibliographic records retrieved. Of course, URN like URN:XXX: (in a properly encoded form) would not violate ISBN assignment rules, but I would still not recommend using URNs like this since there is no 1:1 relation between bibliographic records and ISBNs. One reason we have problems understanding each other is that "to identify" means different things not only to us, but also in different URN namespaces. In the ISBN namespace identification is a managed process and according to the well established rules it would be an abomination to give an ISBN + query to bibliographic record. Some other namespaces with more liberal identifier systems might not have problems with such a practice. Juha > > Keith > -- 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 nobody Thu Aug 7 22:57:21 2014 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 EDCCB1A02DD for ; Thu, 7 Aug 2014 22:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 BrUR6XYCra42 for ; Thu, 7 Aug 2014 22:57:17 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68FF1A02DE for ; Thu, 7 Aug 2014 22:57:17 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by gateway1.nyi.internal (Postfix) with ESMTP id A89C12219C for ; Fri, 8 Aug 2014 01:57:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 08 Aug 2014 01:57:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Mz+43bJTRM4EINx4gUTp1c Fbzes=; b=LlQRilGqoP575y1vvJdtzVRPPlnkgwoAN2EX5lylzp9VnbpQFf7pzK 7fl1v3wPhacryIxIHQlvM0mGKL8GZk5rtU6l4cq+Z3QV+WMG/p6lYIRjZJVVAC01 L8UXFi4pjVCqzpsTP/fqtXwFtPwFT0arRRCjt3heCFv393QftxaFs= X-Sasl-enc: KfU5+JOnNc4gMjPAy7j+5tgoCCSN4dixaBx8ZOj+4ya8 1407477430 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id EC079C00003; Fri, 8 Aug 2014 01:57:09 -0400 (EDT) Message-ID: <53E466A0.1010208@network-heretics.com> Date: Fri, 08 Aug 2014 01:56:48 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Juha Hakala , jehakala@mappi.helsinki.fi References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <53E3296F.1020407@helsinki.fi> <53E390DF.6000305@network-heretics.com> <20140807212546.Horde.P6cY6C6pbAvcvqctbFg4vw9@webmail.helsinki.fi> <53E3D162.7010506@network-heretics.com> <53E45E89.2040005@helsinki.fi> In-Reply-To: <53E45E89.2040005@helsinki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/GVaZi_3chOFk5xhRpsCYQggVaZg Cc: urn@ietf.org Subject: [urn] managing the conflict between resolution service queries and resource queries 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, 08 Aug 2014 05:57:20 -0000 On 08/08/2014 01:22 AM, Juha Hakala wrote: > Hi, > > On 7.8.2014 22:20, Keith Moore wrote: > > >> >> I'm not sure if this is what you have in mind or not, but: I really >> don't like the idea of trying to distinguish the two kinds of queries >> based on reserving certain keywords for resolution service requests. >> I think it will be very difficult to define all of the keywords that >> will ever be needed, and also difficult to avoid collisions with >> keywords used by existing resources. > > We shall need keywords to define services, and 0-n parameters per > service. > > RFC 2483 contains the initial set of services. 9 keywords are needed > to cover them, from s=I2L to s=I2I. Parameters are more tricky; for > instance URI to URC may need a lot of them (about 20 to start with) > due to profileration of metadata formats. There is also a need to > specify a few new services. But all in all, defining the keywords > needed for current & currently foreseen services is manageable. RFC 2483 is only an Experimental document, and for good reasons - it's not very well thought out, and it's very incomplete. But if it serves (or has served) as a starting point for experimentation and additional discussion, that's a good thing of course. > > The query syntax we've suggested (e.g. ?s=URC&p=MARC21) may already be > used somewhere, but certainly not in the URN context. It doesn't matter whether it's used in the URN context. We want to be able to use URNs to name network-accessible resources, and there are many, many network-accessible resources for which "s" and "p" are valid query parameter names. >>> >>> It has never been an intention to prevent other query usages; all we >>> ask is to be able to use query also for service requests. >> >> I think it's difficult to do the latter, while using query syntax, >> without preventing the former. That's why I've been suggesting an >> alternate syntax, not using "?", for parameters to be passed to the >> resolver. >> >> Having said that, it occurs to me that we could have the resolution >> service tell the client how to process queries. It could say "for >> URN urn:foo:bar, parameters a, b, and c apply to the resolution >> service, and parameters c, d, and e apply to the resource" (overlap >> in the example is intentional). In the absence of such a statement, >> any query parameter for that URN would apply to the resource. But >> that still makes it difficult to standardize query parameters for >> resolution services without introducing the potential for a conflict >> with parameters used by existing resources. > > When resolvers get smarter, we shall need a new service which will > enable a client to ask from a resolver which services and service > parameters it supports. Then the client would know what kind of > resolution service requests can be met by the resolver. It should also > be possible to harvest this information from servers into a data store > which clients can use. There's no reason that I can see why resolvers can't "get smarter" rather quickly. Certainly it makes more sense for resolvers to "get smarter" than to cripple the ways that URNs can be used. > > Similar service, called Explain, is included in search protocols > Z39.50 and SRU which the library community uses. > > >> >> I don't think we can reliably anticipate every resolution parameter >> that we're going to need. And I don't think we can use "normal" >> vocabulary for resolution parameters without colliding with query >> vocabulary already used for some set of resources. > > This difficulty in anticipating which services and service parameters > will be required is the main reason why we need a flexible mechanism > for adding them. Revising RFC 2483 each time somebody needs to support > e.g. a new metadata format for URI to URC is not viable. The usual solution to such issues is an IANA registry. > >> >> We could pick some syntax convention for resolution parameters that >> we believed was unlikely to conflict with existing query usage by >> resources. For example, we could insist that all resolution service >> parameters have names beginning with "@". So one could specify >> urn:foo:bar?@volume-number=2&@chapter-number=24 or >> urn:foo:bar?@request=urc > > IMO we have already specified a syntax convention which is unlikely > enough to conflict with existing usage. And the probability of such > collisions in existing URN resolvers is 0. Strongly disagree that the RFC 2483 convention is unlikely to conflict with existing usage. Collisions within existing URN resolvers is not the issue; the issue is conflicting with the ability to use URNs to name network-accessible resources that accept queries. > > >>> >>> It may be reasonable to say that URN with query identifies something >>> else than the identified document from the IETF point of view, but I >>> repeat, extending the scope of existing identifier systems like this >>> is totally unacceptable and also impractical. >> >> Yes, but we're not "extending the scope of existing identifier >> systems", because these modifiers are not part of those >> identifiers. We're defining ways of bundling together identifiers >> and modifiers into a new kind of URI that just happens to begin with >> a URN. An "extended URN" is closer to being a way of expressing a >> kind of query than a resource name. >> >> You might say "but we don't want to define any modifiers that change >> the scope of identifiers". I don't think that will fly. There are >> far more valid and practical reasons that people want to do that, >> than there are reasons that people need a compact way to express >> things like "query the resolution service for URN x using parameters >> a, b, and c". If we build a language that allows people to bundle >> queries with URNs, it's going to be used for all kinds of different >> things that we didn't anticipate. > > This is fine with me. What I am saying is that: > > 1. Many identifier communities have strict rules which specify what > can be identified and by whom. > 2. These rules apply to the namespace specific strings and only to them. > 3. If we say that query and fragment are part of NSS, there is a > problem. If they are not part of the NSS - that is, they do not > identify anything - fine. Yes, I think that's where we have to draw the line. Modifiers (I don't think query and fragment are sufficient) are not part of the NSS. > > And possibly: > > 4. Some namespaces may want to implement identifier assignment > policies which allow the usage of query and / or fragment for > identification. If so, they must be encoded so that they are part of > the NSS. Alternatively, we may say that using queries and fragments > for identification is forbidden in all namespaces, or we may be silent > about this. I don't think encoding them in the NSS is a good idea; I think it will not work well in practice because there are too many situations where ordinary users will want to restrict the scope of a reference that includes a URN, and those ordinary users will want to construct the extended URNs that do that. Furthermore I don't think that whether particular modifiers apply to a URN should be an attribute of the namespace, but rather, an attribute of the resource. Or more precisely: the namespace can set a policy if it likes, but clients shouldn't assume that such characteristics are namespace-specific; they should consult the resolution service to learn which modifiers are applicable for that particular URN. If the resolution service for a particular namespace always returns the same answers to such queries for all URNs coined from that namespace, that's fine. > > >> >> If there's one thing that we understand about the Internet, it's that >> we can't control how people will use the protocols that we create. >> >>> URN:ISBN can be used to identify a book, but URN:ISBN extended with >>> query cannot be used to identify a bibliographic record. >> >> Of course it can. And it will. How could we stop it from happening? > > Based on what I say above, it is fine if people use > URN:ISBN:?s=URC to retrieve metadata about a book. There is no > need to prevent that. They may also use their own query syntax to > retrieve the same metadata. > > But it is not OK to build a system where these extended URN:ISBNs are > used as identifiers for bibliographic records retrieved. But people will do exactly that, no matter what we say, and they'll want to treat those extended URNs as identifiers. Saying "you can construct these things but don't treat them as identifiers" is too much subtlety to expect users to understand. (the same is likely to be true for any combination of URN + modifier, no matter what kind of modifier) > > Of course, URN like URN:XXX: (in a properly encoded form) > would not violate ISBN assignment rules, but I would still not > recommend using URNs like this since there is no 1:1 relation between > bibliographic records and ISBNs. I agree that this is not a good idea. > > One reason we have problems understanding each other is that "to > identify" means different things not only to us, but also in different > URN namespaces. In the ISBN namespace identification is a managed > process and according to the well established rules it would be an > abomination to give an ISBN + query to bibliographic record. Some > other namespaces with more liberal identifier systems might not have > problems with such a practice. Yes it's tricky, for this reason, and for many other reasons. But in defining URN standards we need to do so in a way that's independent of particular namespace characteristics. It's a balancing act - to try to respect and accommodate the needs of various namespaces on one hand, without impairing URN utility for other less restrictive namespaces or making client implementations too complex on the other hand. Keith From nobody Fri Aug 8 15:11:29 2014 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 229441A014C for ; Fri, 8 Aug 2014 15:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 HcV7O_Pcnjqc for ; Fri, 8 Aug 2014 15:11:24 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8361A00FC for ; Fri, 8 Aug 2014 15:11:23 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta13.westchester.pa.mail.comcast.net with comcast id cN7e1o0031HzFnQ5DNBPZj; Fri, 08 Aug 2014 22:11:23 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta14.westchester.pa.mail.comcast.net with comcast id cNBP1o00E1KKtkw3aNBPZa; Fri, 08 Aug 2014 22:11:23 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s78MBLok019384; Fri, 8 Aug 2014 18:11:21 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s78MBLvf019383; Fri, 8 Aug 2014 18:11:21 -0400 Date: Fri, 8 Aug 2014 18:11:21 -0400 Message-Id: <201408082211.s78MBLvf019383@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org In-reply-to: <20140807203435.Horde.pJHMTpPulJNNuDdE93z5qQ6@webmail.helsinki.fi> (jehakala@mappi.helsinki.fi) References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <201408062053.s76KrYFJ011175@hobgoblin.ariadne.com> <53E316FC.4090903@helsinki.fi> <201408071528.s77FSabS002041@hobgoblin.ariadne.com> <20140807203435.Horde.pJHMTpPulJNNuDdE93z5qQ6@webmail.helsinki.fi> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407535883; bh=2ZhsE68BfGyrZAz5u219hlj/WZEOCwHSaPer/2RbtfE=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=okMgeYoDkoIXKX4r4UcoIC+Ro2zLpJwY6RPz1w/Z6xpcfrT9t2pnJmmR0Bbns9Rcd wwE/ACTNNzJhBuOrOc3aVnNNlMjypbA7h/ZJaVEflVssHJCasiWdIOE6Qnv6ZsLJwp oOq4rm0ygYn4go6dbfky8id2CCW1mwy2r3V0k/iEY/A0fDvfDdieirko/TvpqQOwBA 8KXWPNJnzljP2goUNrzlWoBPAFQBWB1IGITbfTk1izngoSqFCv6lQRX4HFlofEHxJn 8uRmu9TPgIw1Y2rDc2MzUqek6YL/8HJ+pXnqHYFYhqcoCYNUzRqjhn0/Vs/hyFK9P2 RlLktu0Xe5u7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/mdhG4pKVtG9kk061AXUCQL2aYwo Subject: Re: [urn] Rules for identifier systems 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, 08 Aug 2014 22:11:29 -0000 [For some reason, the messages with the subject "Rules for identifier systems" have been coming to me directly, but not via the URN mailing list, despite being CC'ed to the mailing list. I'm sending this to the mailing list only, on the assumption that this problem will not recur.] > From: jehakala@mappi.helsinki.fi > [...] But the URN system must accommodate even those traditional > identifiers which are strictly managed. Allowing substantial changes > in existing practices would be regarded as extremely disruptive by the > communities affected. [...] If I may complain a moment: You've said things like this several times in the past. And what you say makes sense. The problem is that it is not "actionable", because there is no way for anyone in the working group (except possibly yourself) to determine what would require a "substantial change in existing practices". What we need (from your or somebody) is a clear statement: "If the URN syntax and semantics follows rules X, Y, and Z, then we can are assured that it will not interfere with the existing practices of *any* of the identifier systems which are to be embedded as URN namespaces." Now currently, it seems to me that there are two requirements that have to be observed: 1) An identifier consists of a sequence of characters, the syntax of which is defined by the identifier system (not the URN syntax). Therefore, there must be a way of encoding an *arbitrary* character string as the namespace-specific string of a URN. Conversely, looking at a URN, there must be an algorithmic way of extracting its namespace-specific string as a sequence of (unencoded) characters, so that that string can be considered as an identifier within the identifier system. (It would be convenient if the extraction algorithm is namespace-independent, but it appears to me that is not strictly necessary.) (Note that since we are revising the RFC, exactly what part of a URN is the "namespace-specific string" can be redefined if we want to.) 2) If we devise mechanisms to (a) designate parts of the identified resource, (b) provide instructions as to which resolver to use or in what manner, or (c) to specify information that is "related" to the identified resource, and ---> if this mechanism involves modifying the URN to produce a "decorated URN" character string (and that has not at this point been agreed upon) <--- , then it must be possible to algorithmicly remove the "decoration" to produce the "base URN", and the "decoration" must not be considered part of the namespace-specific string (that is, the "identifier" proper). That is, "decorating" a URN will fundamentally change its identifier part. (Whether we consider "decorated URNs" to be "URNs" in the strict sense of the word is a matter of terminology to be settled later in whatever way makes discussion most convenient.) At this point, I think that those two requirements will satisfy all the needs that you've articulated (and that I have understood). Dale From nobody Tue Aug 12 03:25:54 2014 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 D2EAF1A0838 for ; Tue, 12 Aug 2014 03:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 KJ9jjVGXAdzD for ; Tue, 12 Aug 2014 03:25:51 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3651A03A9 for ; Tue, 12 Aug 2014 03:25:50 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway1.nyi.internal (Postfix) with ESMTP id E05C323A3A for ; Tue, 12 Aug 2014 06:25:47 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 12 Aug 2014 06:25:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=EOmZ2dIFRv0nOWPhN37k8+ GK6pQ=; b=TkIGRmoFR5sC4IKB9xyyeJ+c2RCvKc36gzCdDx5cqfcIQlTXpoQcFJ gJrghHvtWYrIkeWq99lfNgZsPLZ0COx9Sy3pmDzJ9sdUXC7oDsX+QNClfOHykW+V lDvj2OPYeh9u02HmRkiCTryUVq+BYXItLR3HRyd/BpI0fqrALaWsE= X-Sasl-enc: gPr69AKcLtBBRfwL9xLei4MQCZ98sqi30PisNSd/EFfI 1407839146 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id ABF75680209; Tue, 12 Aug 2014 06:25:45 -0400 (EDT) Message-ID: <53E9EBA3.8080308@network-heretics.com> Date: Tue, 12 Aug 2014 06:25:39 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Dale R. Worley" , urn@ietf.org References: <201408051803.s75I3IM2007097@hobgoblin.ariadne.com> <53E1E107.1080302@helsinki.fi> <53E2630B.6000002@network-heretics.com> <201408062053.s76KrYFJ011175@hobgoblin.ariadne.com> <53E316FC.4090903@helsinki.fi> <201408071528.s77FSabS002041@hobgoblin.ariadne.com> <20140807203435.Horde.pJHMTpPulJNNuDdE93z5qQ6@webmail.helsinki.fi> <201408082211.s78MBLvf019383@hobgoblin.ariadne.com> In-Reply-To: <201408082211.s78MBLvf019383@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/X6gttLoFRKM69ifupWRadutYL3k Subject: Re: [urn] Rules for identifier systems 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: Tue, 12 Aug 2014 10:25:53 -0000 On 08/08/2014 06:11 PM, Dale R. Worley wrote: > (Note that since we are revising the RFC, exactly what part of a URN > is the "namespace-specific string" can be redefined if we want to.) Provided, of course, that we don't change the meaning of existing URNs that conform to RFC 2141 syntax. (Actually, I can't imagine that we would redefine namespace-specific-string, even if we were to allow "decorations" to follow it.) Keith From nobody Fri Aug 15 14:22:52 2014 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 47C331A069F for ; Fri, 15 Aug 2014 14:22:50 -0700 (PDT) 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 W2IZxzL8qvdV for ; Fri, 15 Aug 2014 14:22:48 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65021A065F for ; Fri, 15 Aug 2014 14:22:48 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so4114930pab.34 for ; Fri, 15 Aug 2014 14:22:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Pg6o59cqmFK2FUaZvb4kxD8cdnotfhuRoD9BGBXyuA8=; b=Ejgt6pKqRhCgUqr/2RxfXsiCw/ccj9BJigHZ1nfSLfvUCKp+LABuqh5kILbPJJlyRI dDTVZLXaFo8ew/PK9iEFP2qZ2Y7LDsbWHnvvyJZxTnTDKQSHhSyCJu+IKXBEHhtbGvQP yEE8xB3w1u11dqMsb9G5VAh5YoD5lP6zSW4bvh0EdUodfSSkid3C4g38xnyTsMVnaPqs KQ3pqtXZvDn+K8geILODbcpLifwp2E6eFeNDBR/SJizXWRCMBkd6Je6r/JVZwbCsuPNV ptI8Nni9fGivwUd2ewbAlDw0cARSrAecaS7hfnUb0MICBUzkpdAtspfGYC0EWFyOxK8i mJxg== X-Gm-Message-State: ALoCoQmehp1gJMtMHIaoEGJ1jXLAFR978AJdVdujMlc8k9yfwGE6rtatSfKyauEZVc8Xa+suVTxg MIME-Version: 1.0 X-Received: by 10.70.48.70 with SMTP id j6mr21759354pdn.82.1408137768178; Fri, 15 Aug 2014 14:22:48 -0700 (PDT) Received: by 10.66.27.5 with HTTP; Fri, 15 Aug 2014 14:22:48 -0700 (PDT) X-Originating-IP: [2001:500:4:15:90e4:6918:f1ad:ed7c] Date: Fri, 15 Aug 2014 17:22:48 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/qCsIopMQjx1A06cDA9Laq7nVQHo Subject: [urn] Minutes from IETF 90 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, 15 Aug 2014 21:22:50 -0000 The minutes from our session at IETF 90 are posted. Many thanks to our minute taker, Dorothy Stanley. http://www.ietf.org/proceedings/90/minutes/minutes-90-urnbis If you desire any modifications or have any corrections to the minutes, please let me know. -andy, co-chair From nobody Mon Aug 25 13:37:46 2014 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 E3C2C1A0340; Mon, 25 Aug 2014 13:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3qi0dc6kdn7z; Mon, 25 Aug 2014 13:37:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B99841A0323; Mon, 25 Aug 2014 13:37:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825203743.1062.92769.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 13:37:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/M4_5NE5DanCsPFzgBpMPCx0Mu5c Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-ns-reg-transition-03.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 20:37:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Uniform Resource Name (URN) Namespace Registration Transition Authors : John C Klensin Juha Hakala Filename : draft-ietf-urnbis-ns-reg-transition-03.txt Pages : 7 Date : 2014-08-25 Abstract: The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed in [[RFC 3406bis]]. That document adopts a different model. This document specifies IANA instructions to adapt selected existing registrations to the new model. It also obsoletes some previous RFCs to eliminate any ambiguity about the status of new templates and updated registrations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-ns-reg-transition-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-ns-reg-transition-03 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 nobody Mon Aug 25 17:08:13 2014 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 453F41A04BA for ; Mon, 25 Aug 2014 17:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.568 X-Spam-Level: X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 8q5gp7EPWj2F for ; Mon, 25 Aug 2014 17:08:07 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F230F1A047B for ; Mon, 25 Aug 2014 17:08:06 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XM4Iv-000Ijn-AL; Mon, 25 Aug 2014 20:08:05 -0400 Date: Mon, 25 Aug 2014 20:08:00 -0400 From: John C Klensin To: urn@ietf.org, Andrew Newton Message-ID: 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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/eZ9qTJt1gzkavCrMIjoLmiutxuE Subject: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris) 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: Tue, 26 Aug 2014 00:08:09 -0000 Hi. I've posted the replacement for draft-ietf-urnbis-urns-are-not-uris-01 as draft-ietf-urnbis-semantics-clarif-00. It is now awaiting Andy's approval which I thought was given shortly after Toronto. Some of you know that my intention was to immediately follow it with a trimmed-down -01 because -00 contains a lot of material we probably won't want long-term. As a preview, exclusive of references (some of them cited from the appendices) and appendices, -00 is only 8 pages long; with them, twice that. I've deferred trying to get -01 out both because -00 took much longer than expected and because I continued to review both the post-Toronto mailing list comments and a number of private communications and concluded that the current draft may not be stable enough to start pulling text out of. I'd also like to have a better idea of what Peter expected to do with 2141bis (or what the WG wants him to do). I'm aware that some text is redundant, especially the repeated comments about zero effect on generic URI parsing systems. That is partially intentional (to be sure those statements didn't get lost when we start removing sections) and partially just temporarily running out of energy. Note too that this draft contains, in Section 6, my cut at the list Andy requested of alternatives with which the WG will need to deal. In the spirit of the discussions in Toronto, this document is intended more as the basis for focusing discussions than as a final piece to be published. To paraphrase what Andy said there, we need to make decisions about what we want to do and only then figure out how much of this, if any, is worth having in an officially-permanent document. While some of the discussion in this -00 draft gets fairly far into "how to do this", I personally concur with something Andy, Henry, and several others have said in different ways: in the short run, we are much more likely to end up with the results we want if we can talk about functionality and not where to put it or what syntax to use. While the I-D uses "query" and "fragment" terminology, it may even be useful to thinks of parts of the URI syntax as "path-stuff", "?-stuff", and "#-stuff", remembering that the connotations of words like "query" and "fragment" are themselves semantics. I expect that we will return to URI terminology before the version of 2141bis that reflects these issues is posted but, for thinking right now it again may be useful to break loose from historical concepts. Some of the above has almost certainly influenced what I've written and how I've written it. That doesn't mean the text is right, but I hope we can be clear about what we are talking about before we get into trouble. Happy reading, john From nobody Mon Aug 25 17:17:35 2014 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 9D6D31A04F1; Mon, 25 Aug 2014 17:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 tBg63QwGIPSu; Mon, 25 Aug 2014 17:17:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD4C1A04DC; Mon, 25 Aug 2014 17:17:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140826001727.20837.82843.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 17:17:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/kxQLfxUudexet4BsXJ6rtfWSNnw Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 00:17:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : URN Semantics Clarification Author : John C Klensin Filename : draft-ietf-urnbis-semantics-clarif-00.txt Pages : 18 Date : 2014-08-25 Abstract: Experience has shown that identifiers associated with persistent names have properties and requirements that may be somewhat different from identifiers associated with the locations of objects. This is especially true when such names are expected to be stable for a very long time or when they identify large and complex entities. In order to allow Uniform Resource Names (URNs) to evolve to meet the needs of the Library, Museum, Publisher, and Informational Sciences communities and other users, this specification separates URNs from the semantic constraints that many people believe are part of the specification for Uniform Resource Identifiers (URIs) specified in RFC 3986, updating that document accordingly. The syntax of URNs is still constrained to that of RFC 3986, so generic URI parsers are unaffected by this change. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-00 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 nobody Mon Aug 25 17:22:44 2014 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 33A9C1A04E9 for ; Mon, 25 Aug 2014 17:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 0BU0PH6tdyQJ for ; Mon, 25 Aug 2014 17:22:41 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64721A04C5 for ; Mon, 25 Aug 2014 17:22:40 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XM4Wy-000IlA-WC; Mon, 25 Aug 2014 20:22:37 -0400 Date: Mon, 25 Aug 2014 20:22:31 -0400 From: John C Klensin To: Andrew Newton , Peter Saint-Andre Message-ID: 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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1K34zQ4wxrrxuc8N2fsrivHd2G4 Cc: urn@ietf.org Subject: [urn] URNbis document status 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: Tue, 26 Aug 2014 00:22:42 -0000 Hi. This is mostly to Andy and Peter, but the WG should be aware that it has been sent. >From the tracker and some additional information, we now have, in no particular order: (1) draft-ietf-urnbis-semantics-clarif-00, described in a note I just sent: Awaiting posting approval from Andy. That approval should also tell the Secretariat to make it as replacing draft-ietf-urnbis-urns-are-not-uris (and the latter as being replaced). (2) draft-ietf-urnbis-ns-reg-transition-03: Just posted with fairly minor changes. While those changes are, I hope, improvements, the main reason from posting -03 was to prevent the draft from expiring this week. Once we reach consensus on it (assuming we eventually do), it should be identified as having superceded draft-ietf-urnbis-rfc3044bis-issn-urn and draft-ietf-urnbis-rfc3187bis-isbn-urn). (3) Definitions and syntax - 2141bis (draft-ietf-urnbis-rfc2141bis-urn-07): Expired (4) Namespace definition mechanisms - 3406bis (draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09): Expired. (5) NBNs (draft-ietf-urnbis-rfc3188bis-nbn-urn-04): Expired spring of 2013 (we all know why, but shouldn't lose track of this as a work item). The last three are charter-identified documents, the other two are mostly just procedural. I hope we can see active versions of at least (3) and (4) Real Soon Now, if only because it is a little hard to work this way. best, john From nobody Mon Aug 25 18:53:16 2014 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 CBDC91A063C for ; Mon, 25 Aug 2014 18:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 DAy0_P4rkLRx for ; Mon, 25 Aug 2014 18:53:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C8E191A03E2 for ; Mon, 25 Aug 2014 18:53:13 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8258B40FA4; Mon, 25 Aug 2014 19:53:43 -0600 (MDT) Message-ID: <53FBE88B.60004@stpeter.im> Date: Mon, 25 Aug 2014 19:53:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , Andrew Newton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/CB8XtVJZz5SiHM0Z_rZcOIzHwKU Cc: urn@ietf.org Subject: Re: [urn] URNbis document status 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: Tue, 26 Aug 2014 01:53:14 -0000 On 8/25/14, 6:22 PM, John C Klensin wrote: > Hi. > > This is mostly to Andy and Peter, but the WG should be aware > that it has been sent. > >>From the tracker and some additional information, we now have, > in no particular order: > > (1) draft-ietf-urnbis-semantics-clarif-00, described in a note I > just sent: > Awaiting posting approval from Andy. That approval > should also tell the Secretariat to make it as replacing > draft-ietf-urnbis-urns-are-not-uris (and the latter as > being replaced). > > (2) draft-ietf-urnbis-ns-reg-transition-03: > Just posted with fairly minor changes. While those > changes are, I hope, improvements, the main reason from > posting -03 was to prevent the draft from expiring this > week. Once we reach consensus on it (assuming we > eventually do), it should be identified as having > superceded draft-ietf-urnbis-rfc3044bis-issn-urn and > draft-ietf-urnbis-rfc3187bis-isbn-urn). > > (3) Definitions and syntax - 2141bis > (draft-ietf-urnbis-rfc2141bis-urn-07): > Expired > > (4) Namespace definition mechanisms - 3406bis > (draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09): > Expired. > > (5) NBNs (draft-ietf-urnbis-rfc3188bis-nbn-urn-04): > Expired spring of 2013 (we all know why, but shouldn't > lose track of this as a work item). > > The last three are charter-identified documents, the other two > are mostly just procedural. I hope we can see active versions > of at least (3) and (4) Real Soon Now, if only because it is a > little hard to work this way. Agreed. Unfortunately since a job change in January my time for IETF work has been quite limited, and I have ~15 I-Ds to finish up. My first priority consists of the various PRECIS WG items, which I'll be working on this week. I will set aside some time next week for URNBIS WG items. My apologies for any delays I have caused. Peter From nobody Mon Aug 25 19:55:49 2014 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 92CF91A06A9 for ; Mon, 25 Aug 2014 19:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 5V81oZB-EB51 for ; Mon, 25 Aug 2014 19:55:45 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1531A06A7 for ; Mon, 25 Aug 2014 19:55:43 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XM6v4-000J1X-J4; Mon, 25 Aug 2014 22:55:38 -0400 Date: Mon, 25 Aug 2014 22:55:33 -0400 From: John C Klensin To: Peter Saint-Andre , Andrew Newton Message-ID: <5E0648290D4FD3235F76F2C9@JcK-HP8200.jck.com> In-Reply-To: <53FBE88B.60004@stpeter.im> References: <53FBE88B.60004@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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bAnCLMDePgRWLAqa0Zv78iE4q6Y Cc: urn@ietf.org Subject: Re: [urn] URNbis document status 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: Tue, 26 Aug 2014 02:55:46 -0000 (off list although I'm happy to repeat this on if you or Andy think it would be of any help) --On Monday, August 25, 2014 19:53 -0600 Peter Saint-Andre wrote: > Unfortunately since a job change in January my time for IETF > work has been quite limited, and I have ~15 I-Ds to finish up. > My first priority consists of the various PRECIS WG items, > which I'll be working on this week. I will set aside some time > next week for URNBIS WG items. Great. > My apologies for any delays I have caused. Until I got the "semantics" piece out, you weren't causing any delays - I was. Andy should be able to keep people busy for a while debating whether my list of issues is the right one and, if so, what the responses should be. I think you are going to need some of the bits from this draft and/or the prior "URNs are not..." one. If so, holler and I'd send the XML along. Also, if I can help in any way, please let me know -- I have very little time either but am _really_ anxious to get URNs done and off my plate. best, john From nobody Mon Aug 25 20:01:54 2014 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 85E181A06B3 for ; Mon, 25 Aug 2014 20:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 eOiIVrCbzBSY for ; Mon, 25 Aug 2014 20:01:47 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6B21A06B0 for ; Mon, 25 Aug 2014 20:01:47 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XM70z-000J2F-Fb; Mon, 25 Aug 2014 23:01:45 -0400 Date: Mon, 25 Aug 2014 23:01:40 -0400 From: John C Klensin To: Peter Saint-Andre , Andrew Newton Message-ID: <557282EA8AF72184E04B481D@JcK-HP8200.jck.com> In-Reply-To: <5E0648290D4FD3235F76F2C9@JcK-HP8200.jck.com> References: <53FBE88B.60004@stpeter.im> <5E0648290D4FD3235F76F2C9@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/e1_zfYO2-7f4QX4JdSDWQuEGkIk Cc: urn@ietf.org Subject: Re: [urn] URNbis document status 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: Tue, 26 Aug 2014 03:01:52 -0000 On list after all. Fat fingers. Sorry. --On Monday, August 25, 2014 22:55 -0400 John C Klensin wrote: > (off list although I'm happy to repeat this on if you or Andy > think it would be of any help) > > --On Monday, August 25, 2014 19:53 -0600 Peter Saint-Andre > wrote: > >> Unfortunately since a job change in January my time for IETF >> work has been quite limited, and I have ~15 I-Ds to finish up. >> My first priority consists of the various PRECIS WG items, >> which I'll be working on this week. I will set aside some time >> next week for URNBIS WG items. > > Great. > >> My apologies for any delays I have caused. > > Until I got the "semantics" piece out, you weren't causing any > delays - I was. Andy should be able to keep people busy for a > while debating whether my list of issues is the right one and, > if so, what the responses should be. > > I think you are going to need some of the bits from this draft > and/or the prior "URNs are not..." one. If so, holler and I'd > send the XML along. Also, if I can help in any way, please let > me know -- I have very little time either but am _really_ > anxious to get URNs done and off my plate. > > best, > john > > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn