From nobody Tue Jan 3 20:19:50 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7588129BB4; Tue, 3 Jan 2017 20:19:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148350358881.27933.1944249074526631919.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 20:19:48 -0800 Archived-At: Cc: urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@gmail.com, aamelnikov@fastmail.fm Subject: [urn] urnbis - Not having a session at IETF 98 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 04:19:49 -0000 Barry Leiba, a chair of the urnbis working group, indicated that the urnbis working group does not plan to hold a session at IETF 98. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Tue Jan 3 22:04:56 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B45129C27 for ; Tue, 3 Jan 2017 22:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6I9T_O9d66DQ for ; Tue, 3 Jan 2017 22:04:53 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 BBEAA129473 for ; Tue, 3 Jan 2017 22:04:53 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id n85so213529371ioi.2 for ; Tue, 03 Jan 2017 22:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=CriE4ROZFr+hC2w0vhRTR3j2Mmlzo4NBEm6aZmTGFE4=; b=dLOJuNaB3ifLZ7IpJvd88Nt/L3NUfB5QZ/CzEzxbxt8gGYqYkm1Jp2mJOrlg7OdiGF 0NSopWrGzjUD5gDaVhKrAyOo3261eySdJpXMMnskH6q2cyuV1mM9gT525ujPK3Sk7hJn Rlb+UyQe8oNSe3yQA+XAzfZsn1GtX7JEkY8d2zNtMyxrAvHOA5K6jDYEVE4M5TKAV7ma RMHTlSDRKWiXmKipIvtDXSi5NngM46QtlAKnyJpLdEv1WEBD0P5J+FUkXwO5Q2wqC4iD HTmUk6PSZs2Z8+vqDE/HRCZUE3EWC2hOpSOYvxfIovAIcqMra+WVN/y9x4uNr+rbUKCp rLgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=CriE4ROZFr+hC2w0vhRTR3j2Mmlzo4NBEm6aZmTGFE4=; b=PDaYlvBbjDNesxR7ZMS5p6qRP580ir7PfIH60e6ulT9nZm93QpmV+wiZkmzYtWFidb MqzyWkOj42yWsBmojvGVhtsBJ9sUsevc0bfMYkCDDtI5pvONyUgQI7Cytqv7CPTTvIBy /gS8O4bWBqsyOuAUwKyEzM/iP/sMtejhlcbEFXGdie6JcAs0rA/ZxNH5E0wQYQ8m7UMx 4WXH63xJrgJSsVgateuhGlKdLzWMpRwThE0uO03Z75uG+dORAws5VBHZbAB87PVPI0HQ 0VUm1zaGVNUqvbrxONP+9ab5Z3xpXsrKc564JQoRpnAcFuxvFznCzIOBxQXFnXPlYtZ8 SqGQ== X-Gm-Message-State: AIkVDXJqHMcWqLlR3jcdQb5CabJAaA3sTyA7WoZdSU+3BPzlejMDRBsMwaP75LONYDdoiS+d+bUO4ojJlMR+yA== X-Received: by 10.107.15.29 with SMTP id x29mr56817290ioi.185.1483509892730; Tue, 03 Jan 2017 22:04:52 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.208 with HTTP; Tue, 3 Jan 2017 22:04:52 -0800 (PST) In-Reply-To: References: From: Barry Leiba Date: Wed, 4 Jan 2017 14:04:52 +0800 X-Google-Sender-Auth: ufgYZDpLKlqp_b9epH3lBOZMWxQ Message-ID: To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-19 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 06:04:55 -0000 The chairs believe that this version reflects what was decided during the (now-long-ago) conference call plus the list discussion since then, and that the document is now done. There may, of course, be some "oopsies" that have crept in with the changes, so we will make a call for final comments. Let's call it a "working group last call for typos and major objections." We do not expect to see quibbles that have been discussed before, re-thinking of things that does not reflect a serious error in where we went with it, or other things of that sort. And, so, thus begins a last call of that nature, a last call for major objections and eyes looking for errors that have crept in. That call will run until... oh, let's make it easy and say 31 January. Everyone, please do have one last look. There will be an IETF last call, of course, but let's please not have working group participants waiting until then. Barry, chair On Sun, Jan 1, 2017 at 12:31 AM, John C Klensin wrote: > Hi. > > Ok, draft-ietf-urnbis-rfc2141bis-urn-19 has been posted. It > incorporates the changes to the definition and use of "lcoator" > discussed on this list over the last 48 hours as well as a > number of editorial changes to improve clarity and readability. > For example, there are now several more explicit inter-sectional > cross-reference and some redundant text has been eliminate. In > some case, the revisions make the text a bit more tedious, but > we have concluded that a bit of tediousness is preferable to > user confusion. > > There has also been a small change in tone wrt 3986. The > existence of conceptual, and sometimes confusing, differences > between 3986 -- a URL document with some URN aspects and > inclusions [1] -- and 2141bis have been called out explicit. > There are two reasons for this, neither of which is an attack on > 3986: (i) to reduce opportunities for endless discussions about > apparent, but small, differences in terminology between this > specification and 3986, as discussed on this list over the last > couple of weekss; (ii) to try to protect the URN definition > against the apparent likelihood that, whether the decision is > made in the marketplace or other SDOs, we seem to be in danger > of ending up with at least three different, even if mostly > consistent, specifications of URIs or subsets of them: 3986, the > WHATWG URL definition effort, and statements in various W3C > specs (notably related to HTML). > > It is possible that a similar comment should be made about the > relationship between this document, its terminology, and other > specifications (whether internal or external to the IETF). If > that is true, please send references and recommended text to the > list. > > For Section 4.3(2), Henry suggested slightly different text; I > (and Peter) believe what is now present does the job and fits > better with the surrounding sections. Anyone who believes > otherwise and thinks the debate is wroth reopening should say so. > > Peter and I believe this draft is suitable for WGLC and that it > would be appropriate for the co-Chairs and WG to take a > "showstoppers and major issues only" position relative to > further comments. We (and, as I understand it, Barry and > alexey) would really like to get this tied up before the Chicago > IETF. The only way I can see to accomplish that is to stop > nit-picking about, e.g., minor issues of terminology. > > best, > john > > > > > [1] See the 2141bis text for details and references.. > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Sat Jan 7 09:43:07 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684EB129449 for ; Sat, 7 Jan 2017 09:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AMx9FJkV0n_n for ; Sat, 7 Jan 2017 09:43:04 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F090B1293D9 for ; Sat, 7 Jan 2017 09:43:03 -0800 (PST) Received: from [192.168.178.20] ([93.217.111.75]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M96Jd-1cK6ed0Lr3-00CQlr for ; Sat, 07 Jan 2017 18:42:58 +0100 To: "urn@ietf.org" References: From: Julian Reschke Message-ID: Date: Sat, 7 Jan 2017 18:42:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:xiG9Pf6ZkfbBHHaCNq+ODZzrQ7TnCqBvdgVdcMPj0NMl6WeBmiw Ol/cOBRP0ij6ScHMTy30IGwnZt5itxqu4+u3HxKOn+xXyeLo9T+UwlweMLe/L/fRItyliSI m9gHMtYP3u2NYI+66nzyFcHLcgPGTy6eTZRIu2tVwMqDNREDpnfl6/SkFT4HHmPvQAFM/fW 1Q3PQKg4oRkiHSuEMXN0g== X-UI-Out-Filterresults: notjunk:1;V01:K0:Vb25o8PQTNM=:RreOo/t1N3iMnFmpYVB2Tx oKxSu/Bq0PhvHlqh0RbiQTkhjf1Yq1yQ3sEsb/tQu6zDQeUdHIfhERF46vOl1HtjtiukidpqA UyXAt6J9FSVDhrarbtPb5ctfe9PXfWfk5UY9O1xue9irsEGpXSXTdLWATmY/NRFwMhIT66RYu SmHoAxr8rlR9jwOSKMj4bQUEmdF2aBAWi3/XLwYAkZr/s8y/r4Q0JurzBXLyuABGNgzQNL3QD uRhvl6w/m8Chk6QcAhySIYRInafHJyAdd5pXedNDaPBtVOcGk7KONqJoBTYY5p1N00IIdnrbE 4GanevUq2ajuuRp6m1O5A/EucYyh0oL7utlv0ohIVnPx0NRg6AyGCr+w4znSqd/LPimDoq5td ltVNZiO0EprCupUlWeXZxaZ8pxDKdy9kWgadCbo15AqOuZ0tjt9ks1uhYoyB+s565KPqypMhT w3FwghVeYs7xjzjO6rL2OBtZifHQVFGnDUmmumEGtFks2nCC4vV5jrNPKmppZM2jIcLCfNRZb 8FM/o175zcMbvqCFOF/AtiYFvnvm7S3xjpeL3Hs7cKVYkm2lJOo+a/gpOs2IwBrYQbc6K6Kmf qVLrPIIubW1Ju2PTvD47rYQaY08ZU8C1AsEhMaKL04ErYE1DsAWLQqt8yYJUcf3qoUI0P+W4U JMAg7JHFrxm+KjfUS7YQ6kfW1soXfFBXkF8JYSCMwk+36X6iYhIlzai5XmwivC0O5ER93/p5K QUEd7HtE46/84mtoleIh3KpKpluSPICH0lA/6Lj3rKgY/tZQv0YLp4O4JYrrKYikUh4U8Zl0T Q1+WjBrnE/zrj8PgLUFW3z5++7+IzuRjbiGz4jYUFhn/Qq6kwSxGzViWd5nR/Xf/zEARb3Mk3 B5PUuBZETPO5EhNf/06oJb5mpFLAgzmhcA+4KHEgEW/xMOgaOMs57ihXZtz/IocM5XOwOp4ID 1wsaIyY8UIU4Ktqzu4/FD4A2D9xbZmLPUvnvJ92vjl5bXFxfcB5M0Q90wyMqxahrrDIEv2iwx tnSaj88SThP2qCldBJPe4vY= Archived-At: Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 17:43:05 -0000 Reviewing my own feedback from 7 months ago and reposting those parts that still seem to apply...: On 2016-04-27 20:11, Julian Reschke wrote: > > rq-components = ( "?=" q-component > [ "?+" r-component ] ) / > ( "?+" r-component > [ "?=" q-component ] ) > q-component = pchar *( pchar / "/" / "?" ) > r-component = pchar *( pchar / "/" / "?" ) > f-component = fragment > > These come as a surprise to anybody not already familiar to what led to > the spec. > > Either introduce them later, or insert some prose explaining where they > come from. > > Also, it would be good if there was a discussion about compatibility > with existing use of queries, as these essentially reserve certain > variants of queries for generic use. > ... > For the sake of consistency with RFC 3986, neither the general syntax > nor the semantics of q-components are defined by, or dependent on, > the namespace of the URN. In parallel with RFC 3896, specifics of > syntax and semantics, e.g., which keywords or terms are meaningful, > of course may depend on a particular namespace or even a particular > resource. > > I agree that this is the right thing to do, but I'm not sure what this > has to do with 3986. 3986 allows a scheme to mandate a specific syntax, > no? > ... > ... > For the sake of consistency with RFC 3986, neither the general syntax > nor the semantics of f-components are defined by, or dependent on, > the namespace of the URN. In parallel with RFC 3896, specifics of > syntax and semantics, e.g., which keywords or terms are meaningful, > of course may depend on a particular namespace or even a particular > resource. > > s/3896/3986/ > > Section 5.2 of [RFC3986] describes an algorithm for converting a URI > reference that might be relative to a given base URI into "parsed > components" of the target of that reference, which can then be > recomposed per RFC 3986 Section 5.3 into a target URI. This > > s/RFC3986// > ... Best regards, Julian From nobody Sat Jan 7 13:01:58 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FA8129B91 for ; Sat, 7 Jan 2017 13:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QawDBef6l0HO for ; Sat, 7 Jan 2017 13:01:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D37C129B74 for ; Sat, 7 Jan 2017 13:01:54 -0800 (PST) Received: from [192.168.178.20] ([93.217.111.75]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M7ojs-1cdDi70TM8-00vPYG; Sat, 07 Jan 2017 22:01:47 +0100 To: Barry Leiba , "urn@ietf.org" References: From: Julian Reschke Message-ID: <956b23b0-9f16-7af9-9d41-d664cb8c60c0@gmx.de> Date: Sat, 7 Jan 2017 22:01:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:J8PfOI8jrThpkvykuFrz8kIq/B1ihbEUmxEqFpx+9ZTt6DWv+yf mSdyC17gbynCPxEyCEQsOmnU9HGsODLMtvm05884Wf//Dc2gXK6m3g5hny7gWQkxr4UcVZs kPf94kvp3hNhdmldCDBLUd2CGjWAfDemvDDNxXBGGERgP17tGySJLIcwGnXX6hI1J2xah6h CTyc+aaYxIQNVj/P3NEdA== X-UI-Out-Filterresults: notjunk:1;V01:K0:cDURwr5xwLk=:1Ri1kNmIH0mbax5rl1FvfM K3zpEUs/iWVs2VU7gkUSrnaeLGWElgJEflfuv24pnpZPgiQBJbQA4zswilH06FKsyC9AzWdLq 0ZXHSCutaDJB9SqqTXxnXt3nNAqFWG7GwQraMQZl1v2ScaGafXod0tg2vXCFXXLw6EUPqueLy C4rt+O+TXt+FpzZJOmDVg6Fev1NhxiZPqZhYeW0rSoA8un2Yhj7rhEJ4IeQkHP8uby/8uRSy9 kDdnaR0BXJ/ZLZijHXh6YT4TfS0LiojFrBKpBge/WRCnBIBkKTqWWALqlV79gyQTiju0Y0UAC dzkUQ40ESQ582/SXnc5Qh/E8ryuYkyTS/LTrMJ1AnMgOqZZ+y03WAvm98x/7v+je2njRCYvIx +y8qBOWaWNyzfT+eul/P6JXP0GE2/MtLQwofHB/gECF/K2sIbADzD5/IakjOf81ZdScIoyYLY CA9eMt9lfdlh1fXOtwfviXg0bJ0cH6e/rAUrO+H5nlQBpEUaTeo4rpOWXdibUpC5TyqMV6l3o 9SAkPQ6SaEiK4p954mE9T7TWZamZnTzzHHms0JFz6u4z8JQINYVid0FtRXXZv0HILkIAtxFSX /h4g1e1/tYET/YHnuAbu+LaKpS3ZkvRYB0LCl0aChbKmfqdBP0pTyLf7kumQ7QEUVtoLXXouX lO+LXGHUzRb6mK4enD5zvSfMsG9JLJ7+u1zX1N5ntzte//L2szUCLwKRmMziBcbI0XRWtuzbd 3Ao9OGDBs4p98Kpi3goVheeeA+aurLQ+BsNjPfed8BT1JSG5OTZGog8faj6mDM7f7Bw8LM965 ad8++Cdqd6QmFg6ytQv9ofdLmMPw2yMRe6le+A8B+bEjVhtMl7Pe6rUw8GEEJV2u940329Yir OrnuIoCkXJ6sJyr/Bnq33zVzT7o3DRShrEa0pVVTMDssD2uQlIC6hHRCj2eRL11BYZJUpBPXK IegbG60Z6kSCJFt7rG+DW7RPNbyexns5beOhtqmqKa2GTRffgyj2Ca3b3aiJoZGG2pV/sVjKc od/1v5/ZnhQV0ul6toWDkuew6l2FIIC+kR09RxGOw1i1f+tayuoadYqRXPR2Rd+VCw== Archived-At: Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-19 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 21:01:57 -0000 ...ok, here's my feedback...: Major: Abstract A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN- equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. Observation: this definition of "URN" actually is inconsistent with the one in RFC 3986 (which includes names that use URI schemes other than "urn"). I understand it's on purpose and called out later, but maybe there's a way to avoid this confusion? (also, maybe insert a few paragraph breaks...) 1. Introduction ... This document rests on two key assumptions: 1. Assignment of a URN is a managed process. Any reader familiar with urn:uuid will ask him/herself: so is this namespace ok? ... The foregoing considerations, together with various differences between URNs and URIs that are locators (specifically URLs) as well According to RFC 3986, a URI that is a locator by definition *is* a URL, no? as the greater focus on URLs in RFC 3986 as the ultimate successor to [RFC1738] and [RFC1808], may lead to some interpretations of RFC 3986 and this specification that appear (or perhaps actually are) not completely consistent, especially with regard to actions or semantics other than the basic syntax itself. If such situations arise, discussions of URNs and URN namespaces should be interpreted according to this document and not by extrapolation from RFC 3986. I really believe that this is going to cause more confusion than it possibly can avoid. I think it would be an improvement to remove this paragraph altogether. 1.1. Terminology The following terms are distinguished from each other as described below: URN: A URI (as defined in RFC 3986) using the "urn" scheme and with the properties of a "name" as described in that document as well as the properties described in this one. The term applies to the entire URI including its optional components. Note to the reader: the term "URN" has been used in other contexts to refer to a URN namespace, the namespace identifier (NID), the Assigned-name, and to URIs that do not use the "urn" scheme. All but the last of these is described using more specific terminology elsewhere in this document, but, because of those other uses, the term should be used and interpreted with care. Please separate the "note to the reader" from the terminology definition. ... The term "name" is deliberately not defined here and should be (and in practice, is) used only very informally. RFC 3986 uses the term as a category of URI distinguished from "locator" (Section 1.1.3) but also uses it in other contexts. If those uses are treated as definitions, they conflict with, e.g., the idea of the name of a URN namespace, i.e., a NID or terms associated with non-URN identifier systems. Again, this just creates confusion. RFC 3986 indeed uses the term "name" in several places to talk about ...names. The same is probably true for the majority of all RFCs. I don't think this is a problem. 1.2.1. Resolution With traditional Uniform Resource Locators (URLs), i.e., with most URIs that are locators, resolution is relatively straightforward because it is used to determine an access mechanism which in turn is used to dereference the locator by (typically) retrieving a representation of the associated resource, such as a document (see Section 1.2.2 of [RFC3986]). /most URIs that are locators/all URIs that are locators/ But with that, this could be further simplified... 2. URN Syntax As discussed above, the syntax for URNs in this specification allows significantly more functionality than was the case in the earlier specifications, most recently [RFC2141]. It is also harmonized with the general URI syntax [RFC3986] (which, it must be noted, was completed after the earlier URN specifications). Exactly how is the last sentence relevant? 2.2. Namespace Specific String (NSS) In order to make URNs as stable and persistent as possible when protocols evolve and the environment around them changes, URN namespaces SHOULD NOT allow characters outside the basic Latin repertoire [RFC20] unless the nature of the particular URN namespace makes such characters necessary. RFC 20 does not seem to define "basic Latin repertoire". 2.3.2. q-component For the sake of consistency with RFC 3986, the general syntax and the semantics of q-components are not defined by, or dependent on, the URN namespace of the URN. In parallel with RFC 3896, specifics of syntax and semantics, e.g., which keywords or terms are meaningful, of course may depend on a particular URN namespace or even a particular resource. I have no idea what the text about RFC 3986 is for. RFC 3986 does not care about the structure of a query component. 2.3.3. f-component The f-component is intended to be interpreted by the client as a specification for a location within, or region of, the named resource. It distinguishes the constituent parts of a resource named by a URN. For a URN that resolves to one or more locators which can be dereferenced to a representation, or where the URN resolver directly returns a representation of the resource, the semantics of an f-component are defined by the media type of the representation. ... I understand that it took a lot of time to come up with this, but I see absolutely no gain over just using the term fragment identifier. After all, it *is* the fragment identifier, as a URN is a URI, right? 4.2. Parsing In part because of the separation of URN semantics from more general URI syntax [I-D.ietf-urnbis-semantics-clarif], generic URI processors need to pay special attention to the parsing and analysis rules of RFC 3986 and, in particular, must treat the URI as opaque unless the scheme and its requirements are recognized. In the latter case, such processors may be in a position to invoke scheme-appropriate processing, e.g., by a URN resolver. A URN resolver can either be an external resolver that the URI resolver knows of, or it can be functionality built into the URI resolver. Note that this requirement might impose constraints on the contexts in which URNs are appropriately used; see Section 4.1. Can we state the same without referring to a document we decided not to publish? 4.3. URNs and Relative References Section 5.2 of [RFC3986] describes an algorithm for converting a URI reference that might be relative to a given base URI into "parsed s/URI reference/relative reference/ components" of the target of that reference, which can then be recomposed per RFC 3986 Section 5.3 into a target URI. This s/RFC 3986// algorithm is problematic for URNs because their syntax does not support the necessary path components. However, if the algorithm is applied independent of a particular scheme, it should work predictably for URNs as well, with the following understandings (syntax production terminology taken from RFC 3986): It *does* work predictably, right? 1. A system that encounters a that obeys the syntax for , whether it explicitly has the scheme "urn" or not, will convert it into a target URI as specified in RFC 3986. A by definition does not contain a scheme name, so the mention of "urn" is misleading here. 2. Because of the persistence and stability expectations of URNs, authors of documents, etc., that utilize URNs should generally avoid the use of the "urn" scheme in any that is not strictly a as specified in RFC 3986, specifically including those that would require processing of . Given my previous comment, maybe most of this can be removed? 4.4. Transport and Display When URNs are transported and exchanged, they MUST be represented in the format defined herein. Further, all URN-aware applications MUST That's a tautology, no? Otherwise they wouldn't be URNs... offer the option of displaying URNs in this canonical form to allow for direct transcription (for example by copy-and-paste techniques). That makes it sound as if there was a form other than the canonical one which is still a URN, wich I believe is not true. Editorial: 1. Introduction A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) [RFC3986] that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. A URN namespace is a collection of such URNs, each of which is (1) unique, (2) assigned in a consistent and managed way, and (3) assigned according to a common definition. (Some URN namespaces create names that exist only as URNs, whereas others assign URNs based on names that were already created in non-URN identifier systems, such as ISBNs [RFC3187], ISSNs [RFC3044], or RFCs [RFC2648].) Para break before "A URN namespace...". 3.1. Procedure If an r-component, q-component, or f-component (or any combination thereof) is included in a URN, it MUST be ignored for purposes of determining URN-equivalence. remove "(or any combination thereof)" -- unless I'm missing something, this is entirely redundant. Nits: metadata: should be "Applications and Real-Time" or "art 9.2. Informative References [DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The "doi" URI Scheme for the Digital Object Identifier (DOI)", June 2003, . This will likely require the phrase "work in progress". [I-D.ietf-urnbis-semantics-clarif] Klensin, J., "URN Semantics Clarification", draft-ietf- urnbis-semantics-clarif-04 (work in progress), June 2016. We shouldn't need this reference. (I also note that the references sometimes include the DOI and sometimes do not, but this can be fixed by the RFC Editor) From nobody Sat Jan 7 13:45:02 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A906129BDC for ; Sat, 7 Jan 2017 13:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 3k_eqUhvVtL7 for ; Sat, 7 Jan 2017 13:44:59 -0800 (PST) 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 AF7F7129BD2 for ; Sat, 7 Jan 2017 13:44:59 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cPynJ-000JNA-KM; Sat, 07 Jan 2017 16:44:57 -0500 Date: Sat, 07 Jan 2017 16:44:51 -0500 From: John C Klensin To: Julian Reschke Message-ID: <20022D35B6F9EC84EF0C7901@PSB> In-Reply-To: References: 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.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 21:45:01 -0000 Julian, My belief is that these issues have already been dealt with in -19 or earlier. If you disagree and consider the issues substantive enough to meet the criteria Barry laid out, please explain. Some comments below. --On Saturday, January 7, 2017 18:42 +0100 Julian Reschke wrote: > Reviewing my own feedback from 7 months ago and reposting > those parts that still seem to apply...: > > On 2016-04-27 20:11, Julian Reschke wrote: >> >> rq-components = ( "?=" q-component >> [ "?+" r-component ] ) / >> ( "?+" r-component >> [ "?=" q-component ] ) >> q-component = pchar *( pchar / "/" / "?" ) >> r-component = pchar *( pchar / "/" / "?" ) >> f-component = fragment >> >> These come as a surprise to anybody not already familiar to >> what led to the spec. >> Either introduce them later, or insert some prose explaining >> where they come from. The paragraph immediately above the syntax in Section 2 ("The basic syntax for a URN is defined...") now contains explicit forward pointers to the relevant defining sections. If you think more is needed, please explain and propose text. Whether one soul supply syntax before or after the explanation of what the elements are about is a matter of taste; when I've done it one way in a proposed RFC, I'm been attached and when I've done it the other way, I've been attacked too, so, speaking personally and as co-editor, I'm no longer interested in the discussion. >> Also, it would be good if there was a discussion about >> compatibility with existing use of queries, as these >> essentially reserve certain variants of queries for generic >> use. I believe there is now fairly extensive discussion on that topic. Again, if you think more is needed, please explain and, ideally, supply text. Note, however, that there is no "existing use of queries" within the URN scheme as defined in RFC 2141. Going very much further than 2141bis goes now (which is, IIR, further than -16 did) is ultimately not about the "urn:" scheme but interpretation of 3986 including both what it says and what it omits. Some of those issues have been discussed fairly extensively on the mailing list but, at least IMO, if the WG has neither mandate nor authorization to update or otherwise modify 3986, then the inevitable corollary is that 3986 needs to stand on its own. The new comments about potentially-conflicting terminology or language was motivated precisely by WG discussions of related issues. >> ... >> For the sake of consistency with RFC 3986, neither the >> general syntax nor the semantics of q-components are >> defined by, or dependent on, the namespace of the URN. In >> parallel with RFC 3896, specifics of syntax and semantics, >> e.g., which keywords or terms are meaningful, of course >> may depend on a particular namespace or even a particular >> resource. >> >> I agree that this is the right thing to do, but I'm not sure >> what this has to do with 3986. 3986 allows a scheme to >> mandate a specific syntax, no? Yes, at least as I read it. But, IIR, there have been some claims that 3986 does not obviously allow a scheme to delegate the syntax to other (non-scheme) parts of the URI (specifically a namespace in the urn scheme case). At this point, I would personally prefer sentences to the effect of "no matter what you think 3986 says, URNs works this way...", but I don't think that a proposal like that would be constructive or helpful. If you think this is important and want to propose alternate text, please do so. >> ... >> For the sake of consistency with RFC 3986, neither the >> general syntax nor the semantics of f-components are >> defined by, or dependent on, the namespace of the URN. In >> parallel with RFC 3896, specifics of syntax and semantics, >> e.g., which keywords or terms are meaningful, of course >> may depend on a particular namespace or even a particular >> resource. >> >> s/3896/3986/ I thought we had caught all of those. Both remaining cases, now corrected in the working draft of -20 (which, unless major issues show up or Barry directs otherwise, will appear only after the informal WG Last Call ends at the end of the month). FWIW, even though it is clearly better to fix it now, this is the sort of thing the RFC Editor is really good at catching and fixing. >... best, john From nobody Sat Jan 7 13:57:48 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000B2129574 for ; Sat, 7 Jan 2017 13:57:46 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cflzsVm6G7ks for ; Sat, 7 Jan 2017 13:57:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD6C129424 for ; Sat, 7 Jan 2017 13:57:44 -0800 (PST) Received: from [192.168.178.20] ([93.217.111.75]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MOBOi-1cMhCq2T6y-005Vx2; Sat, 07 Jan 2017 22:57:32 +0100 To: John C Klensin References: <20022D35B6F9EC84EF0C7901@PSB> From: Julian Reschke Message-ID: Date: Sat, 7 Jan 2017 22:57:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20022D35B6F9EC84EF0C7901@PSB> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:dDNIBXJAWdtLhvqtHNF8QLNYJCuZYrFGBiWtL3htOl13oG6CK6S T/5Sm3gTs7ZNUFhLE3qYawCW1S1Mn83SPA/Y7xzclbF3WyLZ+MpKhMYJ/zAQyd2XFhhtScj mnf/b1SkT3XeJGw7+ILBeiug4tNncQy8zR0iFGK1wk9nkUaiGbQUB6U12J/3k7lAZ/CjBlU H8Jf3GbRWVkN0zd34xnqQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZsE5OEi2S2g=:kyplMPhWOmaLcQsdNtwSbO GUdtcMGfhBRRgVFsUEHQm/l7j2crD6tl18taYgjN355U15T0Bhn4eQJHUhobuT4XWynaw7cEu n6B74Z1TVW10ErCEFewr01mb886tVJN0TP0+TSAX07zMbqLY3fAD2aMq39jOC6cdbai6mFfC1 v+1rKagQuo5PWgCtCVeaWB8uXU1DskbYXVuvkYclOAZxhdP0DfHfd119sVB31MKB9mzm4Vr1i +gYvUEGKv4K2SIy5KipnLR/sPnlIL64zfNOqmD6nQBwXzvYNE/PiddxjWpKfEdEIXyzFI/gkm /nQj9eYCg8pdEG9F/ObzB8YMPS9ZARVxFrNCehzw2L/zMzD6FkYDu+53TyoVzW76Qf+YyaX5N CU76fuzzCPzfcNAx5Vxg04l7I2p2GF14ZkFd9KMQyHpGI9UI2UEn90CR42Cbcc3aTWqdPoshE xm8QO8DhQOfjFdmc7p316xHxr1D1bEpUWwfGTn9p8hwuQIOSbh6OpXgZTwi6cn7JvTA/qETo7 h6ZWo4KBjt7vJz5Ip12kP8iSzYph0x7y+90rzrLMv+bNIdErZOaMpUtWNYEK2MomOWDH2B3KU JQMUs7H7GuiHazsOu27iju907GuMGi+K9SWUrFtXKvL5JUTy6k6a0LbXWPda9cpX0hb9fzrHa eVzGE01gixMyVVHxj0nabb0LW5UUX458fUzSZTKoKzbAn9oEfoWaYoi9RxxlOtGJlb6RZGcox Zh/svTF/kUrleD68JllgtOXKnu+u7pyiTmrJk9fAm0N7rEunJ9ZbPyECYLoos3XncfLxFFkQk kLBdUxJOpWxSGbdvMuGoimvuMcAnKgeZHW+ul5uYmW5o5oITkXrK2x5yVd3bDJapuolfeZUfX UIMzvg7cFdBx3lNeDUhI87O5dmDrT0y2CjfclMN0cMohT6kVuarSfskyZPa6Dre94Gbsf9HdM x4lQ9b7hIA83iMs+SxOfG3NyicUE8lH+R/BNx6U/UdK+cb1sZCU2gmwGo/M385/YWhZGrlrSX Mc0TzSuJmU6gaDFumwc8mtA5BKs2v/DNTwLsFDTIRSk877uQG7DlAB6WJHcHoMYf6w== Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 21:57:47 -0000 On 2017-01-07 22:44, John C Klensin wrote: > Julian, > > My belief is that these issues have already been dealt with in > -19 or earlier. If you disagree and consider the issues > substantive enough to meet the criteria Barry laid out, please > explain. Some comments below. Well, I checked -19 before sending the mail. Feedback is feedback. > --On Saturday, January 7, 2017 18:42 +0100 Julian Reschke > wrote: > >> Reviewing my own feedback from 7 months ago and reposting >> those parts that still seem to apply...: >> >> On 2016-04-27 20:11, Julian Reschke wrote: >>> >>> rq-components = ( "?=" q-component >>> [ "?+" r-component ] ) / >>> ( "?+" r-component >>> [ "?=" q-component ] ) >>> q-component = pchar *( pchar / "/" / "?" ) >>> r-component = pchar *( pchar / "/" / "?" ) >>> f-component = fragment >>> >>> These come as a surprise to anybody not already familiar to >>> what led to the spec. > >>> Either introduce them later, or insert some prose explaining >>> where they come from. > > The paragraph immediately above the syntax in Section 2 ("The > basic syntax for a URN is defined...") now contains explicit > forward pointers to the relevant defining sections. If you > think more is needed, please explain and propose text. Whether > one soul supply syntax before or after the explanation of what > the elements are about is a matter of taste; when I've done it > one way in a proposed RFC, I'm been attached and when I've done > it the other way, I've been attacked too, so, speaking > personally and as co-editor, I'm no longer interested in the > discussion. It probably would be sufficient to move the overview in front of the ABNF. > ... >>> ... >>> For the sake of consistency with RFC 3986, neither the >>> general syntax nor the semantics of q-components are >>> defined by, or dependent on, the namespace of the URN. In >>> parallel with RFC 3896, specifics of syntax and semantics, >>> e.g., which keywords or terms are meaningful, of course >>> may depend on a particular namespace or even a particular >>> resource. >>> >>> I agree that this is the right thing to do, but I'm not sure >>> what this has to do with 3986. 3986 allows a scheme to >>> mandate a specific syntax, no? > > Yes, at least as I read it. But, IIR, there have been some > claims that 3986 does not obviously allow a scheme to delegate > the syntax to other (non-scheme) parts of the URI (specifically > a namespace in the urn scheme case). At this point, I would > personally prefer sentences to the effect of "no matter what you > think 3986 says, URNs works this way...", but I don't think that > a proposal like that would be constructive or helpful. If you > think this is important and want to propose alternate text, > please do so. > ... So we agree on what RFC 3986 says :-). I think the right conclusion is to strip the prose wrt RFC 3986. Just say: "Neither the general syntax nor the semantics of q-components are defined by, or dependent on, the namespace of the URN. Specifics of syntax and semantics, e.g., which keywords or terms are meaningful, of course may depend on a particular namespace or even a particular resource." >>> ... >>> For the sake of consistency with RFC 3986, neither the >>> general syntax nor the semantics of f-components are >>> defined by, or dependent on, the namespace of the URN. In >>> parallel with RFC 3896, specifics of syntax and semantics, >>> e.g., which keywords or terms are meaningful, of course >>> may depend on a particular namespace or even a particular >>> resource. >>> >>> s/3896/3986/ > > I thought we had caught all of those. Both remaining cases, now > corrected in the working draft of -20 (which, unless major > issues show up or Barry directs otherwise, will appear only > after the informal WG Last Call ends at the end of the month). > FWIW, even though it is clearly better to fix it now, this is > the sort of thing the RFC Editor is really good at catching and > fixing. ...I prefer to process documents with known problems fixed. That said, there's an IETF LC before that anyway, so whatever the WG submits after WG LC is very unlikely what gets to the RFC Editor anyway. Best regards, Julian From nobody Sat Jan 7 22:41:55 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AD41294A9 for ; Sat, 7 Jan 2017 22:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 OAv1WJaC7AjU for ; Sat, 7 Jan 2017 22:41:52 -0800 (PST) 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 AB8631279EB for ; Sat, 7 Jan 2017 22:41:52 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cQ7Ar-000K1g-MS; Sun, 08 Jan 2017 01:41:49 -0500 Date: Sun, 08 Jan 2017 01:41:43 -0500 From: John C Klensin To: Julian Reschke Message-ID: <5463EBE376D888656975178E@PSB> In-Reply-To: References: <20022D35B6F9EC84EF0C7901@PSB> 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.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 06:41:54 -0000 --On Saturday, January 7, 2017 22:57 +0100 Julian Reschke wrote: > On 2017-01-07 22:44, John C Klensin wrote: >> Julian, >> >> My belief is that these issues have already been dealt with in >> -19 or earlier. If you disagree and consider the issues >> substantive enough to meet the criteria Barry laid out, please >> explain. Some comments below. > > Well, I checked -19 before sending the mail. Feedback is > feedback. Just my opinion: See Barry's note. The difficulty with "feedback is feedback" is that we can quibble endlessly about small matters of phrasing, organization, etc., and that, if we are ever going to finish this work, that needs to stop at some point. I'll leave determining the point up to the co-chairs but, again in my opinion, we are past it. >> --On Saturday, January 7, 2017 18:42 +0100 Julian Reschke >> wrote: >> >>> Reviewing my own feedback from 7 months ago and reposting >>> those parts that still seem to apply...: >>> >>> On 2016-04-27 20:11, Julian Reschke wrote: >>>> >>>> rq-components = ( "?=" q-component >>>> [ "?+" r-component ] ) / >>>> ( "?+" r-component >>>> [ "?=" q-component ] ) >>>> q-component = pchar *( pchar / "/" / "?" ) >>>> r-component = pchar *( pchar / "/" / "?" ) >>>> f-component = fragment >>>> >>>> These come as a surprise to anybody not already familiar to >>>> what led to the spec. >> >>>> Either introduce them later, or insert some prose explaining >>>> where they come from. >> >> The paragraph immediately above the syntax in Section 2 ("The >> basic syntax for a URN is defined...") now contains explicit >> forward pointers to the relevant defining sections. If you >> think more is needed, please explain and propose text. >> Whether one soul supply syntax before or after the >> explanation of what the elements are about is a matter of >> taste; when I've done it one way in a proposed RFC, I'm been >> attached and when I've done it the other way, I've been >> attacked too, so, speaking personally and as co-editor, I'm >> no longer interested in the discussion. > > It probably would be sufficient to move the overview in front > of the ABNF. See above. Barry? >> ... >>>> ... >>>> For the sake of consistency with RFC 3986, neither the >>>> general syntax nor the semantics of q-components are >>>> defined by, or dependent on, the namespace of the URN. >>>> In parallel with RFC 3896, specifics of syntax and >>>> semantics, e.g., which keywords or terms are meaningful, >>>> of course may depend on a particular namespace or even a >>>> particular resource. >>>> >>>> I agree that this is the right thing to do, but I'm not sure >>>> what this has to do with 3986. 3986 allows a scheme to >>>> mandate a specific syntax, no? >> >> Yes, at least as I read it. But, IIR, there have been some >> claims that 3986 does not obviously allow a scheme to delegate >> the syntax to other (non-scheme) parts of the URI >> (specifically a namespace in the urn scheme case). At this >> point, I would personally prefer sentences to the effect of >> "no matter what you think 3986 says, URNs works this way...", >> but I don't think that a proposal like that would be >> constructive or helpful. If you think this is important and >> want to propose alternate text, please do so. >> ... > > So we agree on what RFC 3986 says :-). I don't know if we do or not. Some things I know are that I've spent too many weeks of my life reading and rereading 3986, trying to understand how it bears and should bear on URNs and that the WG has spent years circling around the issue. Another thing I know is that 3986 is quire clear that it updates and replaces some URL documents and that, while it includes some sentences about URNs, it does not identify itself as updating or replacing RFC 2141 or, for that matter, 3406 or any other URN-specific document. Since the WG has no mandate or authority to update or otherwise modify or clarify 3986, it is equally or more reasonable that it start from prior URN materials as a basis as it is that it treat 3986 as definitive. > I think the right > conclusion is to strip the prose wrt RFC 3986. Just say: > > "Neither the general syntax nor the semantics of q-components > are > defined by, or dependent on, the namespace of the URN. > Specifics of syntax and semantics, e.g., which keywords or > terms are meaningful, of course may depend on a particular > namespace or even a particular > resource." I think that change is probably harmless, but would like to hear from others before I make the change. In particular, in either version, whether the sentence(s) are meaningful at all depends on the distinction between what are "general syntax" and "[general ?] semantics" versus "specifics of syntax and semantics". The previous form tied that distinction to 3986, even though it is not clear to me that it made the distinction clear either. Perhaps it is just late at night but, with the 3986 references removed, I just don't see a clear boundary. >>>> ... >>>> For the sake of consistency with RFC 3986, neither the >>>> general syntax nor the semantics of f-components are >>>> defined by, or dependent on, the namespace of the URN. >>>> In parallel with RFC 3896, specifics of syntax and >>>> semantics, e.g., which keywords or terms are meaningful, >>>> of course may depend on a particular namespace or even a >>>> particular resource. >>>> >>>> s/3896/3986/ >> >> I thought we had caught all of those. Both remaining cases, >> now corrected in the working draft of -20 (which, unless major >> issues show up or Barry directs otherwise, will appear only >> after the informal WG Last Call ends at the end of the month). >> FWIW, even though it is clearly better to fix it now, this is >> the sort of thing the RFC Editor is really good at catching >> and fixing. > ...I prefer to process documents with known problems fixed. So do I, which is why the fix has been applied. I was just trying to suggest that, had this fallen through the cracks, it almost certainly would have been caught in final editing. > That said, there's an IETF LC before that anyway, so whatever > the WG submits after WG LC is very unlikely what gets to the > RFC Editor anyway. If that implies that you expect a complete rewrite as the result of IETF LC, noted. best, john From nobody Sat Jan 7 23:28:57 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D7D127A91 for ; Sat, 7 Jan 2017 23:28:56 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JOMBx7LCfvG7 for ; Sat, 7 Jan 2017 23:28:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C777E126BF6 for ; Sat, 7 Jan 2017 23:28:54 -0800 (PST) Received: from [192.168.178.20] ([93.217.91.126]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MVJze-1bz5Oh0O4c-00Yl4F; Sun, 08 Jan 2017 08:28:41 +0100 To: John C Klensin References: <20022D35B6F9EC84EF0C7901@PSB> <5463EBE376D888656975178E@PSB> From: Julian Reschke Message-ID: <987d269d-1c8e-5d54-18e8-3f89e551d1e4@gmx.de> Date: Sun, 8 Jan 2017 08:28:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <5463EBE376D888656975178E@PSB> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:av1XLxvjpUQ5xezBIRJp5AHEaaVfEaDr3vQ8di7fJDTbmYGyz0M 7EMaMYylSWtlAVAcvUOtLCJPAVSmuz9KI6FYrrGaJ6GUnlVYLpVNxsEjtb+5YZh+W0BN17u fKMEF1cixLYv4b7LHe8iEGzq1NQph9Bd7l0foqXHcVw1hxdZzRcMBKxxtgf/BT+2l0wi7Gd XlkCSJmng6Fh61tdmqSZg== X-UI-Out-Filterresults: notjunk:1;V01:K0:qF2rKJk7JUU=:byXTBn7oObVABz7TKaLys6 oZc6IxUQBmSV6GHzejZOydsOlY8UvjO2zjbVPBds4srbEAhRM366IsOH6wVSBPLf6/RYPMRFa r3p7+DSXy4sjPrhuN1rTWmbtWj3JsZ7a3et1QWQtbSrgjVUslh8MTDu6VHqC0OFNCBt2ymi2+ pcD+1F3soR8NtGUDLTl1wa6+ih09lwGIzhIHx7Mm7xddYb9W1xWSQteOLuYCojdLBf1In/m7h 9GtpR3cT+H3peElAo19UpxPeionYgN7Rj16jFE/zymSQxnqILfRbioP8cTEBNc2i2mm70XxXM wT9IF/vuneuEPANsmcpUSB6lsuw416S+U+Kb2PWkWJlnfVdVLm1ZokWp6PX9JHbmO6o8kzAbW 3MxqY44tmRiw4pn5hNPEFHbUZ8Oouw/9Ci6mFQCwazqNIpqM73ZdFgw2GtPVs10ykR7pFAG2k kDLw3UMrv1U7LVNaBHZfDvZv5bcjr3ddNgoosHVfj92J+SfZ/MDeJskKeqRhA5Wk2cDzq43OE aPdFH/3JtmfdWmmU/J+zDckpw0qLhuIbDcEAhfSgY3GOFTIjRGAnOFmDYPpqiM4ZQq+4SB39E BI2ggPPM958cbTLEaPFa/ofVSQTC//fMcelaLG6Qbbg2JJd65MgrZk4hJXYFB4rxYDdjdYBYk wk6P5oDSTTv5mGTQf4hdAUepiVoMXv5Wp3Czretbbr8I27abi0uqDOc5eYBeuKxo1j5XxUTmI Ml6O4ot6YL4IsCChgy8dNyh+6pQvCi29khjANPsWairvfJFjcyIurBQDe/99FpeYiuu3Cy9ld JX7jRG88Z2qqMTtKkow9t0F3bSckTfT6Qt2vT55vSAd15gz4Z1S2rw3CvrxeHLmYVfIMc0g8F Yo706hSblLDunjiRPn+XKde4Z+ZOx8rWi5rtWt8brk9F3qcVqVvELFMa+cYiXJAx4kPRdMTeY B32zXvzD3fegd1RZuRIzcswxEbmEH/nYv/F3UQ2VYQO6H3gZZn09080kcvCiRnU0K07ucx7zu +LBkCuEuPynykWXSyp+6ab0= Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 07:28:56 -0000 On 2017-01-08 07:41, John C Klensin wrote: > ... > If that implies that you expect a complete rewrite as the result > of IETF LC, noted. > ... No, I don't expect that, nor do I think it's needed. What I said is we'll very likely have one more draft after WGLC and one more after IETF LC and IESG discussions. Best regards, Julian From nobody Mon Jan 9 22:28:39 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC66129F72 for ; Mon, 9 Jan 2017 22:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 oRe2Ir9VseHC for ; Mon, 9 Jan 2017 22:28:34 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10101.outbound.protection.outlook.com [40.107.1.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733BC129F6D for ; Mon, 9 Jan 2017 22:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=i2mbUOpQONpN86nguEQbhdB/YEXwmMwnyqanGNGpo3Q=; b=Oaq8+H5D84wTKv18ADGJIrGbzkSnceEit6gqbdfMj8bc4uUdyoiesEbp097PgTCd20Gf8AeWs4TSYu5/Zw3WmNkwVZA58hWYBts8RowVHki+iLZsnIUncnN4xwMkavlXlugqNDqE1qrZniK+0G+pk/vE0CD8infqfIJo7/8Ky+M= Received: from HE1PR0701MB2603.eurprd07.prod.outlook.com (10.168.187.138) by HE1PR0701MB2601.eurprd07.prod.outlook.com (10.168.187.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.6; Tue, 10 Jan 2017 06:28:29 +0000 Received: from HE1PR0701MB2603.eurprd07.prod.outlook.com ([10.168.187.138]) by HE1PR0701MB2603.eurprd07.prod.outlook.com ([10.168.187.138]) with mapi id 15.01.0845.010; Tue, 10 Jan 2017 06:28:29 +0000 From: "Hakala, Juha E" To: Julian Reschke , John C Klensin Thread-Topic: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 Thread-Index: AQHSaQ2MVPUHHgmpCkarsNsHeFgvoKEtjHGAgAADiwCAA66WQA== Date: Tue, 10 Jan 2017 06:28:29 +0000 Message-ID: References: <20022D35B6F9EC84EF0C7901@PSB> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-ms-office365-filtering-correlation-id: 589784b5-0c44-4d09-ea35-08d43921e49a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2601; x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2601; 7:zxGbwnVaASC5qW1x0WT+KltCQWTs375x6e9856F9k5IVc1+1ks2jXKgGQovXcgAUboDwE5ddQ8hc0hYd7H9cC7wxt696MR2MpEG67xpbIcfZToR2P4l0i/Squa38xJkZbb63kbMRzBi/Adrer/oocyvP/nCdtjt5m5nI1DYFjp8ZXZG8+gPVkQqvB7cSi3QJi0H4344LiZTcVYqpdpWDRpwYxI+jlCe1s4N0YeRw3nvaMUl1LMGTVNxEW6Du4lyQvwyx7T7cA4A/eq/BK46UGfFjuWj/PZdBYVJ60M2Y0VfH14uz+CffaoUBilAJ5+T/9j5OPkHNipZQjmXPmZflT5X7fyFetfySAhO4rz7qFONlUHvVY8GUmD5MV+f8Pi+ltVar6WCmxFDWTrxjG6SwzxzWObfcz3SB+Y6HK2E6fhOzIJfMFozgUHujsP41ZwCB2j5VXUEjX3+Eq1cUjKj0BA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:HE1PR0701MB2601; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2601; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(52314003)(13464003)(24454002)(377424004)(199003)(189002)(76104003)(105586002)(66066001)(189998001)(3846002)(106116001)(38730400001)(81166006)(7696004)(97736004)(93886004)(230783001)(5660300001)(106356001)(561944003)(86362001)(229853002)(122556002)(5001770100001)(8676002)(2906002)(102836003)(8936002)(92566002)(33656002)(101416001)(74482002)(2950100002)(6116002)(81156014)(2900100001)(31430400001)(6506006)(4326007)(25786008)(50986999)(9686003)(3660700001)(54356999)(6306002)(55016002)(99286003)(74316002)(8666007)(3280700002)(7736002)(77096006)(305945005)(6436002)(68736007)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2601; H:HE1PR0701MB2603.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 06:28:29.6452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2601 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 06:28:37 -0000 Hello,=20 A comment below.=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Julian Reschke > Sent: 7. tammikuuta 2017 23:58 > To: John C Klensin > Cc: urn@ietf.org > Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 >=20 > On 2017-01-07 22:44, John C Klensin wrote: > > Yes, at least as I read it. But, IIR, there have been some > > claims that 3986 does not obviously allow a scheme to delegate the > > syntax to other (non-scheme) parts of the URI (specifically > > a namespace in the urn scheme case). At this point, I would > > personally prefer sentences to the effect of "no matter what you think > > 3986 says, URNs works this way...", but I don't think that > > a proposal like that would be constructive or helpful. If you > > think this is important and want to propose alternate text, please do > > so. > > ... >=20 > So we agree on what RFC 3986 says :-). I think the right conclusion is to= strip > the prose wrt RFC 3986. Just say: >=20 > "Neither the general syntax nor the semantics of q-components are defined > by, or dependent on, the namespace of the URN. Specifics of syntax and > semantics, e.g., which keywords or terms are meaningful, of course may > depend on a particular namespace or even a particular resource." Yes, different namespaces definitely support different resolution services.= In the ISSN namespace it is possible to request metadata about the identif= ied periodical, or locations from which it can be found. But it is usually = not possible to request all volumes and issues of a periodical. Identified resources also have an impact on resolution services. Dublin Cor= e metadata record as an identified resource allows some services (including= migration to another metadata format), large research datasets some others= , such as extraction of selected variables.=20 One aspect which is missing from Julian's suggestion above is that applicat= ions with which we manage resources also support different services. There = are certain things an integrated library system can do for an electronic bo= ok, and then some other services only a digital preservation system can sup= ply for the same book. Taken together, the different system with which orga= nizations manage their digital collections will support a wide variety of s= ervices which can be requested using q- and r-components. Syntax and semant= ics of these components will evolve over time to reflect new functionalitie= s supported by digital asset management systems in production. =20 Juha > >>> ... > >>> For the sake of consistency with RFC 3986, neither the > >>> general syntax nor the semantics of f-components are > >>> defined by, or dependent on, the namespace of the URN. In > >>> parallel with RFC 3896, specifics of syntax and semantics, > >>> e.g., which keywords or terms are meaningful, of course > >>> may depend on a particular namespace or even a particular > >>> resource. > >>> > >>> s/3896/3986/ > > > > I thought we had caught all of those. Both remaining cases, now > > corrected in the working draft of -20 (which, unless major issues show > > up or Barry directs otherwise, will appear only after the informal WG > > Last Call ends at the end of the month). > > FWIW, even though it is clearly better to fix it now, this is the sort > > of thing the RFC Editor is really good at catching and fixing. >=20 > ...I prefer to process documents with known problems fixed. That said, > there's an IETF LC before that anyway, so whatever the WG submits after > WG LC is very unlikely what gets to the RFC Editor anyway. >=20 > Best regards, Julian >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Mon Jan 9 23:12:19 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8565129AF2 for ; Mon, 9 Jan 2017 23:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0AvW_NpDoykz for ; Mon, 9 Jan 2017 23:12:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13980129AE7 for ; Mon, 9 Jan 2017 23:12:15 -0800 (PST) Received: from [192.168.178.20] ([93.217.125.108]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MTMzb-1c0HaY1YSV-00SST0; Tue, 10 Jan 2017 08:11:53 +0100 To: "Hakala, Juha E" , John C Klensin References: <20022D35B6F9EC84EF0C7901@PSB> From: Julian Reschke Message-ID: <5f7d9cd6-9430-2222-f652-1547d3ad33ac@gmx.de> Date: Tue, 10 Jan 2017 08:11:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:xCZXRdIrFJadQQUm1XVMJSa1O8Y+6o9U25soWhWVkrPAQ/lJULB LlVUprNFa0X2sl/5XSIKEssrLmAh2aap4dvkSUsCI25spuuvqMIh8+yB/RdAsXijJWzqzAz ZN68BvmgufDnUUfKVnjnXcGkHjbJwplON35dWolpeTUf0ZRa3hem5LW25N8+wp2o0ECyKZX 87vAw/QeTE5y2yBeWA3Yw== X-UI-Out-Filterresults: notjunk:1;V01:K0:hxNQw4taoBc=:1V8NcfwrR47MrTdv99TSgE skjXGkmgXZWrXcJFlTlFs5YUBKRn7IX9Ih06HQqjI6aZQ4bRbWgeSflm6eeEJdHCK4oMNO5sB PvToDG/xjX3Xfwt+hSjkepcrwJxRH7YhbGUNMPh8upGnKwlPcLPFXBwzXwHVdFU1eGRPCXIaq PkWiEfkDmzyfqNP7UtX3FXBs6oYMK9FlhgZQ+4Cm/dDmij36Bl8uRa6Bvi5hgicR5p/6iI/IX 1HuffBVnW1TME1ia+Sly7NPMjX9O0XWOEr0+8/yCW15SXnuMS4u8jPdlkhCkvPoVqvscy9JtF EshFBlWfr+BxxJhShy7nMIQhVOxz1wsThmEtm7uB/eJLhwfprG6RpGYvN825AsSBgX6LJrxwz 2O3mRp9LSxPOrTuLvpKVroOIZvHAx/HZ5favTzFr1y2B9Nh07qecjrkcSNMT2NSVHlRPCHfw4 8YTKaT+XNBicilN/flnNq4R59NUz1i7ZAP4AiAXjv2ifuP0+H5T+IeCFQ9TH97m9E60WD2utb r59sXmvJC44dHDKc0dXEJ8nhKQcROBr5tWLUyDJ8tSz6I7mczjXA+CQE3e08L6jb2nTrF8hZG gC3hNDThLR/pU4ADJXLIBkJ2geD283K1DpRCC2bu/qPma0p7EWYJwUFWK4BZMWFaWiuFmYvqV wlb1x0RQi4CNWJhR9iziMegZbZKcs8dIisSw71gPWcI1gZ+rV2okqOUR1kkPnzzoFYzcdKrQz BpTgpd2CqCAjRfeLcpTMpYCMR4LhO1irhHZij6W0IRhtQIjy+pQSd7jeOypLR2g7vxLyQp0W1 r8knRzm Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 07:12:18 -0000 On 2017-01-10 07:28, Hakala, Juha E wrote: > ... > Yes, different namespaces definitely support different resolution services. In the ISSN namespace it is possible to request metadata about the identified periodical, or locations from which it can be found. But it is usually not possible to request all volumes and issues of a periodical. > > Identified resources also have an impact on resolution services. Dublin Core metadata record as an identified resource allows some services (including migration to another metadata format), large research datasets some others, such as extraction of selected variables. > > One aspect which is missing from Julian's suggestion above is that applications with which we manage resources also support different services. There are certain things an integrated library system can do for an electronic book, and then some other services only a digital preservation system can supply for the same book. Taken together, the different system with which organizations manage their digital collections will support a wide variety of services which can be requested using q- and r-components. Syntax and semantics of these components will evolve over time to reflect new functionalities supported by digital asset management systems in production. > ... My proposal was just to remove the (IMHO) confusing and unnecessary mention of RFC 3986... Yes, there may be other things to change -- this is why we're doing a Last Call, right? Best regards, Julian From nobody Wed Jan 11 00:42:22 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22797129A8A for ; Wed, 11 Jan 2017 00:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 m-Wlo1HZ_-8l for ; Wed, 11 Jan 2017 00:42:16 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (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 935B51294A9 for ; Wed, 11 Jan 2017 00:42:16 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id 2F7164455D08; Wed, 11 Jan 2017 09:42:14 +0100 (CET) X-AuditID: 0a453fe7-171ff70000000f1b-68-5875efe2bd8a Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id F0.B7.03867.2EFE5785; Wed, 11 Jan 2017 09:42:13 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 11 Jan 2017 09:42:09 +0100 From: "Svensson, Lars" To: Julian Reschke Thread-Topic: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 Thread-Index: AQHSaQ2diiw30zGR+kafTGD0ekYhHqEte62AgAADiwCABWrnkA== Date: Wed, 11 Jan 2017 08:42:08 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2ACF68@dnbf-ex1.AD.DDB.DE> References: <20022D35B6F9EC84EF0C7901@PSB> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.193] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA11Tb0gTcRjut930nP7snM79Whl5Yh+sTCFEIlTMwDQqKmpJpWe7tuX8024T F1Gi+aGBQ8PAP5hZyw+ipQb9N3Ra2h8sBCsUNTHNqaUJTvpi3e1OO/323vM+z/M+7+/lcKli zFuNG3LMtCmHMpJeckx+IH5x18ScRRM10RkR+2hsVhZ7q3hekiBJnv99Ltnh+CM5KkmT79PS RkM+bdodlyHXF3feBXlNioJa97h3IWj1twEfHBF7UFPpDZkNyHEF0QVQf00Dxn88Aajb3gds wBv3IiLQnJ7jB7HV0Eg74GopEYraRiskXB1IJKIhe62M5+xHY42NgK8T0UN3jRdXY0Q4Gugt 9uCQSEWTZR3CqKcAjX5d8hj5EHtRTVGvxwgQIail5aOUH6ZCbZNLMj40gRwveRwRSuQaXxbw bajsusub50ehub46QbsDNdTPSPnBAeht1XesDCirRbbVIkm1SFItktwBWCPwZ7J10ZGUNlKr zYzU0m2Av8WPp8Den+QEBA5IP0jPmjUKGZXPWLOd4AguIZXww4xFo/DPzNVa9RSjTzdZjDRD BkH3KMuEq3CmxZhFboWPXSxZtYoyFibPcN6Qa2HSLSajEyBcykobplkS1FLWy7Qplzd0gs04 Rqqg69UGjYLQUWY6i6bzaNNKV4PjJIJdP1lhgInW0QUXDEbzSpvVPZ9iO4S44wkUCuO59Gpx Y30mCe7jBIdwPzZY0S8uGJNHZTMGneAdCCsdLOq3gnp8Q+Awt2jwCrjW8x04rlbBKi4swTH0 lpzVrOpgiLWyL7dR1OAs1dtgRxKjUWwS4Wtdp8FB9kSB8AHn68f+Uf8zKqCNS+4rgJ6IW+A3 LqJSwNZ7HWJvGwRPxzHcwmbKLF74vsuzsIAKC5dPexYWwLV26kKA5Z/NvHJT6ivJdXd+9s8O sn7qf2M/+8LLHu5uRsrytp33rCmve9QzYT3hhzPIsYoF1VGf2tb6EmxKc7U9zTGo77ttkx2O qbxEdqekgcHUlmvypOljk3GJ9ZNhlQt1aEZ+8dng4vaYkhHdculUoSFrIP5LwonmpeGTfxdO nXlfR2KMnoqOkJoY6h9tqnkqdAQAAA== Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 08:42:21 -0000 Julian, all On Saturday, January 07, 2017 10:58 PM, urn [mailto:urn-bounces@ietf.org] O= n Behalf Of Julian Reschke wrote: > >>> For the sake of consistency with RFC 3986, neither the > >>> general syntax nor the semantics of q-components are > >>> defined by, or dependent on, the namespace of the URN. In > >>> parallel with RFC 3896, specifics of syntax and semantics, > >>> e.g., which keywords or terms are meaningful, of course > >>> may depend on a particular namespace or even a particular > >>> resource. > >>> > >>> I agree that this is the right thing to do, but I'm not sure > >>> what this has to do with 3986. 3986 allows a scheme to > >>> mandate a specific syntax, no? > > > > Yes, at least as I read it. But, IIR, there have been some > > claims that 3986 does not obviously allow a scheme to delegate > > the syntax to other (non-scheme) parts of the URI (specifically > > a namespace in the urn scheme case). At this point, I would > > personally prefer sentences to the effect of "no matter what you > > think 3986 says, URNs works this way...", but I don't think that > > a proposal like that would be constructive or helpful. If you > > think this is important and want to propose alternate text, > > please do so. > > ... >=20 > So we agree on what RFC 3986 says :-). I think the right conclusion is > to strip the prose wrt RFC 3986. Just say: >=20 > "Neither the general syntax nor the semantics of q-components are > defined by, or dependent on, the namespace of the URN. Specifics of > syntax and semantics, e.g., which keywords or terms are meaningful, of > course may depend on a particular namespace or even a particular > resource." Since the q-component is always passed directly to the resource representat= ion returned by the URN resolver, I'd say that any syntactical and semantic= constraints of the q-component depends _entirely_ on that resource represe= ntation. My suggestion would be to strip references to the URN namespace, t= oo: [[ Neither the general syntax, nor the semantics of q-components are defined o= r dependent on the namespace of the URN. Specifics of syntax and semantics,= e. g., which keywords or terms are meaningful, depend entirely on the part= icular resource representation. ]] Best, Lars=20