From nobody Mon Aug 10 17:08:12 2015 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 7D89B1A1F04; Mon, 10 Aug 2015 17:08:10 -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 20sEgIFxiDsS; Mon, 10 Aug 2015 17:08:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDE41A1EE8; Mon, 10 Aug 2015 17:08:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150811000809.8360.21435.idtracker@ietfa.amsl.com> Date: Mon, 10 Aug 2015 17:08:09 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-ns-reg-transition-05.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, 11 Aug 2015 00:08:10 -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-05.txt Pages : 8 Date : 2015-08-10 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 2141bis]]. 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: https://tools.ietf.org/html/draft-ietf-urnbis-ns-reg-transition-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-ns-reg-transition-05 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 10 17:08:29 2015 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 E87D71A1EF9; Mon, 10 Aug 2015 17:08:25 -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 sL2bLsGOZmLK; Mon, 10 Aug 2015 17:08:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 350161A6EE2; Mon, 10 Aug 2015 17:08:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150811000822.11796.85934.idtracker@ietfa.amsl.com> Date: Mon, 10 Aug 2015 17:08:22 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-02.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, 11 Aug 2015 00:08:26 -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-02.txt Pages : 11 Date : 2015-08-10 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 Information Science 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) 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: https://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-semantics-clarif-02 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 10 18:25:04 2015 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 5FCD01A884D for ; Mon, 10 Aug 2015 18:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 SCTE9C2FOmgf for ; Mon, 10 Aug 2015 18:25:02 -0700 (PDT) Received: from bsa2.jck.com (ns.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 0FBB81A884B for ; Mon, 10 Aug 2015 18:25:02 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZOyJI-0008Bz-Fu for urn@ietf.org; Mon, 10 Aug 2015 21:25:00 -0400 Date: Mon, 10 Aug 2015 21:24:55 -0400 From: John C Klensin To: urn@ietf.org Message-ID: In-Reply-To: <20150811000822.11796.85934.idtracker@ietfa.amsl.com> References: <20150811000822.11796.85934.idtracker@ietfa.amsl.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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] New versions of semantics-clarif and transition drafts 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, 11 Aug 2015 01:25:03 -0000 Hi. These two new versions really aren't (new, that is). IETF Internet Drafts automatically expire six months after posting, these were about to expire, so, after a quick consultation with the co-chairs, I issued new versions to keep the drafts active. Other than the version numbers, dates, and updating a few references and the change logs, there are no changes at all from the prior versions. 2141bis remains the critical path and I hope people will concentrate on it rather than letting these administratively-necessary updates distract them. john From nobody Thu Aug 13 19:52:13 2015 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 194151B3C2B for ; Thu, 13 Aug 2015 19:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 p0iAmBRZxWRI for ; Thu, 13 Aug 2015 19:52:10 -0700 (PDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735431B3C29 for ; Thu, 13 Aug 2015 19:52:10 -0700 (PDT) Received: by iodt126 with SMTP id t126so72466060iod.2 for ; Thu, 13 Aug 2015 19:52:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=H3d218NcSghDw1bnTY4oyPjUORpyD+Q0qQ/CxgtNlGE=; b=le8XGbcbvFMvRtLg7AvH/krL/zHzDA3+dKGrXTLwvK3PyeCyXufeBzdVB79hrrKPJ+ 6VCT6zYG1PFmcx+vocmmOR5gFC1H2cHgnHPVOmOyU+GErQjCcv4RULLFq22+KpD27sWx 6ubkc42ERkKk/Fp1boXl09Vgzj4mh3aJDK4cnoExhNc8Jc3LIhu9/NE/4tufOwEaPND5 gUDAFagtgIKEsJesa4vThP9IxsDl3YqRdM1xFVHfw17PI//vOCs3UaDevFTMmeVuWd8n Tez75/56I23UTwVifjiCQbXN0SwLfXEWm4lrM3tsjct6IdxvgXbTsPdXJoWmeeWI3dq9 HBAg== X-Gm-Message-State: ALoCoQn6k8yueHHo7suB5XJTBfVUQf5/Ic3cXlLW3HvFN3g9WAD4O6Wkr+Mt3tRzoAeXxA6hyetm X-Received: by 10.107.34.147 with SMTP id i141mr39416285ioi.59.1439520729806; Thu, 13 Aug 2015 19:52:09 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id e33sm3190554ioi.12.2015.08.13.19.52.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Aug 2015 19:52:08 -0700 (PDT) To: Keith Moore , urn@ietf.org References: <559463C3.3030905@network-heretics.com> <4732B81F609179B87526E501@JcK-HP5.jck.com> <55B71ABF.7090508@network-heretics.com> From: Peter Saint-Andre - &yet Message-ID: <55CD57D6.2010603@andyet.net> Date: Thu, 13 Aug 2015 20:52:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B71ABF.7090508@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] encoding, component order, and related issues 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, 14 Aug 2015 02:52:12 -0000 My apologies for the delayed replies to list discussion on version -12. I shall endeavor to catch up. For now just one comment, focusing on component order... On 7/28/15 12:01 AM, Keith Moore wrote: > Since I believe that protocol designs and system should try to avoid > obscure edge cases, I would prefer that the syntax permit a direct > copying of URN q-component to URL query (and vice versa if this is ever > applicable). All other things being equal, I think that is a laudable goal. > And that's why I was looking for ways to change the ABNF > to permit this, including changing the order of q- and r-components. I > think that will produce fewer implementation bugs, less obscure and odd > behavior, and less user frustration. More laudable goals. > But I also realize that this is at least the third time I've tried to > fix this, and that the glitches that this causes will probably be > infrequent. I also strongly suspect that this will come up again in > IETF-wide Last Call because I expect the web types will want to go over > this with a fine-toothed comb. So while I still don't understand why > you so strongly insist that r-component has to follow q-component, My sense is that John feels this was a closed issue and that the WG had reached agreement on q-then-r, so why revisit it? For myself, I don't have strong feelings about q-then-r vs. r-then-q. I find mostly compelling your argument in favor of r-then-q in appealing to the ability to copy from URN to URL without translation (since translation inevitably introduces the possibility of getting it wrong). And as far as I can see right now there is no particularly strong reason to prefer q-then-r with regard to ease of implementation, improved security, minimizing user confusion, etc. So I am open to changing the order if that's the direction the WG prefers. > I > feel like other issues are more substantive and I've done due diligence > trying to point it out. So maybe the thing to do is see if it gets > raised again in IETF-wide Last Call, where I expect the whole > interaction between URN components and URL components will get a lot of > attention. I think it would be good to minimize attention in IETF Last Call by addressing issues sooner rather than later. :-) Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Aug 13 21:47:03 2015 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 E56D41AC3AE for ; Thu, 13 Aug 2015 21:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 RlWdW4jg1TXZ for ; Thu, 13 Aug 2015 21:47:00 -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 5FA2D1AC3A2 for ; Thu, 13 Aug 2015 21:47:00 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZQ6tL-0005JY-Hb; Fri, 14 Aug 2015 00:46:55 -0400 Date: Fri, 14 Aug 2015 00:46:50 -0400 From: John C Klensin To: Peter Saint-Andre - &yet , Keith Moore , urn@ietf.org Message-ID: <0A78DE19CA88E036C0B22104@JcK-HP8200.jck.com> In-Reply-To: <55CD57D6.2010603@andyet.net> References: <559463C3.3030905@network-heretics.com> <4732B81F609179B87526E501@JcK-HP5.jck.com> <55B71ABF.7090508@network-heretics.com> <55CD57D6.2010603@andyet.net> 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.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] encoding, component order, and related issues 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, 14 Aug 2015 04:47:02 -0000 --On Thursday, August 13, 2015 20:52 -0600 Peter Saint-Andre - &yet wrote: >> But I also realize that this is at least the third time I've >> tried to fix this, and that the glitches that this causes >> will probably be infrequent. I also strongly suspect that >> this will come up again in IETF-wide Last Call because I >> expect the web types will want to go over this with a >> fine-toothed comb. So while I still don't understand why >> you so strongly insist that r-component has to follow >> q-component, > > My sense is that John feels this was a closed issue and that > the WG had reached agreement on q-then-r, so why revisit it? Yes. I'm happy to reconstruct and explain again the reasons for preferring q-then-r, including why I think the "copying" argument is mostly bogus in practice, but I'm disinclined to spend everyone's time doing so unless either the co-chairs say "actually there was no conclusion earlier" or someone other than Keith feels strongly about the other order and says so. john From nobody Fri Aug 14 17:23:51 2015 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 A26C51AD05D for ; Fri, 14 Aug 2015 17:23: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 ci6KLjY3YeLE for ; Fri, 14 Aug 2015 17:23:48 -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 5B9B71ACEF6 for ; Fri, 14 Aug 2015 17:23:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BDBB2231B9 for ; Fri, 14 Aug 2015 20:23:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 14 Aug 2015 20:23:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=0RHWrSXZXkiT7ml Ecors9A2ScVE=; b=Siv4+ckHaGdg9YukoDZAO2y3I2ZTS1IQtjAGAQKIYCb67jI YcqEhZH67p1Gi/OawwBhwKj71zQY0ez7MiCORcVCsTf1FzC7ez7GpXmxgBkPaUOx NPb99Hr/LgHbkihkd1bUGRmIC9rsRfQbqSKQN8hkm0Rr1QwN4lBzsxwuY8Co= X-Sasl-enc: mc+Zl+6Asxog46X2/2TmbFybpMr+ny3dg/webh9wW5uW 1439598226 Received: from [21.162.128.84] (unknown [66.87.128.84]) by mail.messagingengine.com (Postfix) with ESMTPA id 15F3BC0001D; Fri, 14 Aug 2015 20:23:46 -0400 (EDT) References: <559463C3.3030905@network-heretics.com> <4732B81F609179B87526E501@JcK-HP5.jck.com> <55B71ABF.7090508@network-heretics.com> <55CD57D6.2010603@andyet.net> <0A78DE19CA88E036C0B22104@JcK-HP8200.jck.com> In-Reply-To: <0A78DE19CA88E036C0B22104@JcK-HP8200.jck.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (12F70) From: Keith Moore Date: Fri, 14 Aug 2015 20:23:44 -0400 To: John C Klensin Archived-At: Cc: "urn@ietf.org" , Peter Saint-Andre - &yet Subject: Re: [urn] encoding, component order, and related issues 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: Sat, 15 Aug 2015 00:23:49 -0000 I never was convinced of a consensus on this issue (though it's hard to tell= when there are so few active participants and people sometimes take a long t= ime to reply). But I'm also no longer convinced that this is a huge problem= . Sent from my iPhone > On Aug 14, 2015, at 12:46 AM, John C Klensin wrote: >=20 >=20 >=20 > --On Thursday, August 13, 2015 20:52 -0600 Peter Saint-Andre - > &yet wrote: >=20 >>> But I also realize that this is at least the third time I've >>> tried to fix this, and that the glitches that this causes >>> will probably be infrequent. I also strongly suspect that >>> this will come up again in IETF-wide Last Call because I >>> expect the web types will want to go over this with a >>> fine-toothed comb. So while I still don't understand why >>> you so strongly insist that r-component has to follow >>> q-component, >>=20 >> My sense is that John feels this was a closed issue and that >> the WG had reached agreement on q-then-r, so why revisit it? >=20 > Yes. I'm happy to reconstruct and explain again the reasons for > preferring q-then-r, including why I think the "copying" > argument is mostly bogus in practice, but I'm disinclined to > spend everyone's time doing so unless either the co-chairs say > "actually there was no conclusion earlier" or someone other than > Keith feels strongly about the other order and says so. >=20 > john >=20 >=20 >=20 From nobody Mon Aug 31 18:27:54 2015 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 E30881B4947 for ; Mon, 31 Aug 2015 18:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 J27Cy5VpFm7k for ; Mon, 31 Aug 2015 18:27:51 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBC71A88A4 for ; Mon, 31 Aug 2015 18:27:51 -0700 (PDT) Received: by ioeu67 with SMTP id u67so36768661ioe.1 for ; Mon, 31 Aug 2015 18:27:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ESQTVZkOG8hNcjHRX2l+q6vzN/9eSU8XY4xUY7G4dTQ=; b=M5MTvMyVJd3ISPDUgPnIXsq0MwjNHDKGau1HKp4tODqm9Wx3bj0poMGXsyjnTPClyb RzJet3jEyy8uzuKsbiG8wucplXKbWKLqH8Unp3Gjwt6GMuvD7Jjh0O3N3Z3LDxqJxtNr bzlqI5Nvtqvz+D0BpK0BSXDCGWZGgYcS7l5gcYPqRGIr1NC0G1Zhc/YPbgZy2MKE/BHF QTUrsCOwq/uRWFBq3Iaay5rESng3AlLwzKdoyh6/fCIiHixWxHhxWut2p0JuAViYTXw9 SiDjQhoFjN7wwhom3wQf8PnwddTcIEZyqdyc3Go1TOERVnY9QGYcOIHkEQWeB2Gg1gEo o+HQ== X-Gm-Message-State: ALoCoQlUGmsgqafBEDZMvao4m2yOXbk5RUtS+vCXvZB9aVfXmVQX3fptqezbdpLxKjB/HBAVfoWI X-Received: by 10.107.16.213 with SMTP id 82mr7355084ioq.50.1441070870673; Mon, 31 Aug 2015 18:27:50 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id z5sm190886igl.21.2015.08.31.18.27.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2015 18:27:49 -0700 (PDT) To: "Svensson, Lars" , "urn@ietf.org" References: <55804085.5000105@gmail.com> <5584CD07.4050906@gmail.com> <24637769D123E644A105A0AF0E1F92EF010D0A868F@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre - &yet Message-ID: <55E4FF08.1000200@andyet.net> Date: Mon, 31 Aug 2015 19:27:36 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D0A868F@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt 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, 01 Sep 2015 01:27:53 -0000 Hi Lars, thanks for the feedback and my continued apologies for the delayed reply. On 7/5/15 1:37 PM, Svensson, Lars wrote: > Melinda et al.; > > My comments are even more minor than Juha's: > > 1) Introduction The first paragraph discusses the difference between > resource identifiers and abstract designators. In order to avoid > confusion we should make it clear that "resource" is meant as > "internet resource", since also abstract designators do identify > resources (but not internet resources). This comment also applies to > the document's abstract. I'm not sure. RFC 3986 says that "a resource is not necessarily accessible via the Internet", so limiting the scope of resources in the URN context to Internet resources seems perhaps incorrect. On the other hand, RFC 1737 does say that a URN is an "Internet resource identifier". I would slightly favor leaving the text as-is for now. > 2) Terminology The first paragraph mentions that important terms are > taken from RFC 3986. I think it would help the interpretation if we > could list exactly what terms are to be interpreted in the RFC 3986 > fashion (e. g. "resource"). That's a good point. I might suggest... OLD Several important terms used in this document, including some "normalization" operations that are not part of the Unicode Standard [UNICODE], are defined in the URI specification [RFC3986]. NEW Because this document attempts to harmonize the definition of URNs with that of URIs, it borrows a number of important rules (such as "normalization" operations that are not part of the Unicode Standard [UNICODE]) from the URI specification [RFC3986], and also uses several key terms (such as "resource" and "identifier") in effectively the sense as the URI specification. I don't exactly want to say that some of these key terms are "defined" in RFC 3986 because I don't consider ostensive definition to be sufficient for protocol specifications. > 3) URN syntax The third paragraph discusses "rules not defined here" > and mentions "path-absolute" and "query", but I cannot find that > those two rules are used in the ABNF. Good catch. Those were used in a previous version, but are no longer used. > 4) Appendix A, §A.6 This section says that the use of p-components is > not allowed unless the registration explicitly says how. There are no > p-components any more. Correct. Will fix. Peter From nobody Mon Aug 31 19:39:11 2015 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 DC9551B5E9D for ; Mon, 31 Aug 2015 19:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 iH4kcQy7yiBx for ; Mon, 31 Aug 2015 19:39:01 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EF71B5931 for ; Mon, 31 Aug 2015 19:39:01 -0700 (PDT) Received: by iog7 with SMTP id 7so56716424iog.2 for ; Mon, 31 Aug 2015 19:39:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=jySf4Ucxx1FjNCmMvPaM/9FL/bX5rIrYmqiEUJRylck=; b=nJzOagQOwfsyEItiD9fyq48jACRwMOfxm+3OxGmm+Wx91K08vfkPCUTkQVGZvbPx2A zKVnaciEfzMMGWFOy3baqY3do/xt/Wzgl8ZT5QE/+FN3No1iO4VOBuaVW0WaRsy6esKT PrNS7zZjqiEael0bPkyOpTueTQQMvLOEzsdwJ1xGoKlzaLl/ewmZ151hrd3OgoKmHKKI 5xcGyGxMOVN0qrFzcl1WuHwDowQVdyln83daVnMJ9AvZW8VrWm8x7swymbcSgmQQ2YdL BhGWtghfotqaMwovM0KPZLYuCe/xeO7P/XqGhnd5p75v/HIVGUJl49KV/3lMPjWy3emH vlhw== X-Gm-Message-State: ALoCoQmSd8Lsyy5VkTW0oYQH9vhwZ/srI3BqwhbfsjvwQOmtmkwAE4IAfbEOJ2r9gTodrz0zEWwA X-Received: by 10.107.32.196 with SMTP id g187mr8342600iog.33.1441075140238; Mon, 31 Aug 2015 19:39:00 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id c64sm14793972ioc.13.2015.08.31.19.38.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2015 19:38:59 -0700 (PDT) To: "Hakala, Juha E" , Melinda Shore , "urn@ietf.org" References: <55804085.5000105@gmail.com> <5584CD07.4050906@gmail.com> From: Peter Saint-Andre - &yet Message-ID: <55E50FC2.8050106@andyet.net> Date: Mon, 31 Aug 2015 20:38:58 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Tobias Weigel , "stella@isbn-international.org" , "isabelxiang@hotmail.com" Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt 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, 01 Sep 2015 02:39:05 -0000 Hi Juha, thank you for reviewing the document and providing detailed feedback. Comments inline. On 7/1/15 4:19 AM, Hakala, Juha E wrote: > Hello Melinda; all, > > I have only a few, mostly minor comments to the latest RFC2141bis > draft. As far as I am concerned, our work is almost done. With this > syntax the library community will be able to do everything we wanted > initially to do, and then some more - we did not anticipate the > possibility to send resolution requests not only to the URN > resolvers, but also to the identified resources themselves or to the > applications managing them. Since resources are getting more complex > - research data sets are an example of this -, this kind of enriched > functionality may become very useful in the long run. It's good to hear that the needs of the library community seem to have been met. > In the second paragraph of chapter 3.3 we say that unless defined for > a particular namespace, use of q-, r- and f-components is > disallowed. > > This is OK for q- and r-components, but I am not sure if such > limitation is required for F-component, since it has no impact on URN > resolution. Moreover, F-component is not namespace specific but > depends on file format. It can be added to the URN:ISBN if the > identified book is e.g. a PDF document, but not to every URN:ISBN > (even if the ISBN identifies an e-book; printed books certainly do > not have URI fragments). So it is likely that f-component can never > be applied to all URNs in a certain namespace, but it may be possible > to apply it to some URNs in most (actionable) namespaces. As I recall, the purpose of the text you have cited was to maintain strict compatibilty with RFC 2141 for all existing namespaces; only if a namespace explicitly allows q-, r-, and f-components after 2141bis is published should it allow and use those components. This is an "opt-in" model, if you will, and seems like the safest approach (i.e., do not assume that it's OK to add an f-component to an "old", 2141-compatible namespace just because 2141bis says that f-components are now allowed). This is a form of Postel's Law, I think. > The example in the last paragraph of chapter 3.3.1 uses a real ISBN > but in wrong (urn:example) namespace. It is better to replace the > ISBN with a random NSS such as "bar", because the URN is not > actionable and even if it were, the fragment would not be > applicable. Yes, we'll fix that to prevent confusion. > Although libraries' primary intention was to use q-component for > passing resolution related information to URN resolvers, I see no > problem in using r-component instead to this purpose. IMO it is good > design to make a difference between requests to resolvers > (r-component) and requests to resources themselves or applications > managing them (q-component). Identified resources will become > increasingly large and complex (scientific data sets are a good > example of this) and it may be necessary to perform various > operations before the resource is ready to be sent to the user. Do you think that the text or example in Section 3.3.1 needs to change in order to make that clear? > In 3.3.3 we say that f-component need not be semantically equivalent > to the URI fragment (component). IMO URN f-component is never > semantically equivalent with URI fragment since f-component does not > have a role in identification. We avoid making this difference > explicit by saying that f-component is intended to "distinguish > integral parts of resources", which is OK to me in spite of being > somewhat vague. I think that "constituent parts" might be clearer. > If we want to be more specific we could say that what > is being distinguished are physical (encoded) parts of resources. > F-component cannot be applied to logical parts of resources unless > they coincide with physical ones. It might be a good idea to be more > specific about what f-component does because there is an increasing > need within my community (libraries, archives and museums) to > identify component parts of resources. If and when we start > developing a new standard identifier for logical components of > resources (or if we extend existing systems such as NBN in such a way > that they do the job) it is important to know precisely what the role > of f-component is. The present wording does not make that very > clear. I am not well versed in information science, so I am sure how the distinction between logical and physical parts is applied in that field. However, from my own limited perspective I hesitate to say that f-components are necessarily tied to physical representation because even though the "preface" and "chapter 3" and "afterword" might be constituent parts of a book, in an electronic book those parts are not represented physically as they would be in a paper book. > The example in the last paragraph of chapter 3.3.3 uses a real ISBN > but in wrong (urn:example) namespace. It is better to replace the > ISBN with a random NSS such as "bar". URN:ISBN is actionable (as > http://urn.fi/URN:ISBN:978-952-10-7060-0) but urn:example is not. In > both cases fragment is not applicable. Yes, we will fix that too. > In chapter 6 (top of page 14) the draft states that "uniqueness > constraint means that an identifier within the namespace is never > assigned to more than one resource and never reassigned to a > different resource". We might consider saying "one resource (as > defined in the namespace)". Every journal article published in e.g. > Scientific American has the same ISSN, since in the URN:ISSN > namespace "resources" are serials. In SICI (Serial Item and > Contribution Identifier) namespace resources are journal issues and > articles. URN:NBN could be used for identification of still images > within these articles. I see your point. How about this? The "uniqueness" constraint means that an identifier within the namespace is never assigned to more than one resource and never reassigned to a different resource (for the kind of "resource" identified by URNs assigned within the namespace). > In chapter 6.1, the last paragraph of page 16 the draft requires that > particular attention should be paid to strings that might imply > association with well-known trademarks. More exhaustive formulation > would be "... well-known identifier systems and trademarks". In this > context we need to be even more concerned about NID strings like > "handle" and "doi" than "pepsi". Good point. > In 7.3.1 (Purpose of the URN registration) it is IMO necessary to > provide information whether resolution services are or will be > available, and if so, what the existing / anticipated services. > Registrants might even be able to provide examples for q- and > r-component semantics and syntax, even if they are registered > elsewhere later. That seems fine. > It might be a good idea to ask the registrants to clarify formal > status of the identifier (de jure standard / de facto standard / > other) and current / anticipated extent of its use (international / > national / local usage). In my experience and (see RFC 6648) the experience of the Internet community, it is not especially helpful to draw a distinction between standardized and unstandardized identifiers, because unstandardized identifiers have a tendency to leak into the space of standardized identifiers. > Identifiers with statuses "other" and "local > usage" should usually have informal than formal namespaces registered > for them. Here again, see RFC 6648. > The current scope question (number 4 on the list) is a > little bit of a mixed bag as it covers both geographical and > organizational issues; it might be better to target scope on various > organizational issues only (public / private sector, book trade / > libraries, military / civilian use etc.). It's not fully clear to me why some of those dimensions are relevant, but in any case I think the answers would emerge from asking about the community of use. Thus I propose: The scope and applicability of the URNs assigned within the namespace; this might include information about the community of use (e.g., a particular nation, industry, technology, or organization), whether the assigned URNs will be used on public networks or private networks, etc. > As regards the current second (later perhaps third) question on the > list, I would drop the request for telling why it is preferable to > use URN rather than some other technology. IETF does not need to know > this. Also asking the registrant to explain why existing URN > namespaces are not a good fit sounds a bit negative. I would ask the > registrant to describe how the namespace to be registered relates to > existing URN namespaces and how the new namespace complements them. I like that more positive focus. How is this? How the namespace relates to and complements existing URN namespaces, URI schemes, and identifier systems. Thanks again for the review. Peter From nobody Mon Aug 31 20:34:42 2015 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 BB03D1B60D4 for ; Mon, 31 Aug 2015 20:34:41 -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 uEIhv6mzog-C for ; Mon, 31 Aug 2015 20:34:40 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B78C1B7987 for ; Mon, 31 Aug 2015 20:34:39 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9D5B9207DA for ; Mon, 31 Aug 2015 23:34:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 31 Aug 2015 23:34:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=SCCVJ4aF+WErrhl fl10HJEMME+M=; b=isUPhWSRCXsQGWHogcF6xXjs1Fby5zYGsNBlkoT4w29bIaD Rh5YtpHNGFDjT2uBuY0Qu+78IDZXvRLCMNqBlr3syYFN3McsonwWmW2n1dr1Tyx/ 2WD94RiYFNZzVldN1w9PUgfPPZAQsPgNAoh62JyrBRbyLdHq5R7uheK1iRDw= X-Sasl-enc: dK9G13QnNrIQGrBLwpKP1otALh+5kqTaqM9+W1N3tCYk 1441078478 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A9326800B3; Mon, 31 Aug 2015 23:34:38 -0400 (EDT) To: urn@ietf.org References: <55804085.5000105@gmail.com> <5584CD07.4050906@gmail.com> <55E50FC2.8050106@andyet.net> From: Keith Moore Message-ID: <55E51CCC.4010308@network-heretics.com> Date: Mon, 31 Aug 2015 23:34:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E50FC2.8050106@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt 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, 01 Sep 2015 03:34:41 -0000 On 08/31/2015 10:38 PM, Peter Saint-Andre - &yet wrote: >> In the second paragraph of chapter 3.3 we say that unless defined for >> a particular namespace, use of q-, r- and f-components is >> disallowed. >> >> This is OK for q- and r-components, but I am not sure if such >> limitation is required for F-component, since it has no impact on URN >> resolution. Moreover, F-component is not namespace specific but >> depends on file format. It can be added to the URN:ISBN if the >> identified book is e.g. a PDF document, but not to every URN:ISBN >> (even if the ISBN identifies an e-book; printed books certainly do >> not have URI fragments). So it is likely that f-component can never >> be applied to all URNs in a certain namespace, but it may be possible >> to apply it to some URNs in most (actionable) namespaces. > > As I recall, the purpose of the text you have cited was to maintain > strict compatibilty with RFC 2141 for all existing namespaces; only if > a namespace explicitly allows q-, r-, and f-components after 2141bis > is published should it allow and use those components. This is an > "opt-in" model, if you will, and seems like the safest approach (i.e., > do not assume that it's OK to add an f-component to an "old", > 2141-compatible namespace just because 2141bis says that f-components > are now allowed). This is a form of Postel's Law, I think. I think this is not only wrong for several technical reasons that I've already described, but also unnecessary for compatibility, since the use of q-, r- and/or f-components doesn't affect the "assigned portion" of the URN. The whole point of URNs is to permit uniform handling by software of names from different namespaces. This continued insistence on making components namespace-specific is trying to break that. Keith From nobody Mon Aug 31 20:48:11 2015 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 5AB6F1A00FF for ; Mon, 31 Aug 2015 20:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 7NUa-DPPixEx for ; Mon, 31 Aug 2015 20:48:07 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDF71B76BC for ; Mon, 31 Aug 2015 20:48:07 -0700 (PDT) Received: by igbuu8 with SMTP id uu8so39951230igb.1 for ; Mon, 31 Aug 2015 20:48:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=2r1N554vDoxIu4xcbvtw0g6RffF3AV+WXz5XG+m0lDc=; b=l1e7Xvi4YVNXkho5Iarf8SS9wHLx7lh9lLO6A8sli9xkV9SP4sfnH/JMD8gWuUjPc5 ntXpSvmz0sdVtEt1UWSuGdVdt/7EFv8xHLTQchvF005L0G8Z9jJLeD/yT/L80+3QzW5J IDr6FU8EeFi+YXfXXwdA7onQS2KCFB7k9zrfstHP0I95TlIj+XbTV4lG8a3PtURwmeRS mvyv6W8mQ212dN3nKUNMtPVOsXW0y4BPcLQFmk8NaB4nhL8uZD4WvKucL1axpgkN+iog vjGPAhUH7xHsdg7eSbbqhC9UirEAr9w9UMAzLEQ9NTrhHSf/jw++pdMA5U5GjTpYm4Cc jEcg== X-Gm-Message-State: ALoCoQnyXvtZvYLjd+DBqqXXl9PaxkEC+mbomCyPy3Fho2wQyTPqRvywGiryK7Zvm6+tQGkV5zdR X-Received: by 10.50.13.100 with SMTP id g4mr566250igc.62.1441079286550; Mon, 31 Aug 2015 20:48:06 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id r8sm14940315ioi.10.2015.08.31.20.48.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2015 20:48:06 -0700 (PDT) To: Keith Moore , urn@ietf.org References: <55804085.5000105@gmail.com> <5584CD07.4050906@gmail.com> <55E50FC2.8050106@andyet.net> <55E51CCC.4010308@network-heretics.com> From: Peter Saint-Andre - &yet Message-ID: <55E51FF4.1080404@andyet.net> Date: Mon, 31 Aug 2015 21:48:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55E51CCC.4010308@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt 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, 01 Sep 2015 03:48:10 -0000 On 8/31/15 9:34 PM, Keith Moore wrote: > On 08/31/2015 10:38 PM, Peter Saint-Andre - &yet wrote: >>> In the second paragraph of chapter 3.3 we say that unless defined for >>> a particular namespace, use of q-, r- and f-components is >>> disallowed. >>> >>> This is OK for q- and r-components, but I am not sure if such >>> limitation is required for F-component, since it has no impact on URN >>> resolution. Moreover, F-component is not namespace specific but >>> depends on file format. It can be added to the URN:ISBN if the >>> identified book is e.g. a PDF document, but not to every URN:ISBN >>> (even if the ISBN identifies an e-book; printed books certainly do >>> not have URI fragments). So it is likely that f-component can never >>> be applied to all URNs in a certain namespace, but it may be possible >>> to apply it to some URNs in most (actionable) namespaces. >> >> As I recall, the purpose of the text you have cited was to maintain >> strict compatibilty with RFC 2141 for all existing namespaces; only if >> a namespace explicitly allows q-, r-, and f-components after 2141bis >> is published should it allow and use those components. This is an >> "opt-in" model, if you will, and seems like the safest approach (i.e., >> do not assume that it's OK to add an f-component to an "old", >> 2141-compatible namespace just because 2141bis says that f-components >> are now allowed). This is a form of Postel's Law, I think. > > I think this is not only wrong for several technical reasons that I've > already described, Sorry, I haven't yet had time to reply to your large review. I'll start to do that soon, breaking it down into smaller chunks. > but also unnecessary for compatibility, since the use > of q-, r- and/or f-components doesn't affect the "assigned portion" of > the URN. This is true. > The whole point of URNs is to permit uniform handling by software of > names from different namespaces. I don't think that uniformity is the whole point (because IMHO that would primarily encompass something about defining a space of "persistent, location-independent resource identifiers"), but it is one desirable quality. > This continued insistence on making > components namespace-specific is trying to break that. In this case, we're trying to be careful about introducing new features or assuming that those new features have any meaning in the context of names that were defined before those new features were created. The *intent* of this caution has not been to break uniformity, although that might have been an unintentional byproduct. Although I'm open to discussing the tradeoffs and adjusting the text so that we don't break the principle of uniformity, inflammatory statements about the bad intent of the editors does not conduce to a constructive dialogue. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Aug 31 21:00:14 2015 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 C97B71B7B60 for ; Mon, 31 Aug 2015 21:00:13 -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 9G-QxXKSJc2w for ; Mon, 31 Aug 2015 21:00:12 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA891B7B5E for ; Mon, 31 Aug 2015 21:00:12 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3B6A4201E1 for ; Tue, 1 Sep 2015 00:00:12 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 01 Sep 2015 00:00:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=/jrnrxO9l8T4yOs kAHR1TmOJ3PY=; b=ZGKuW7PkeC/s83nRBtBK2EGJrM2mDwnHH8xQD0I0aDipjm1 fvGEf+sZLlJODKONfQyTCLvtp7fI8ygczQy6EDJdq0kC5Vh3bBy4ifHy9UrqRam7 9jY4w2b4bQqiR0nhYK9Ju3mLwV3KbCK9zl+M+RhGjPkEt8RRrYC3fWfbsxuE= X-Sasl-enc: wesZiJ1HGGpH5N5/JbpvnbNcF7SIkerjFcIDj7HsMvXs 1441080011 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id D058FC00013; Tue, 1 Sep 2015 00:00:11 -0400 (EDT) To: urn@ietf.org References: <55804085.5000105@gmail.com> <5584CD07.4050906@gmail.com> <55E50FC2.8050106@andyet.net> <55E51CCC.4010308@network-heretics.com> <55E51FF4.1080404@andyet.net> From: Keith Moore Message-ID: <55E522CA.8000005@network-heretics.com> Date: Tue, 1 Sep 2015 00:00:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E51FF4.1080404@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt 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, 01 Sep 2015 04:00:13 -0000 On 08/31/2015 11:48 PM, Peter Saint-Andre - &yet wrote: > In this case, we're trying to be careful about introducing new > features or assuming that those new features have any meaning in the > context of names that were defined before those new features were > created. The *intent* of this caution has not been to break > uniformity, although that might have been an unintentional byproduct. > > Although I'm open to discussing the tradeoffs and adjusting the text > so that we don't break the principle of uniformity, inflammatory > statements about the bad intent of the editors does not conduce to a > constructive dialogue. I should have worded things slightly differently. I don't think the editors are "trying" to break uniformity, in the sense that this is their intent. I do think that trying to make components namespace-specific has the effect of breaking uniformity. And I believe that this further degrades the value of URNs in several ways. To me this seems obvious because (long ago) I've written URN resolution systems and modified browsers so that URNs were "clickable". As soon as we start talking about components being namespace-specific, I immediately see how this makes the browser more complex (and the complexity increases without bound) and blurs the layering between the namespace and the publisher (with very unfortunate implications). Keith