From nobody Sun Sep 4 14:44:06 2016 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 4DC7D12B0B4 for ; Sun, 4 Sep 2016 14:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, 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 PWaAEJQWq8M9 for ; Sun, 4 Sep 2016 14:44:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DA6BD12B012 for ; Sun, 4 Sep 2016 14:44:02 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8CF76F0793; Sun, 4 Sep 2016 15:44:13 -0600 (MDT) To: "urn@ietf.org" From: Peter Saint-Andre Message-ID: <63bd7757-6e7d-c893-4c10-9196269ad097@stpeter.im> Date: Sun, 4 Sep 2016 15:44:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Julian Reschke Subject: [urn] text on URN relative resolution in Section 4.3 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, 04 Sep 2016 21:44:04 -0000 During the interim meeting on 2016-06-29 (around the 25 minute mark of the recording), Julian raised a concern that the URNbis specification says that relative resolution is done by first resolving the URN and only then doing the relative resolution if possible. A discussion of around 15 minutes in length ensued. Specifically, Henry raised a concern about the text that was added between versions 11 and 12: https://tools.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-12.txt That text currently reads as follows: ### 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 components" of the target of that reference, which can then be recomposed per RFC 3986 Section 5.3 into a target URI. This algorithm cannot be applied directly to URNs because their syntax does not support the necessary path components. Whenever a URN resolves to a URL which may be used to access the resource, there is a more specific interpretation of q-component and f-component: the q-component is copied verbatim to the query portion of the URL (if that URL scheme supports query), and the f-component is copied verbatim to the fragment portion of the URL. Even though the notion of a URN as a "persistent", "permanent" identifier does not reconcile easily with relative referencing, resources named with URNs may contain relative references that do not apply to the URN itself. Given the foregoing, a relative reference SHOULD NOT be evaluated directly with respect to a URN. Instead, a relative reference SHOULD be evaluated indirectly with respect to one of the following: 1. a base URI (other than a URN) declared by the resource itself; or 2. a base URI (other than a URN) obtained through the URN resolution process; or 3. the URL of the resource as obtained through the URN resolution process (Case 2 permits the resolution process to explicitly supply a base URI if the resource content is supplied directly by the resolution service rather than via an intermediate "location" URI.) If no such base URI exists, use of a relative reference with respect to a URN is an error. Client behavior in this case is undefined. Resolution services SHOULD ensure that a base URI is supplied any time they provide resource content directly to a client. ### John said that he thought he saw a way to fix it, but I'm not sure what that was, so I'll leave that aspect of the text fixes for -18 to him. Peter From nobody Mon Sep 5 19:30:22 2016 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 77754128E19; Mon, 5 Sep 2016 19:30:16 -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.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147312901648.3121.16573915781832438280.idtracker@ietfa.amsl.com> Date: Mon, 05 Sep 2016 19:30:16 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-18.txt 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: Tue, 06 Sep 2016 02:30:16 -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 of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-18.txt Pages : 40 Date : 2016-09-05 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-18 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 Sep 5 19:31:07 2016 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 CAE9612B0C8 for ; Mon, 5 Sep 2016 19:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, 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 T4JXMxmoQTVL for ; Mon, 5 Sep 2016 19:31:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A9FC312B0C3 for ; Mon, 5 Sep 2016 19:31:04 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7B424416C3; Mon, 5 Sep 2016 20:31:20 -0600 (MDT) To: "urn@ietf.org" From: Peter Saint-Andre Message-ID: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> Date: Mon, 5 Sep 2016 20:31:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] version -18 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, 06 Sep 2016 02:31:06 -0000 First, my apologies (as the pen-holder) for taking so long to publish version -18 after the WG meeting in late June. Yesterday I finally found time to listen to the recording of that meeting and to address the issues discussed at that time. The only exception is the concern about relative resolution that Julian Reschke raised, which I posted about to the list yesterday. After thinking about it further, my feeling is that it would be very helpful for Julian (and perhaps Henry Thompson) to review the text again and to post to the list with a description of their concerns so that John and I can address them. And, as always, proposed text is welcome. Also, please note that, because of his many other responsibilities, John has not yet had time to review this version in detail (and I wanted to publish it sooner rather than later in the interest of making progress). All errors are mine, and feedback would be appreciated. Peter From nobody Mon Sep 5 22:25:01 2016 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 664B012B0DC for ; Mon, 5 Sep 2016 22:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=d4MX4jj/; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=d4MX4jj/ 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 RN87NRv7GWSl for ; Mon, 5 Sep 2016 22:24:57 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F2D12B0CE for ; Mon, 5 Sep 2016 22:24:57 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id 87E7115A0688; Tue, 6 Sep 2016 07:24:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1473139495; bh=7dCT8B74KF/DO5boPl35iyHjMqeL6aR7hOzECpT+VdU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=d4MX4jj/tXpiIhpqONdh6A3mRhi7Y/MTo5i2DWVXUImHFUPWppNhLDh9hZFm5mEEt ho1/tZ3VloHiFzoEJnixuGQdXsf3z2s1Dr/waemp1Kd9QCOrQ+cW2ohaEbOT7lbdBG Zcwg557GtRll5VPsDAvfLT2GPrSIsqKDgrTmKGvs= Received: from [192.168.178.20] (unknown [93.217.127.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id E287815A0484; Tue, 6 Sep 2016 07:24:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1473139495; bh=7dCT8B74KF/DO5boPl35iyHjMqeL6aR7hOzECpT+VdU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=d4MX4jj/tXpiIhpqONdh6A3mRhi7Y/MTo5i2DWVXUImHFUPWppNhLDh9hZFm5mEEt ho1/tZ3VloHiFzoEJnixuGQdXsf3z2s1Dr/waemp1Kd9QCOrQ+cW2ohaEbOT7lbdBG Zcwg557GtRll5VPsDAvfLT2GPrSIsqKDgrTmKGvs= To: Peter Saint-Andre , "urn@ietf.org" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: Julian Reschke Message-ID: Date: Tue, 6 Sep 2016 07:24:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] version -18 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, 06 Sep 2016 05:24:59 -0000 On 2016-09-06 04:31, Peter Saint-Andre wrote: > First, my apologies (as the pen-holder) for taking so long to publish > version -18 after the WG meeting in late June. > > Yesterday I finally found time to listen to the recording of that > meeting and to address the issues discussed at that time. > > The only exception is the concern about relative resolution that Julian > Reschke raised, which I posted about to the list yesterday. After > thinking about it further, my feeling is that it would be very helpful > for Julian (and perhaps Henry Thompson) to review the text again and to > post to the list with a description of their concerns so that John and I > can address them. And, as always, proposed text is welcome. ...the main concern is that it is indeed overriding RFC 3986, which, in the call, we decided wasn't necessary. Best regards, Julian From nobody Sun Sep 25 04:08:23 2016 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 6A67112B1BC for ; Sun, 25 Sep 2016 04:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, 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 sCJ_xsGJmIU1 for ; Sun, 25 Sep 2016 04:08:19 -0700 (PDT) Received: from seine.is.ed.ac.uk (seine.is.ed.ac.uk [129.215.17.202]) by ietfa.amsl.com (Postfix) with ESMTP id E975612B1B8 for ; Sun, 25 Sep 2016 04:08:18 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by seine.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id u8PB8FuC002481; Sun, 25 Sep 2016 12:08:16 +0100 Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id u8PB8FQ1002462; Sun, 25 Sep 2016 12:08:15 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u8PB8FZ4019821; Sun, 25 Sep 2016 12:08:15 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u8PB8DnH019820; Sun, 25 Sep 2016 12:08:13 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Sun, 25 Sep 2016 12:08:13 +0100 In-Reply-To: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> (Peter Saint-Andre's message of "Mon\, 5 Sep 2016 20\:31\:03 -0600") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at seine.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.17.202 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] version -18 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, 25 Sep 2016 11:08:22 -0000 Peter Saint-Andre writes: > The only exception is the concern about relative resolution that > Julian Reschke raised, which I posted about to the list > yesterday. After thinking about it further, my feeling is that it > would be very helpful for Julian (and perhaps Henry Thompson) to > review the text again and to post to the list with a description of > their concerns so that John and I can address them. And, as always, > proposed text is welcome. Here's an (overlong) attempt to be helpful here. *TL;DR* _Actually_, since we have kept URN syntax compatible with 3986, strictly speaking the 3986 syntactic approach to relative resolution works just fine with a URN as base URI, that is, does not trigger any error conditions; _But_ with two exceptions the result is unlikely to be a useful, or even valid, URN: Exception 1: The base URN's namespace is hierarchical in structure and its NSS syntax uses / to delimit steps in that hierarchy; Exception 2: The relative reference consists entirely of q- and/or f-components (r-components, no so sure); _However_ in practice the issue only arises when delivering a resource representation which includes one or more relative references in ways which identify themselves as such; _So_ section 4.3 [1] can and should be simplified to something like the above summary, followed by advice to resolvers that _deliver_ resource representations which may contain relative references to be sure to deliver them in such a way that the base URI _for that representation_ does use an appropriate hierarchical locator scheme, e.g. http: or https:. Below here are some lengthy discussions of supporting arguments for the above summary. *Background* The starting point for any consideration of relative references and the resolution thereof is an understanding of the circumstance in which questions arise. Yes, 3986 treats this in the abstract, but I'm going to go concrete in order to clarify some things. First point: Relative reference resolution is a _process_, carried out by some agent. Some reflection leads to a list of requirements which must be satisfied before this will happen: 1) We have to have a structured artefact (document/data structure/...) which 'has' a base URI; 2) We have to know something about the nature of that artefact which allows us to identify strings in it as being relative references. The most likely ways this can happen are a) We have a document accessed via some means, and that means itself lets us know both a base URI and a media type (the HTTP protocol is such a means). The media type in turn lets us identify parts of the document which are URIs, and 3986 lets us tell when those are relative references. The media type _may_ also tell us how parts of the document change the base URI for delimited regions therein; b) We have a structure (think e.g. JSON or SQL) which is either intrinically or extrinsically typed. Base URI information may come either extrinsically, or via the structure and its types, or an interaction between those and an agent's processing. That certain values in the structure are URIs can be assumed to be determined similarly. Even for those rare cases distinct from (a) and (b), it is _very_ likely that the _author_ of any artefact including strings intended to be understood/treated as relative references will have had such scenarios in mind. (Note that for URNs which are "abstract designators", no such scenarios can ever arise.) Second point: There are _lots_ of HTML or XML or RDF or JSON documents out there on the Web which have been authored with the expectation that they will be accessed via HTTP using an http: URI which in turn therefore will be the base URI during processing of that artefact, and thus that relative references in that document can be used to access e.g. siblings in the tree-structured information space in which the retrieved representation's resource can be assumed to be situated. The toolchains which support this on the receiving end are many and varied, and we _really_ don't want to include anything in urnbis which makes them suddently non-conformant. But this appears to put us in difficulties. If such documents are accessed via some URN resolution process, the last assumption above (about sibling access) would appear to be at risk, as resolving e.g. "../foo.html" against e.g. urn:isbn:0451450523 is unlikely to produce anything that will resolve at all (see below at *Algorithms*). But that of course is only true if the outcome of the resolution process identifies the base URI of the result as urn:isbn:0451450523. So don't do that. That is, resolvers should deliver resource representations with hierarchical locator URIs, not URNs, as their base URIs. *3985 Algorithm* First, the relevant section [1] begins with an assertion I find perplexing: 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 algorithm cannot be applied directly to URNs because their syntax does not support the necessary path components. Earlier in the draft there is a careful explanation that URN syntax as described is compatible with URI syntax as specificed in RFC 3986. As a result, the 3986 algorithms [2], [3] work just fine, albeit not perhaps in a way that's very useful. For example, if we take one of the example URNs from 2141bis as the base URI: urn:example:a123,z456 and a simple string as the relative reference xyzzy the algorithms proceed as follows: 1) Pre-parse the base: scheme: urn path: example:a123,z456 auth, query, frag: undefined 2) Transform references a) Parse: path: xyzzy scheme, auth, query, frag: undefined b) Merge paths: new path: xyzzy c) Copy query and fragment new query, fragment: undefined d) Reuse scheme, auth new scheme: urn new auth: undef 3) Recompose result: urn:xyzzy For URN namespaces which happen to use / as a separator, the 3986 algorithms will work as perhaps as expected in some cases, but not in others: urn:example:a123,z456/bar + baz --> urn:example:a123,z456/baz but urn:example:a123,z456/bar + /foo --> urn:/foo Behaviour in the presence of one or more '..' segments is left as an exercise for the reader. All of this may suggest that a minor edit saying "don't do this unless you are _very_ sure you know what you're doing" might seem to be all that's required. But there is a large set of cases where the right thing will happen and these are likely to be quite useful: that is, those where the reference consists entirely of the optional post-assigned-name part of the URN syntax. In these cases the r- and or q- components will override the base if present and the f-component will be copied over. ht [1] https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-18#section-4.3 [2] https://tools.ietf.org/html/rfc3986#section-5.2 -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Sun Sep 25 10:09:26 2016 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 C7926126FDC for ; Sun, 25 Sep 2016 10:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 rGH19yQp0vqq for ; Sun, 25 Sep 2016 10:09:22 -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 B690E1200DF for ; Sun, 25 Sep 2016 10:09:21 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1boCvU-0007Zh-KY; Sun, 25 Sep 2016 13:09:17 -0400 Date: Sun, 25 Sep 2016 13:09:11 -0400 From: John C Klensin To: "Henry S. Thompson" Message-ID: In-Reply-To: References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.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: Cc: urn@ietf.org Subject: Re: [urn] version -18 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, 25 Sep 2016 17:09:25 -0000 --On Sunday, September 25, 2016 12:08 +0100 "Henry S. Thompson" wrote: > Peter Saint-Andre writes: > >> The only exception is the concern about relative resolution >> that Julian Reschke raised, which I posted about to the list >> yesterday. After thinking about it further, my feeling is >> that it would be very helpful for Julian (and perhaps Henry >> Thompson) to review the text again and to post to the list >> with a description of their concerns so that John and I can >> address them. And, as always, proposed text is welcome. > > Here's an (overlong) attempt to be helpful here. >... Henry, Speaking as an individual contributor only (and as one who is, personally, quite frustrated with how long this and some closely related issues have preventing the WG from completing its work, driven people away, etc.), I'd like to suggest a different approach. This is strongly inspired by your summary, but even shorter and less prone to errors and misinterpretations. In addition to what is in your summary, I note that, if URNs are going to serve the function of a [very long term] stable identifier, a program or engine that processes a URN cannot, in the general case, know how a particular namespace will resolve or otherwise interpret that URNs at a particular time. The suggestion below was strongly stimulated by your note, especially by the section titled "*3985 Algorithm*" (sic). I believe, even more strongly than I did before, that saying more about relative references in 2141bis just gets us into more trouble and that we should say less, ideally almost nothing. Consequently, I suggest that we remove all of the present discussion of relative resolution from 2141bis and replace it with two statements, exact wording to be determined, but whose substance should be (the footnotes should probably not be part of the statement(s), but that is an editorial matter): (i) A system that encounters a [1] 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.[2] (ii) 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 self-contained, specifically including those that would require processing of . [3] [1] All terminology and definitions in these statements are references to 3986, presumably as it may be updated, replaced, or interpreted by some sort of consensus in the future. [2] Finding an appropriate Base URI is a 3986 problem, not a URN one. If such a Base URI cannot be found in an acceptably unambiguous way, that is a 3986 problem too. If the community concludes that more advice (or requirements) are required about edge or failure cases than 3986 provides, that is a 3986-bis or 3986 update matter, not a URN one. [3] A more succinct way of saying that is that using a relative reference with a URN is probably crazy behavior. Now, the effect of that approach is to take us back to where we should have been at the beginning: 3986 effectively says that relative references/URIs are a lexical matter, to be resolved by parsers that are not scheme-dependent. 2141bis should not be required to say more about them than, e.g., RFC 6068 ("Mailto") does and that is nothing. I'd suggest removing the section entirely except that I believe that the explicit warning should be given that use of relative references with URNs is likely to result in nonsense. _Anything_ more than the above, including your proposed paragraph or explanation, is likely to put us into the business of updating 3986, even if only updating it by additional explanation, or arguments about whether or not we are doing that... and, at least IMO, we just need to move on. In particular, I note that > advice to resolvers that _deliver_ > resource representations which may contain relative > references to be sure to deliver them in such a way that the > base URI _for that representation_ does use an appropriate > hierarchical locator scheme, e.g. http: or https:. is really advice for an improvement to 3986 because it is independent of whatever scheme might be associated with the resource representation and makes a scheme-independent (except by example) statement about appropriate base URIs. Even more strongly, your "First point" about the relative resolution process is, to me, an entirely worthy update and clarification to 3986. Your explanation under "*3985 Algorithm*" is hugely more clear than Section 5.2 of 3986 (although I agree they say just about the same thing). I suggest you turn one or both into an I-D and submit it as a 3986 update and clarification. best, john From nobody Sun Sep 25 16:42:12 2016 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 8466C12B047 for ; Sun, 25 Sep 2016 16:42:10 -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_HELO_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 llM628xqOLFx for ; Sun, 25 Sep 2016 16:42:08 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 565E812B040 for ; Sun, 25 Sep 2016 16:42:08 -0700 (PDT) Received: from [172.20.10.4] (unknown [70.197.89.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 96A0622E1FA for ; Sun, 25 Sep 2016 19:42:01 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <147312901648.3121.16573915781832438280.idtracker@ietfa.amsl.com> Date: Sun, 25 Sep 2016 16:41:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85949CB4-0C13-46FC-946E-34B03A1613C2@seantek.com> References: <147312901648.3121.16573915781832438280.idtracker@ietfa.amsl.com> To: urn@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-18.txt 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, 25 Sep 2016 23:42:10 -0000 Hello: I read through draft-18. Overall I do not have any negative feedback that requires blocking this = document. It=E2=80=99s been a long slog; I think this document is = getting very close to the next stage (i.e., last call, publishing, = shutting down WG). Thanks all for the hard work. *** r-component and q-components are now ordered: r first, then q. That is = great with me. Thanks for accepting the suggestion. Section 2.3.1 doesn=E2=80=99t specifically call out the parsing problems = associated with "?=3D" being not possible to put in r-component, because = it delimits the q-component; however, this is implicit in paragraph 3 = (=E2=80=9CThe r-component ends with a "?=3D" sequence (which begins a = q-component) or a "#" character (number sign, which begins an = f-component).=E2=80=9D I am okay with this. However, the ABNF should make this clear. Right now it says: r-component =3D pchar *( pchar / "/" / "?" )=09 But that is ambiguous with ?=3D . It should say: r-component =3D pchar *( pchar / "/=E2=80=9C / ("?" ( unreserved / pct-encoded / "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / ":" / "@" ) ) ) This is ? pchar without the =3D character. I still believe that it=E2=80=99s better to say that r-component is the = first ? , while q-component is the second ? , and simply say that r = component can=E2=80=99t contain ? . But I already raised that issue = repeatedly, and I acknowledge that there is some value in using ?X = syntax, simply because it opens the door to other delimiters such as ?- = ?! ?$ etc. (in which case, maybe it should just be "?" (unreserved / = pct-encoded), leaving out all of the delimiters ). *** I am fine with the technical result of URN-Equivalence (Section 3). = However, I find the wording to be quite convoluted. =46rom the specific = to the more general: =E2=80=9CTwo URNs are URN-equivalent if their portions = are octet-by-octet equal after applying case normalization (as specified in=20 Section 6.2.2.1 of [RFC3986]) to the following constructs:=E2=80=9D=20 Actually I think that Percent-Encoding Normalization is meant to be = referred to, possibly including case normalization to the pct-encoded = productions. Path Segment Normalization is not discussed (RFC 3986 6.2.2.3) but I = think this is an important issue since we are allowing / in the NSS. = Specifically what is: urn:foo:abc/def/ghi/.././jkl ? And is it URN-equivalent to: urn:foo:abc/def/jkl or not? And is it URN-equivalent to: urn:foo:abc/d%65f%2f/jk%6c ? Why or why not? The character encoding of the NSS is UTF-8, but this is not called out = in the URN-Equivalence part. Tell me: if the NSS includes %FF, is that = URN-equivalent to another one that includes %FF? 0xFF can never appear = in UTF-8 content. Therefore, it is not a valid URN, and cannot be equal = to another URN. But do we impose this on the equivalence algorithm or = not? It=E2=80=99s better to say one way or another. The text says to do an octet-by-octet comparison, but after normalizing = 3 different parts (plus several other implied parts, see above) in = differing ways. Why doesn=E2=80=99t the text just say: for a valid URN [implies UTF-8, implies conformance to ASCII-only, = etc.], compare the scheme case-insensitively, the NID = case-insensitively, and the NSS case-sensitively ? Etc. Can a namespace create a distinction between percent-encoded characters = and non-percent-encoded characters? RFC 3986 says it can=E2=80=99t for = the unreserved characters, such as %6c =3D l . But the current text = implies that it can (because it doesn=E2=80=99t say to do = percent-encoding normalization). In contrast, what about gen-delims such = as %2f =3D / and %3a =3D : , which can appear in both pct-encoded and = non-encoded forms? It appears that Unicode normalization issues/forms (NFC, NFD...) are not = specifically discussed in this document. I would like to see that issue = addressed by new registrations. Currently Section 6.4.2 merely hints at = it in parts 2, 3, and 4. I would like to see the repertoire of = characters be listed in the registration, along with the normalization = forms, if relevant. For example, if a URN namespace is based on some = French standard that allows =C3=A9, =C3=AA, etc., then there should be = some discussion about whether =C3=A9 is going to be U+00E9, U+0065 = U+0301, or something else. *** For similar nomenclature reasons, I am uncomfortable with the = distinction between =E2=80=9CURN=E2=80=9D and =E2=80=9Cassigned-name=E2=80= =9D. See Section 1.2 and the use throughout the document. Basically, = these two appear to be the same to me. What is the distinction? Also, both the abstract and Section 1 say: =E2=80=9CA Uniform Resource Name (URN) is a Uniform Resource Identifier = (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a = resource.=E2=80=9D=20 =E2=80=9CA Uniform Resource Name (URN) is a Uniform Resource Identifier = (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource.=E2=80=9D If a URN is a URI that is assigned under the =E2=80=9Curn=E2=80=9D = scheme=E2=80=A6then it would seem that a =E2=80=9CURN=E2=80=9D includes = the r, q, and f-components. Because = urn:foo:bar?+r-component?=3Dq-component#f-component is a URI. Therefore, = it is a URN. But I think an important distinction is trying to be made = between the NAME component, which is urn:NID:NSS, and the entire URI, = which includes r, q, and f. This distinction is muddled in the text. Regards, Sean PS I just read Henry Thompson=E2=80=99s feedback. It doesn=E2=80=99t = change my opinion of draft-18=E2=80=99s =E2=80=9Cdone-ness=E2=80=9D but = I want to respond to that separately. > On Sep 5, 2016, at 7:30 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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 of = the IETF. >=20 > Title : Uniform Resource Names (URNs) > Authors : Peter Saint-Andre > John C Klensin > Filename : draft-ietf-urnbis-rfc2141bis-urn-18.txt > Pages : 40 > Date : 2016-09-05 >=20 > Abstract: > A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) > that is assigned under the "urn" scheme and a particular URN > namespace, with the intent that the URN will be either a persistent, > location-independent resource identifier or in some cases an = abstract > designator that is persistent but that does not identify a resource. > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-18 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc2141bis-urn-18 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Sun Sep 25 17:17:44 2016 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 9549912B04D for ; Sun, 25 Sep 2016 17:17:43 -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_HELO_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 b5lvq0rP1xuO for ; Sun, 25 Sep 2016 17:17:41 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 9B5A812B040 for ; Sun, 25 Sep 2016 17:17:40 -0700 (PDT) Received: from [172.20.10.4] (unknown [70.197.89.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8F74A22E1F3; Sun, 25 Sep 2016 20:17:38 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Sun, 25 Sep 2016 17:17:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> To: "Henry S. Thompson" , "urn@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [urn] version -18 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: Mon, 26 Sep 2016 00:17:43 -0000 Hello URNies: Henry=E2=80=99s observations are all very interesting and such. It=E2=80=99= s a bit too much in the weeds for me. I only have the following points to add: * At this point, less is more. Say less, and URNBIS will do more (i.e., = people will actually start using it). More or less echoes John=E2=80=99s = observations. * There are many examples of permanent URI schemes that yield nonsense = when used as a base URI and combined with relative references. For = example, data: and mailto: . Short answer remains the best: =E2=80=9Cdon=E2= =80=99t do it.=E2=80=9D *How* you =E2=80=9Cdon=E2=80=99t do it=E2=80=9D = is left as an exercise for the reader. :) But my hint would be: =E2=80=9Cas much as you want to think of urn: as = the base URI for an HTML document, =E2=80=9Cdon=E2=80=99t do it.=E2=80=9D = Would you use data: or mailto: as the base URI for an HTML document? = =E2=80=9CDon=E2=80=99t do it.=E2=80=9D Figure out some way--ANY WAY--to = compute some other base URI for the subject that gives you trouble, and = use that. * . and .. have no meaning when / is not in the p-component (NSS), = noting that / is not part of NID anyway. Therefore, all this stuff about = relative references goes away when we prohibited / (the =E2=80=9Cold = way=E2=80=9D). The complications raised here suggest that keeping / = prohibited was a good choice with RFC 2141. Those who want to use / in = identifiers, could use %2f instead. I would characterize the =E2=80=9Cneed= =E2=80=9D to add / in URN strings as =E2=80=9Cdesperate=E2=80=9D. = Nothing=E2=80=99s wrong with : , and it doesn=E2=80=99t suffer from = these problems, by design. Maybe this ship has sailed. Just pointing out = the consequences. * The NSS in this draft corresponds to path-rootless. No matter what, = sufficient ../../=E2=80=A6 will knock out the NID. There is no way to = avoid this, unless we changed the way that NID works, to have it start = with //, in which case, it could be =E2=80=9Cprotected=E2=80=9D from = excessive ../../=E2=80=A6 . * I like Henry=E2=80=99s comment: > But there is a large set of cases where the right thing will happen = and > these are likely to be quite useful: that is, those where the = reference > consists entirely of the optional post-assigned-name part of the URN > syntax. In these cases the r- and or q- components will override the > base if present and the f-component will be copied over. To me, the case where this is useful is where the additional media = content is operatively associated with the URN, but using different = query data. Specifically, consider: urn:ietf:rfc:9999 let=E2=80=99s suppose that: urn:ietf:rfc:9999?+ct=3Dtext/html#Section-2 gets the text/html version from say tools.ietf.org. Then: urn:ietf:rfc:9999?+rel=3Dembed;ct=3Dimage/svg;id=3Dfig3#icon-clock-view gets the SVG content that was archived along with the main document = blob, and focuses on the clock icon (see SVG ). Then the following = URI-reference would be useful: blah = blah =E2=80=A6still though, if urn:ietf:rfc:9999?+ct=3Dtext/html#Section-2 = amounts to a =E2=80=9Credirect=E2=80=9D to = https://tools.ietf.org/html/rfc9999#Section-2 , I don=E2=80=99t see why = an HTML client (web browser) would see in the = first place. The better way to think about it, would be that would = be stored in some content management system as the internal reference to = the content, to be rewritten when serialized out to a web browser. (Note = that the content management system is aware of the base URI being a URN, = by design; it never exposes this fact to web browser clients, as it = =E2=80=9Crebases=E2=80=9D the content.) Kind regards, Sean > On Sep 25, 2016, at 4:08 AM, Henry S. Thompson = wrote: >=20 > Peter Saint-Andre writes: >=20 >> The only exception is the concern about relative resolution that >> Julian Reschke raised, which I posted about to the list >> yesterday. After thinking about it further, my feeling is that it >> would be very helpful for Julian (and perhaps Henry Thompson) to >> review the text again and to post to the list with a description of >> their concerns so that John and I can address them. And, as always, >> proposed text is welcome. >=20 > Here's an (overlong) attempt to be helpful here. >=20 > *TL;DR* >=20 > _Actually_, since we have kept URN syntax compatible with 3986, > strictly speaking the 3986 syntactic approach to relative resolution > works just fine with a URN as base URI, that is, does not trigger any > error conditions; >=20 > _But_ with two exceptions the result is unlikely to be a useful, or > even valid, URN: >=20 > Exception 1: The base URN's namespace is hierarchical in > structure and its NSS syntax uses / to delimit steps in that > hierarchy; >=20 > Exception 2: The relative reference consists entirely of q- and/or > f-components (r-components, no so sure); >=20 > _However_ in practice the issue only arises when delivering a > resource representation which includes one or more relative > references in ways which identify themselves as such; >=20 > _So_ section 4.3 [1] can and should be simplified to something like > the above summary, followed by advice to resolvers that _deliver_ > resource representations which may contain relative references to be > sure to deliver them in such a way that the base URI _for that > representation_ does use an appropriate hierarchical locator scheme, > e.g. http: or https:. >=20 > Below here are some lengthy discussions of supporting arguments for > the above summary. >=20 > *Background* >=20 > The starting point for any consideration of relative references and > the resolution thereof is an understanding of the circumstance in > which questions arise. Yes, 3986 treats this in the abstract, but I'm > going to go concrete in order to clarify some things. >=20 > First point: Relative reference resolution is a _process_, carried out > by some agent. Some reflection leads to a list of requirements which > must be satisfied before this will happen: >=20 > 1) We have to have a structured artefact (document/data > structure/...) which 'has' a base URI; >=20 > 2) We have to know something about the nature of that artefact which > allows us to identify strings in it as being relative references. >=20 > The most likely ways this can happen are >=20 > a) We have a document accessed via some means, and that means itself > lets us know both a base URI and a media type (the HTTP protocol > is such a means). The media type in turn lets us identify parts > of the document which are URIs, and 3986 lets us tell when those > are relative references. The media type _may_ also tell us how > parts of the document change the base URI for delimited regions > therein; >=20 > b) We have a structure (think e.g. JSON or SQL) which is either > intrinically or extrinsically typed. Base URI information may > come either extrinsically, or via the structure and its types, or > an interaction between those and an agent's processing. That > certain values in the structure are URIs can be assumed to be > determined similarly. >=20 > Even for those rare cases distinct from (a) and (b), it is _very_ > likely that the _author_ of any artefact including strings intended to > be understood/treated as relative references will have had such > scenarios in mind. >=20 > (Note that for URNs which are "abstract designators", no such > scenarios can ever arise.) >=20 > Second point: There are _lots_ of HTML or XML or RDF or JSON documents > out there on the Web which have been authored with the expectation > that they will be accessed via HTTP using an http: URI which in turn > therefore will be the base URI during processing of that artefact, and > thus that relative references in that document can be used to access > e.g. siblings in the tree-structured information space in which the > retrieved representation's resource can be assumed to be situated. > The toolchains which support this on the receiving end are many and > varied, and we _really_ don't want to include anything in urnbis which > makes them suddently non-conformant. >=20 > But this appears to put us in difficulties. If such documents are > accessed via some URN resolution process, the last assumption above > (about sibling access) would appear to be at risk, as resolving > e.g. "../foo.html" against e.g. urn:isbn:0451450523 is unlikely to > produce anything that will resolve at all (see below at *Algorithms*). >=20 > But that of course is only true if the outcome of the resolution > process identifies the base URI of the result as urn:isbn:0451450523. >=20 > So don't do that. That is, resolvers should deliver resource > representations with hierarchical locator URIs, not URNs, as their > base URIs. >=20 > *3985 Algorithm* >=20 > First, the relevant section [1] begins with an assertion I find > perplexing: >=20 > 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 > algorithm cannot be applied directly to URNs because their syntax > does not support the necessary path components. >=20 > Earlier in the draft there is a careful explanation that URN syntax as > described is compatible with URI syntax as specificed in RFC 3986. As = a > result, the 3986 algorithms [2], [3] work just fine, albeit not = perhaps > in a way that's very useful. For example, if we take one of the = example > URNs from 2141bis as the base URI: >=20 > urn:example:a123,z456 >=20 > and a simple string as the relative reference >=20 > xyzzy >=20 > the algorithms proceed as follows: >=20 > 1) Pre-parse the base: >=20 > scheme: urn > path: example:a123,z456 > auth, query, frag: undefined >=20 > 2) Transform references > a) Parse: > path: xyzzy > scheme, auth, query, frag: undefined > b) Merge paths: > new path: xyzzy > c) Copy query and fragment > new query, fragment: undefined > d) Reuse scheme, auth > new scheme: urn > new auth: undef >=20 > 3) Recompose >=20 > result: urn:xyzzy >=20 > For URN namespaces which happen to use / as a separator, the 3986 > algorithms will work as perhaps as expected in some cases, but not in > others: >=20 > urn:example:a123,z456/bar + baz --> urn:example:a123,z456/baz > but > urn:example:a123,z456/bar + /foo --> urn:/foo >=20 > Behaviour in the presence of one or more '..' segments is left as an > exercise for the reader. >=20 > All of this may suggest that a minor edit saying "don't do this unless > you are _very_ sure you know what you're doing" might seem to be all > that's required. >=20 > But there is a large set of cases where the right thing will happen = and > these are likely to be quite useful: that is, those where the = reference > consists entirely of the optional post-assigned-name part of the URN > syntax. In these cases the r- and or q- components will override the > base if present and the f-component will be copied over. >=20 > ht >=20 > [1] = https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-18#section-4.= 3 > [2] https://tools.ietf.org/html/rfc3986#section-5.2 > --=20 > Henry S. Thompson, School of Informatics, University of = Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 = 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is = forged spam] >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Sun Sep 25 23:38:06 2016 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 AEB0512B094 for ; Sun, 25 Sep 2016 23:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=itaoyama.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 dMoozav_YXOT for ; Sun, 25 Sep 2016 23:38:02 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0111.outbound.protection.outlook.com [104.47.92.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C77E12B036 for ; Sun, 25 Sep 2016 23:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6bP3FhoI2AGi03c5MOrXbV7ykLsJxgv63EK4dXba52s=; b=Tg36w2C5qOvvrFA7tdwA10ZPvlqCr4XrbQub7GjXec8AJdZbJSY/kzVaWr62Ck/H4NFMBPQ2JBjhx1FvKVOcxKdka5xYS9gUQkQebiiLL7Gcz59wxV9sgfIOuoqvOqRixN79F1M0P7J80jArpTUeyXiHv48Y4I42cLhLYVzHUZc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR01MB0927.jpnprd01.prod.outlook.com (10.168.45.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Mon, 26 Sep 2016 06:37:57 +0000 To: John C Klensin , "Henry S. Thompson" References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Mon, 26 Sep 2016 15:37:48 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR06CA0006.apcprd06.prod.outlook.com (10.164.91.16) To TYXPR01MB0927.jpnprd01.prod.outlook.com (10.168.45.22) X-MS-Office365-Filtering-Correlation-Id: 7bb5684d-3fde-46bb-5e3f-08d3e5d7a72a X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 2:w7ZAmMOh/Vu2SPuVQJZT2pc6rRrOebAX6zS+aBZpyGhnx9uJaBnpwVD2cSrPxaSIoBFPVchAd5BWO/kz05QW8nMVks6MVqzCl6oBsWWx8nE3Yc8yfvkzfXo8L2yl50PL1iV3okiNgp/RotND2IZmsnQIIMFABZGaqC/yJ6+JN3+L5E2PoBVa952N32qM6x/b; 3:L8EOvmXAHLdk6PcSx+kUn3WgARRYEoSDMqAxUsWue/5uzsdQgTwjSjIVAHgD4a4dG/uwjofd0qwUTpYxc78jZLLTCvCA1o7hCr4YanvhvNXiGZBdQ32jQj0+4BotGqTQ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0927; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 25:Q5kL59I/VoDFZ38VU9fpScjbf7DhDO0POGHwxDC+3VivI5M5d+IpStarAKtN5XFtOj3/8vnGYKr2ocZgqV/kZev9Hc9tqc78mBPXBmL4iPE5HX3O6Ct3UzmI7/KoCi+we8zwrWOLywvEXsaSssQrnCJDIyLolw0ITpgqtHHtjYqtHED9J9LHUn0c4oyMFfdgAaSlVaPF57Z9NXS9V9IED06MrCjS51OOfEBqScrEpXq6m/IlvXbw3nh5RoR6hPbojRUdcyUl6A5FJN5QG5wE4GIiS3tUXTH1rjDw5EDb/8dPnfbzVjfoNxrNRceci6gGFiglQYx4vJhT37hVVfqC323IEydxzdkudawzlDp0u1awVThgFPXWREJqFlEZsdzccHlTTjtPhGiIiaoOTJZyUflKcaSE1ZqTgiEeXD/VLBzCzmG2s2/K4mR7USvmgNzBqeKslbegPDTciO+W+cnZAyLOFJ2dcrcyokXYCm72da9Qqc+xIHyn+mZhARvABdVCB1+51Dnc0IBNTmNqovzYpYWVjPmeTOj3dPmloiQnTvGnCcf/E1p0uhR3JOf06R9zaYNoraCrA3AhOepA5cCm+5dXs+W+6TCGsszOSvOmEZDHJYeVSK9UJI48ZJX1j5npEVjBYAr7cHh3tmeihj2nE4TRTxpj7NqJsUA2wuQcQjgJWxRy5WqLQE9GNJRbcjAiNU7PU58J8Y2+VbMbGlSCCcm++jDfuRXZWESogqIsHVNzk3uwLwYf0z501tFcySUgD5/QVo9gvhOHuPg97IE4YsViNF72T6eIYTkfOxbhxos= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 31:WSRwaCxk7Zd4DZb03mjbvMbs2PuO9HUKwPa32UKvhT/QC/7rm6TXx2Z0DGIAZuOcm7IXL1QgAyBa8mEyD6V5FiBqC4mWEQj/HydweI5FNuHS+I8PfetUP3Z4MmNOjaghrU8SqPFOPm2XMfjh96o/dJWAKghvatQI4jRzG/pMJwH2ZJx7PI/3ACu10X7AHyEKAtTpvrZ19mzY5UjMAMmjAzV0iFrbkNIacRnQ0WQR3gg=; 4:R498HSk5seWrDmHKYNocbMcXNpDNP9koozB622SavP+H+8GfrXW4nOE9Jk/3d28/rtr9DXYjFA/uigXeGRyBU2cRwwvqaiYlRNlYrs6LKa4IK2rb41j7tBSAtqzg4WrqncUAJo3mG6bThHsb0SnJALsBpc7ndFWTDbaBnvVXCDti+bi+HrpPqMcGW2Ft0maNVQDc/GwXu7zDKADq6OwUS2USoq02pMdYwvpJsjOzX6MRvKiw5DFyRNWPVRn/o5e5lBRmQqV33rkDT7IV9JbGbbL4j/10F27Mmnj7StTKhrdxRTElN+yyjuW2TsH3jShddK7AMJZoos+gRwnLKgUO6D1oNeQ2uuZLHbGTxdwGXbpX3l1K27/4ipxiF3K4G+kFsbwL7NLdmM+pQ8/4GmEoWSZ//pn+clIgxo8BfNMpBKZNOozHRQ9pAF8O7O0wFSgSyvQNmROzDhgZAilvVbAs34fPVCMzcRBhLQXJyMt+LbI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089)(181193635805523); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6042046)(6043046); SRVR:TYXPR01MB0927; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0927; X-Forefront-PRVS: 00770C4423 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(52314003)(24454002)(199003)(189002)(5660300001)(97736004)(74482002)(23676002)(4001350100001)(65826007)(31696002)(5001770100001)(16799955002)(4326007)(2906002)(33646002)(42882006)(101416001)(81166006)(15188155005)(83506001)(8676002)(81156014)(86362001)(76176999)(50986999)(2950100002)(54356999)(66066001)(50466002)(19580395003)(42186005)(19580405001)(3846002)(68736007)(230700001)(105586002)(6116002)(31686004)(65806001)(65956001)(106356001)(92566002)(47776003)(15975445007)(77096005)(64126003)(305945005)(7736002)(189998001)(7846002)(586003)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0927; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI3OzIzOk5CZ3o5YlRGeW9FazBCM0xKM2xwWGxLTUVC?= =?utf-8?B?MWlVbEIxSHhidnMzRTR1cVF4U3hQK0I0MWlYajQ5NUFqOFJVcnNtSVJ4M20z?= =?utf-8?B?RTdSb0RMUUg2b1VpQ1pmWjN0Zmc1cEdEUCtlbWs4YUxqZkl3VSt2QUZadlpo?= =?utf-8?B?RkorQW93aW8zYTZucUIvc0JOcCtmWnBXcEhQY3Y0aFUveWJBSkRKdzI5dm4r?= =?utf-8?B?QnRLc2Z1YTVUVTRqT3JkVUZiUUhWVjNvSDU4S0U0Y3VvVC9GeWZVN0JYV3Bh?= =?utf-8?B?c21HVDFpdmR6WWl3RCszT2I2RGJSdW5kUHllTldVRVhFeGQ3RjJlcCtuQzZ4?= =?utf-8?B?dkcyNW5aeGJYTmYvWHRPbDIzbWVBa3VzS21Hdis2bGZBY29zV3lIS1FFY25X?= =?utf-8?B?d2xVYm9SeUorRzJ4V0ExaFhJTko2ZHkrS3BscGhQNlhkUnBUdWpGVDRUNUhH?= =?utf-8?B?YjVrQXVRK1c1L2V3UGtjeUp5dXA0UDlSZUtKUHhsdHFIcFpIeUo2Q2dqMVkw?= =?utf-8?B?bi9wclBobjFlK1dtWTZ1dmFJM1ZsSmREZVFiSk54cFlna0Fxa0EzOG41U2hu?= =?utf-8?B?eHBGRStWYm9sVVMxcFNFMy9Wbm5iZ3dJRkxidGduTENkUy8vTk9vZlIwRzJq?= =?utf-8?B?U0owSU4vaUtsUkt2NStUK0RtNENTSXFqVlQyVVdwYWJNNHdZNDNqUUJuVFpS?= =?utf-8?B?cVUzNjk5TjJpOVRnYkw0ZUhpMEhScXZYa2w4Wm1SaEtxZERjbmwvRnpYTWlJ?= =?utf-8?B?dERMTTJReXBPa1V1TlJxREVWdVFwM3BPc3VnMDVEdmZzbmtLcmd3NVc5bmd5?= =?utf-8?B?ZEpJTzd6TmE5NUt0QnVSVkUrK1N6NWZ6bVlpVTVNRSt6RUk2bC9QOG42RkFi?= =?utf-8?B?NWRjYzE1N3Q5MVRPSmJLUWcwcXRXZEc2TGFGeVNuRkY3Y3JLd2tZS0Erbk14?= =?utf-8?B?czhYMHdaRXUwNFBBN1N1Nytsb0s3RU5wNGNGNHgwWHV2VlRucTJxVllHRlFU?= =?utf-8?B?VXdlTFh6WTNhdjBsc3RHYjJDWi9kZ0FCSTliSWNrbnpsNUI1enJONitCTGlF?= =?utf-8?B?R3hTU0NBTTlyNm5uTTU2enpTTWZHUlA3d0t1UXdjVVpVZGNXRTFvSngzWVBx?= =?utf-8?B?K1RYc0hPYW9yRk1FUi8xRGorOUlXcUZ0ZXp6eXNkMU1xTlJsYWkxQVJoU0l3?= =?utf-8?B?N21SdFpCRVFEZE9xT01BUklJcWxhdXJMZGJHVzhVaFNBR3hjTDV2d1gxTXEy?= =?utf-8?B?TlBoVjc4Ky9TWTJhNDdHMzg1c3VqUEVXcTlMLzN6c2IrVEdscXZ6Um5oZlQw?= =?utf-8?B?bGp1QzVKWlBBMUp4NHVVZVRDaGNqbW5jUjQzeGVaaG1zYzZncGQyOFJMcS9n?= =?utf-8?B?NDJaaUxLNXRjTTdFdmpia28vQmtsLzJuejQ1eGxpak9Gdlo3SWptQWszRlBV?= =?utf-8?B?bThHd3ZPamdPU3REcTh0RVdrQ1ZmMkVuUkxnYlNaQVZpZGpiaUpJZTF0a3Zr?= =?utf-8?B?L29STjZCUllhVDZzbS9kenFmMlRBNkgwYjE5MGxZOExQZDRBTGs3TXV5L20z?= =?utf-8?B?Q2c1UUhMYmdXT3Z5YndzS2FCYStOYS8xZ0ZpaTNYamg1L0lPOGNQdWhRR0Yv?= =?utf-8?B?cXBBSmNtN2xWRW9vR0NZWm41OXdyRW81bU5rNWtxM29LRTZQMVBJck04T3c1?= =?utf-8?B?RFZPZ2NRWGRWeTdxZ3BaM3cyTnV1QkRqTDFpYU1CaVZFcXY3Qkg5SW1MZWRk?= =?utf-8?B?RUN6MU9uekMxZXNIU2ZadExhTVFUK25FV3BJRXRFQ1cwMGw1dUFndFh4OGFV?= =?utf-8?B?Sy9ON09XNHE3bm5NVDdRU09QWkpzcFgzYXlLTUxUQjdsL21yR1RLbTZ3RmpO?= =?utf-8?B?T0cwZXl6UkxjTCtUanllbytraGxGaTdtRzllaDQxZWhlNEh2UG5NTWpua09n?= =?utf-8?B?U0RuSXR3SkZ3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 6:FHLIHB8wCXObjlCTb4R8MkdooTWPAsCOCPZn0eVnqu+OJGQRGiVsz3jDi5k527aKIQJksCsQ6E3JO0p2rzEUfW5ayPoYS126nnZ0fnPt3MzLKJfN9oxSDJKCdkBtV5sF/DmhWV7i+KNQ4l3PimWcdyKasb53JwMOUGjO7eYyXHxlsZTWu1qqDVk5Uhjb0I3ou/ZC+tdiz7hu/V5NEGevTeuC+kWKgrLPSbVXAoiM9a1SqYwKPNMfLkiumf6rL10+Rxnx2RI3KnXgPU8+NqQqht1OqMDyMLLuZvNQwFLEdmrsgv//96XU2r4uoHo/AIW6; 5:HuL3XImO20BaJSlyCkJGIOR4VSgOSixiAQduGxQ/NQV039asY6+BCFHXxwuVIEiDpKTtp0sXgX/3YMUsBzI2bLUg6Nyi5066ar5ktSerChoBtzp/4OnN9E/Z1WZiGBlQATj4nxXU+AsKLd5h/wR58g==; 24:vT/IkbF1wgenBA5oHNKyBr05kckRskA6m9Q6OPlkPMopHzoz451yg43Y9j3qREnIbQTXZ/paxid+fq9AZC3EXeuiRq3iV4B8sZYNeOqQqEE=; 7:oKac1LuJkiqlyUrAflr3hptP9WW4YJNt/LOjSRtjFdSyb/vP+TQjVhVwEXCoer20+H/VxmaA+jCukLFlrT2DZ5adpO5TtbuYtqebd8PBgegqTeY9yqIR70pVF/x6dhMK4D5qcKtLY69U+uJoHDxSLnKBkNvtKMg75TKCaKTZXwUgkJdtKGmrMNoR5NJWTJ6mTNkqJ/L21ZogLoGqkU3ZfKqgKi2G5dpervWG9Ac1BHsIxYabfEK2C+3XmE4SugF3nxIXQLr42TeAjjfu96Cs8WDY3PL7toX8zNpC/RFiHPDwqilKlL0LLkO1EwC590mq SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2016 06:37:57.2821 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0927 Archived-At: Cc: urn@ietf.org Subject: Re: [urn] version -18 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: Mon, 26 Sep 2016 06:38:05 -0000 Hello John, Henry, others, Just one comment below. On 2016/09/26 02:09, John C Klensin wrote: > --On Sunday, September 25, 2016 12:08 +0100 "Henry S. Thompson" > wrote: > Consequently, I suggest that we remove all of the present > discussion of relative resolution from 2141bis and replace it > with two statements, exact wording to be determined, but whose > substance should be (the footnotes should probably not be part > of the statement(s), but that is an editorial matter): > > (i) A system that encounters a [1] 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.[2] In general, references that contain a scheme (such as "urn") are treated as absolute, and are therefore not involved in this process. However, there's an exception in RFC 3986, called a "non-strict parser" (see http://moo.sw.it.aoyama.ac.jp/mod/quiz/view.php?id=1850), which allows to ignore the scheme if it's the same as the scheme on the base. I'm not sure how widely these "non-strict parsers" are deployed. Maybe very widely, but maybe they are rather non-existent. We'd probably have to as Roy directly about this. Anyway, that suggests that the wording above might need to be a bit more cautious. Regards, Martin. P.S.: I generally agree with the direction that John is suggesting. From nobody Mon Sep 26 00:50:42 2016 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 2726612B0A4 for ; Mon, 26 Sep 2016 00:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=itaoyama.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 LwJcVWQonssY for ; Mon, 26 Sep 2016 00:50:33 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0112.outbound.protection.outlook.com [104.47.93.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7483412B09B for ; Mon, 26 Sep 2016 00:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rVWHF0NXwlrt4RPatrSm27eZibnCNZL3EnYiHVy5J4w=; b=vnrrRwCf9DUIzY76htzeX0b0mft8UJuXCKEmLp3ZSI15ruGDz7+kl5/P3lV5PIPXf3wtlpA550yMvaHxbhYkFARwPXZ2e3yeIwowK/fVbZZ1vWX9EVHVOsIquZDKtxXpxC5TdfGrlg9CClMYOkg8Slt7lP16TT1ITqMKX0l6Vbk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OSXPR01MB0918.jpnprd01.prod.outlook.com (10.167.148.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Mon, 26 Sep 2016 07:50:28 +0000 To: "'Roy T. Fielding'" , "uri@w3.org" , "urn@ietf.org" From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <8f61fb13-8c29-8477-0441-b042845ef92e@it.aoyama.ac.jp> Date: Mon, 26 Sep 2016 16:50:24 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TYXPR01CA0040.jpnprd01.prod.outlook.com (10.168.40.50) To OSXPR01MB0918.jpnprd01.prod.outlook.com (10.167.148.148) X-MS-Office365-Filtering-Correlation-Id: 70a3e28b-673f-49a0-074f-08d3e5e1c8e5 X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0918; 2:+mtR+NwRhdHW9inCtcWmDsamSpiXh6jLwevIQVVKBpyD+CJUFaTNHKe/zsGg+JNQ9MEUiNlxNiIQI8diMvLVmtsdlboAaJDRJexxfI/YSZfhaiGL6uEaeQ4yxJBYGmMMqUa/UHiJERtQcIl9sY8iQM21+9iOWn/ztvEa3genwI8pxKp99IPdPnAAayyY2IsN; 3:iL7+/eD/RtRlv+BXeoF60mbQ3OwzIPCviR4svDw8Km0wuVxpPzpWtcy+HVc2GOKTWl3rdjHKVe40crlg3tFfnVbG81BTe9qyiQhLltwLAtMO0uShdKB5DWH0Ak536HR7 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OSXPR01MB0918; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0918; 25:jpY5Gg0nV1L46TnHta2Wu3Lk6TRITOHVFo9vKOTmBDkwEOSv5khoIpnhtgrbKNw6eDCBCTqtPGNSTbluagk+7JlG43ftnXkzL5Uz8uSQXj+YQQZ91UokFnh2QOo6e6lNc+btcDdXpdxk+LgeL0Gnx34nCrg7n4E1L8VNZABSKUcQClSGRVF/JZ2b09fc4Pgzs0q3tjfJSG7nJ24+MjSnWUe+2JgNRarqs4NaLm49Q25gbPRxY8eUs2iI2K2NQ0LiWmPSOgseLk/IB6oBl+cQ+bshoKsztIXrCpWp8plN4Rxj/i/QKElU/H6mVvTHzqWQ1FH5mzEwGI87euMPMmch6T6Soa9RwyA8jc3sVMcpTkQRVI9qe0UWUnMtqk6zaHmlNKE2DwjlS3CEcOB4Cgj/de74zKDyZqWKkUP/43LKL5bfsQgepDdKGj432BXpYrqr9PibHICziXdZRzuLXUyyFN9DWM6qblbUMP9ENWJwE/2KIpxPimO5wF5T0FC83xGt0Lyi98LHuXMzb+1us889GxJOupv1jQeWUlVUEnOw8hRFLtGDKi9dH8UQE1ZgT9sr+IsZfgzurmz55eO97MHcUoFdR9aGaXD6s49/OCv/Ak+Die9g+/dkKp/ubGTgTLi5I3u2/roOxGiqep8VE30SHiVfYmR4TdnMro17t0QkPpIRKL8e+n7G7PaME6VSz/kFUrt9bXUN+aX1/pfsmKInkvw70lrSPJ/5hn90sclIzaWJ0AJ1sf1wTvgRM05OUaQEHpIHqltE43kgrtW3Ap1IBt1kr8J4IH9QxYpeRDYB9LydRrsYoukE4SGo2VA/Bwho X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0918; 31:OUJIPEzFHLYuLsfuuPPyOB0Zo8AcZYacrDx+Vu/JqdZYlSWB66kv2s3I7bvDxjm+tjwgMllG/R85Qdl+z2EmOG0t58ehUVqS4brrBCJeAVZvnlAxkNbubvQ/Q2PMh1CjDL0x/vFcBz4+Ped3EgIZftKqWkluYTuMP0bfbPzMBlyvKA4CFaF/JE7HY6SoRwkfsqqaq4BbwANzCIjc2aAQPvBmbUiu0y5eIvPUQLsOVHg=; 4:dhEydaCylocoMP7H01b3PN4fIKc90s63S7LW6Q/3s8dRPQMzpkDBi85hTAoBpmyrj5euyummAWJqOMMXtKr/dL1DH9AccN0akrsDegQ2Z7/hW61ZmhplfgMbUSOCAQLGaMSlkqXXWsIKLuGe10D0T0HO7SVuK1oJg7OHLTB4/gsbVsw+cxjfi25AvxuA0Ocq+WszKGdLkLpk1s4nEo1zUwReQY7L6wEIdTtCFhnaMmvWHsWk3qMgk+wLqCkV4+FnHGoCM6geE5xwM69jLlJ496oSc8UgqyO/5LJhMWYu3hQGZ4CktuQjXp2tGgE45XXaVTgQT3zWj8fe8julIOnEkmWuxyyUr2WmgeQRvAxs2yfTnoEt7gOq/q+56UAsCjIlXwAF4Fw3nAoGHbN3p/9TUTFyNQXxEj48fJa88+7VHLk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6043046)(6042046); SRVR:OSXPR01MB0918; BCL:0; PCL:0; RULEID:; SRVR:OSXPR01MB0918; X-Forefront-PRVS: 00770C4423 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(199003)(66654002)(107886002)(5001770100001)(189998001)(229853001)(74482002)(19580395003)(2906002)(7846002)(92566002)(47776003)(77096005)(15975445007)(97736004)(83506001)(68736007)(105586002)(42882006)(42186005)(23676002)(106356001)(4001350100001)(230700001)(31686004)(65826007)(86362001)(65956001)(65806001)(3846002)(6116002)(31696002)(66066001)(64126003)(2201001)(5660300001)(101416001)(54356999)(81156014)(50986999)(2501003)(33646002)(7736002)(586003)(50466002)(81166006)(305945005)(8676002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSXPR01MB0918; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU1hQUjAxTUIwOTE4OzIzOnJQUUtJTmdSNDZIQWlmQnAwK2ZEclREb3BM?= =?utf-8?B?MG1icXRxcGx0VFJsZHNSbTBmTnhYQVRtN2dPRGkrMTFrR0tUVlhyUDkvZTB0?= =?utf-8?B?Nmd5MlVVa3pxaTdXb2R6QkpWR3VZV3JiRnFZbzFFeGhBY2wyRjlQdTJ5Q2pJ?= =?utf-8?B?dWw2cmZKU3d4d2JXZ2ZpamRwR0lSWWpZOGJud2hnQnRnUEtRRWkyNGpheURq?= =?utf-8?B?Ylk3ZGsxZHpBbFVJaVdiVkRQMUlmanlTamZ4OGo5aStmN0lBU1kwNnZFZEkv?= =?utf-8?B?ZnlQT3o3Qkg2SGlGT2hUYitnWE1XU1NTdHl0amJucHJZeDViY1M5dEtWVXF6?= =?utf-8?B?QU1Kb2Y2MXJrUHd5YlI2aXllYmRMNUxsSnA1Qkwrdi80Q3E0aEQ0eUlwTTB5?= =?utf-8?B?SEZhVEt4MlQ3b2F2Z3lKRnF5UHZNaVRwbEdTZzh2dU9yeC9lbHU5L3AvMkxQ?= =?utf-8?B?UGQ3Z1AxREJyL0RYamNVZmZ6bEZ1aG13QThITWlHcHFpUGtzSzFySktJcjN1?= =?utf-8?B?OHROV01MR0RoWVF3KzFGR1NHMXIxUitXcDZCZ0d5Z1l5YjdwVitmdmJjckFV?= =?utf-8?B?d28rZS84Z0svSXFHRm5xOWxYb2VpM2RLdUh0QmVQdnA5TEFwWjZ4M25RbS9r?= =?utf-8?B?b0dzMmhwaWJiL215Sjg1aTZZMVBrVGZvdDZ4UE1lK0YwUk4vZUdrb05VN1ls?= =?utf-8?B?UTVmY3VnYkU4S1RqL2o1NlFIMXNiUVpiWDhMYUlIYTBZNmVZK2puUkJsZ1hL?= =?utf-8?B?VDJXbGF3K00vdlZoRi93WGc4blRXejFjRktPYU4xR2tINjZ0NVNjU3FPWlVa?= =?utf-8?B?M2xkSlNmYk9ENEFyZDB5d1lqb1daam1QMGxwWUJuNVNpbnNxc1pvSDg1akla?= =?utf-8?B?Lys2ZGxKaWxnWFdtN0VxZlg3UmlCY2gxV2k2WDlzTVYraTlpam9NSnpaVzVm?= =?utf-8?B?dmozTzFoVEYrODRrRWtNZkJqUnBsc09uSkdCc2NrSmV1TTFPeFJWeHBBTmFv?= =?utf-8?B?MG12YkNIVldwbUhFN1dRbkQ3bllIWlV1bm5hbm1HbHl3N1FUT2VuYzRTUmZT?= =?utf-8?B?VE53TFVubkdvb0pOdU80b2pialpUN1RJVDRYWHZnemRTZ2ZwUUtPTzE2TUdw?= =?utf-8?B?UTNhSWdnTVYvNkR1eHB0QTk5TVZ6VEhNT09lYzRiL0Y2bnJ0ZlowOWJ2WUZr?= =?utf-8?B?djI4aHVCdXZqR2tXNFEwY0luNzFFVVhPYzRVNDllcGRIK1BSNHM4TjdacVpn?= =?utf-8?B?UndmanNILzlsMjdXS2VSZ0t1VnIySVRSL1BNbTZrZ3cwQzFwNmk2SHhla3RI?= =?utf-8?B?eG9rUGVSVGRJMGpSZ3Fuei91Um9JdTJKRXVNOGt5R0pUaE0yNE9LSGRabWtp?= =?utf-8?B?TS93ZXA2OGtURkFSS095UDBXTnJ3LzgzdHNDT1RhcGtCZDhVUGJ6R2RwUHF4?= =?utf-8?B?OEtNSHREOWw5dUhHeUV2L21sRHF6cC9Id0hEOFN0cW5PWjJ0eDJaVm1CK3k0?= =?utf-8?B?R0V3M3hHRjVHRGt4UE5MQ1I1c0FLU1ZXc3g0cCs4R3Q5K1VoZFU5bmI1cy9M?= =?utf-8?B?N2dwODVERi9MZjdmT3d2REN2WWpIWklmbUh1RXJONVE0RXoxS2tYZENscVdq?= =?utf-8?B?UXZZU0F6OVhhajh0ZTlwSWF2bmlvay84TzJiYXhTTXRlMEFnT3poTVNOMnhv?= =?utf-8?B?U0NScUZJZE1IZHE5V1NxWjRXQU9Zci9mVUZ2ZHRvbzZJQWRsbHRGanh1V2Fm?= =?utf-8?B?VVRBUTFvOXJkdXpXa0lFV2J4RktiWEVUVjNLQ0NMWUFMUDJ3MmZLTFNtMVox?= =?utf-8?Q?qJUBu0OwFYK9f?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0918; 6:NWZpsSKM6dFcJWqbS+WA90zKho1hXFNHIFXBHLEtfZpU4Ksjl7AqKoqvRgoxxUlJdvYB775ZZ92duz1wv0B+SvTvpdiCvNxvHIBS+QJ+3tgEaaEB7MEMhDtVgqMyS/O9j4jAm/Y0/HzgeHeZYfMs9ZdNs1BuhsRHpPJ7y0sK9AfIOuiHeMhR/PlbkXrSdp+6Vo7/dqts2wQFh3F5REF9wRDXAgUUpHkT6LYjukz7tgO0ryXNet5rikxFar5FbIwHrvhtVR0IpOwMEUtkD7hGib8xHSJWEDtRkyTXzloSxw/vSHwUyH+uPCzYPc9WzjjC; 5:rRa4h86xho6ab68Z4iIvwie+5c/BYENGFqDGqth8Q/FIkta7yyOmNb949NBZPxwBPAdcLZwCkTfvwhnUr7AoZv+57QRMsKB4yl3muXGAm3xW6AcLnOH6JztDuINAidDY3bhEbpXGtnV8tzD/Z/mTmw==; 24:zBTmAIABMDPenGVxD1qdhz2avCWkn0BZxCQlJVbHzXmNZRQaleHCH90zD5Ewsf53mnZ3P79M6wIEGfB+ZDUeBBwMHxsUm/Nj8tB3cueXHV4=; 7:qqSY2MRoursiVfD/GUzyZsRj5Q8J0Nws5Doc3c/Yd36ABd7j3lOPfjFPIL0z5LYyl5OW6pi7/JG4MZd39gcoLZ/dVuPnnP+7hmD6xJ+KxXiDVsKj/p4Ibgj8Ag0ytDaRpCOkAmfJiYPlijBTn0b2uWRT2MONFyOdYtxhAVZ9NVktpoC/KtNIkncu9ZjX5IkLdGGGfhfPGXyQwPsSkg3h+1NgYxfjQzQDk9qN0kBnTtUzygBuySnlGgJGZ4N1NfSamGqxHpC8fLVoXUmL316/FuPNl0NTZAN/i4Ex33A34G2yQKDH/M8ASnwGUmoIu2VS SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2016 07:50:28.8255 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR01MB0918 Archived-At: Subject: [urn] How widely deployed are "non-strict parsers" in RFC 3986 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: Mon, 26 Sep 2016 07:50:35 -0000 This question came up on the URN mailing list, but is essentially an URI question, so I'm copying the URI list and the co-author of the URI spec that I think will know the answer. RFC 3986, in section 5.2.2 (https://tools.ietf.org/html/rfc3986#section-5.2.2), mentions the following: -- A non-strict parser may ignore a scheme in the reference -- if it is identical to the base URI's scheme. -- if ((not strict) and (R.scheme == Base.scheme)) then undefine(R.scheme); endif; The term "non-strict" isn't found in any other place in RFC 3986. The question is how widely deployed such "non-strict" parsers are. E.g. are these things that still existed in 2005 when RFC 3986 was published, but are now essentially extinct, or e.g. did and do all browsers behave that way. Many thanks for an enlightening answer. Regards, Martin. From nobody Mon Sep 26 02:18:40 2016 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 8B7E012B0BE for ; Mon, 26 Sep 2016 02:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 VPDYthX0ew5t for ; Mon, 26 Sep 2016 02:18:37 -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 7A33712B071 for ; Mon, 26 Sep 2016 02:18:37 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1boS3S-000B5D-5Y; Mon, 26 Sep 2016 05:18:30 -0400 Date: Mon, 26 Sep 2016 05:18:25 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , "Henry S. Thompson" Message-ID: <1A3D61350AEE72A747B14709@JcK-HP8200> In-Reply-To: References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 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: Cc: urn@ietf.org Subject: Re: [urn] version -18 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: Mon, 26 Sep 2016 09:18:39 -0000 Martin, (top post and very quick comment) I was aware of the non-strict parser text when I wrote my note. I favor "more cautious" whether there are extensive implementations or none as long as it can be done without adding length, complexity, and the opportunity for more controversy and questions about whether 3986 is being updated or contradicted. = However, because a new implementation could come along tomorrow, I think we are stuck with what 3986 says rather than implementation-counting unless someone proposes to immediately create an I-D to explicitly amend those provisions out of 3986 or deprecate their use and a plan for getting that I-D approved. As long as 3986 contains those provisions, "no one actually supports this" (even if that were true) is not particularly relevant to what goes in 2141bis, at least other than supporting a statement advising against the use of relative references where URNs are concerned. best, john =20 --On Monday, September 26, 2016 15:37 +0900 "Martin J. = D=C3=BCrst" wrote: > Hello John, Henry, others, >=20 > Just one comment below. >=20 > On 2016/09/26 02:09, John C Klensin wrote: >> --On Sunday, September 25, 2016 12:08 +0100 "Henry S. >> Thompson" wrote: >=20 >> Consequently, I suggest that we remove all of the present >> discussion of relative resolution from 2141bis and replace it >> with two statements, exact wording to be determined, but = whose >> substance should be (the footnotes should probably not be = part >> of the statement(s), but that is an editorial matter): >>=20 >> (i) A system that encounters a [1] 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.[2] >=20 > In general, references that contain a scheme (such as "urn") > are treated as absolute, and are therefore not involved in > this process. >=20 > However, there's an exception in RFC 3986, called a > "non-strict parser" (see > http://moo.sw.it.aoyama.ac.jp/mod/quiz/view.php?id=3D1850), > which allows to ignore the scheme if it's the same as the > scheme on the base. >=20 > I'm not sure how widely these "non-strict parsers" are > deployed. Maybe very widely, but maybe they are rather > non-existent. We'd probably have to as Roy directly about = this. >=20 > Anyway, that suggests that the wording above might need to be > a bit more cautious. >=20 > Regards, Martin. >=20 > P.S.: I generally agree with the direction that John is > suggesting. From nobody Mon Sep 26 09:53:13 2016 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 E122B12B255 for ; Mon, 26 Sep 2016 09:53:11 -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_HELO_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 zwh2c_R5dWz3 for ; Mon, 26 Sep 2016 09:53:06 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 05C3E12B122 for ; Mon, 26 Sep 2016 09:53:06 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E439450A73; Mon, 26 Sep 2016 12:53:03 -0400 (EDT) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , "'Roy T. Fielding'" , "urn@ietf.org" References: <8f61fb13-8c29-8477-0441-b042845ef92e@it.aoyama.ac.jp> From: Sean Leonard Message-ID: Date: Mon, 26 Sep 2016 09:54:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <8f61fb13-8c29-8477-0441-b042845ef92e@it.aoyama.ac.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "uri@w3.org" Subject: Re: [urn] How widely deployed are "non-strict parsers" in RFC 3986 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: Mon, 26 Sep 2016 16:53:12 -0000 On 9/26/2016 12:50 AM, Martin J. D=FCrst wrote: > This question came up on the URN mailing list, but is essentially an=20 > URI question, so I'm copying the URI list and the co-author of the URI = > spec that I think will know the answer. > > RFC 3986, in section 5.2.2=20 > (https://tools.ietf.org/html/rfc3986#section-5.2.2), mentions the=20 > following: > > -- A non-strict parser may ignore a scheme in the reference > -- if it is identical to the base URI's scheme. > -- > if ((not strict) and (R.scheme =3D=3D Base.scheme)) then > undefine(R.scheme); > endif; > > The term "non-strict" isn't found in any other place in RFC 3986. The=20 > question is how widely deployed such "non-strict" parsers are. E.g.=20 > are these things that still existed in 2005 when RFC 3986 was=20 > published, but are now essentially extinct, or e.g. did and do all=20 > browsers behave that way. > > Many thanks for an enlightening answer. The way I've seen such a parser work is: Say your base is: http://www.seantek.com/asn1teletexer/ and you want to link to: http://www.seantek.com/asn1teletexer/asn1teletexer-0.7.zip Using a "non-strict parser", you can use , and it will do the job. You should= =20 look at the top of Page 32 of RFC 3986: it says that if R.scheme is=20 defined, then R is not actually a relative URI, so R is just used as the = URI itself. A strict parser will produce a URI of=20 "http:asn1teletexer-0.7.zip", which is not dereferenceable. RFC 3986's pseudocode could have been written as: if defined(R.scheme) and ((strict) or (R.scheme !=3D Base.scheme))) then (...T =3D R...); else ... I have seen some web browsers that will handle https: , such as: producing=20 "https://www.seantek.com/asn1teletexer/asn1teletexer-0.7.zip". I cannot=20 point to specific web browsers at this time, but you could construct a=20 very simple webpage and see what happens. Regards, Sean From nobody Mon Sep 26 15:34:06 2016 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 AD93112B2FF for ; Mon, 26 Sep 2016 14:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.317 X-Spam-Level: X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 4gqfTdOeWp4W for ; Mon, 26 Sep 2016 14:56:37 -0700 (PDT) Received: from nm50.bullet.mail.gq1.yahoo.com (nm50.bullet.mail.gq1.yahoo.com [67.195.87.86]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0229212B2AC for ; Mon, 26 Sep 2016 14:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1474926993; bh=yzejfNzQrPM0l54rWU2XezMv+eZur6Q6lBHyPI7K/Jg=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=rS6f57nkUJEe6pmbKxTyeuYhmCJ/2b1TqwdJcQ/BFGOxn+l4E1SwzuZK5O8v+Gc0IqmqdgFh1Avk7ErZHhpScFpJhhLFQTwg1GVEz+iHzR3oBkjyLip+P9u0maK1Ky77QF9nHHkCBPkfcDVNUvftKIGvtQIk+5/mEcfLLbusZVI6hC50Y/KwijMO/F8DqD7Q4JSU0gMzvggMh7YFUAiuxfC+b0+SN3qpirS35WZA/7FMDzn/LwEpXeQZV5DuqrTr+pe1yzq607nY5xjhb3Q9fjxGItkYNQt4JPKLyri47R8tRM9+qcVUvd13Vl8Lbno8UuFLPVKL08Hz0lux5kWKnA== Received: from [127.0.0.1] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 26 Sep 2016 21:56:33 -0000 Received: from [216.39.60.181] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 26 Sep 2016 21:53:49 -0000 Received: from [98.137.12.232] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 26 Sep 2016 21:53:49 -0000 Received: from [127.0.0.1] by omp1040.mail.gq1.yahoo.com with NNFMP; 26 Sep 2016 21:53:49 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 437250.23932.bm@omp1040.mail.gq1.yahoo.com X-YMail-OSG: 4OSYG.MVM1mTnHAEe3PAkJPN6xzqbAtIqD5aIpSxH0FzfHV6yGh3pgfEg4cAbKb 4PPDZyWxSfgfdQmekMdUGekD46b952uuc0mLeZ91BEnnV0UQITHTisASbgWn1M3QHKJYnxBQWfLf 7XVR70OzM8jQxOma_..O43a5f4H3GEDXOd31S3KRnBCrN73NDNv6PIkcB8yp0TyUIdZga0dMnuBE nL6Ed.6VeawCF9IW0ZxrQ3nDbmg.8JOA08NiYGsNpJgeSAWQECjMWfnGFL4VP8jO6gEnoRGiehTr FGKx0JB3kLvmAYgf7_rss_j44C1WiGv4wY2N4jkZYDFQ1iB3RuEqgCtfikH1kOmfMKk1oKLonR_b KAiD.1l5o7aCP.4AnfEFRUDTkhS4ztAw36895ctGl7rNrkP9mHqs7T0sXXnH6vtit2N8APIw1oTp vRskel_y_CpBRYFl04WiquPPmSPtluTQ97L7sBVjpzNDrjyIe6un226RO5ZILsTWYYoIZvLoKnON 8AsDSqifVHwcRzSpYj0BZJf62VZ7cr6o56XW5ow-- Received: from jws10781.mail.gq1.yahoo.com by sendmailws107.mail.gq1.yahoo.com; Mon, 26 Sep 2016 21:53:48 +0000; 1474926828.438 Date: Mon, 26 Sep 2016 21:53:48 +0000 (UTC) From: Gannon Dick To: "'Roy T. Fielding'" , "uri@w3.org" , "urn@ietf.org" , =?UTF-8?Q?Martin_J=2E__D=C3=BCrst?= Message-ID: <1388715639.6356426.1474926828205@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1388715639.6356426.1474926828205.ref@mail.yahoo.com> Archived-At: X-Mailman-Approved-At: Mon, 26 Sep 2016 15:34:04 -0700 Subject: Re: [urn] How widely deployed are "non-strict parsers" in RFC 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Gannon Dick List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 21:56:40 -0000 FWIW Martin, When me and my dinosaur mates get together for Mark-Up reunions we remember= a time when XML parsers came in validating and non-validating variants. These variants= caused a huge amount of syntactical mischief because they implied two or m= ore sets of "House Rules" for what was ostensibly the same game. The "two = or more" criterion is highly significant because DTD's classify character e= ntity behavior as Null or One or more. That is why IBM Salesmen have tradi= tionally traveled in packs :) "Non-strict" and "Strict" parsers both can be very intolerant of documents = which do not follow "House Rules". There is a way around the politics - Ro= man Phone Books - and I will tell you about that if you are interested. --Gannon -------------------------------------------- On Mon, 9/26/16, Martin J. D=C3=BCrst wrote: Subject: How widely deployed are "non-strict parsers" in RFC 3986 To: "'Roy T. Fielding'" , "uri@w3.org" , "u= rn@ietf.org" Date: Monday, September 26, 2016, 2:50 AM =20 This question came up on the URN mailing list, but is essentially an URI=20 question, so I'm copying the URI list and the co-author of the URI spec=20 that I think will know the answer. =20 RFC 3986, in section 5.2.2=20 (https://tools.ietf.org/html/rfc3986#section-5.2.2), mentions the following: =20 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0-- A non-strict parser may ignore a scheme in the reference =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0-- if it is identical to the base URI's scheme. =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0-- =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0if ((not strict) and (R.scheme =3D=3D Base.scheme)) then =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 undefine(R.scheme); =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0endif; =20 The term "non-strict" isn't found in any other place in RFC 3986. The=20 question is how widely deployed such "non-strict" parsers are. E.g. are=20 these things that still existed in 2005 when RFC 3986 was published, but=20 are now essentially extinct, or e.g. did and do all browsers behave that=20 way. =20 Many thanks for an enlightening answer. =20 Regards,=C2=A0=C2=A0=C2=A0Martin. =20 =20 From nobody Wed Sep 28 09:11:58 2016 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 D057712B204 for ; Wed, 28 Sep 2016 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, 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 hznT_Eb-7Hy9 for ; Wed, 28 Sep 2016 09:11:53 -0700 (PDT) Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) by ietfa.amsl.com (Postfix) with ESMTP id 003C612B1F4 for ; Wed, 28 Sep 2016 09:11:52 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by loire.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id u8SGBoJP031181; Wed, 28 Sep 2016 17:11:50 +0100 Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id u8SGBmNx013505; Wed, 28 Sep 2016 17:11:50 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u8SGBmlv025529; Wed, 28 Sep 2016 17:11:48 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u8SGBktO025527; Wed, 28 Sep 2016 17:11:46 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John C Klensin References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 28 Sep 2016 17:11:46 +0100 In-Reply-To: (John C. Klensin's message of "Sun\, 25 Sep 2016 13\:09\:11 -0400") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at loire.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.16.10 Archived-At: Cc: urn@ietf.org Subject: Re: [urn] version -18 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, 28 Sep 2016 16:11:57 -0000 John C Klensin writes: > ... > The suggestion below was strongly stimulated by your note, > especially by the section titled "*3985 Algorithm*" (sic). Oops :-( > I believe, even more strongly than I did before, that saying more > about relative references in 2141bis just gets us into more trouble > and that we should say less, ideally almost nothing. Works for me. > Consequently, I suggest that we remove all of the present > discussion of relative resolution from 2141bis and replace it > with two statements, exact wording to be determined, but whose > substance should be (the footnotes should probably not be part > of the statement(s), but that is an editorial matter): > > (i) A system that encounters a [1] 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.[2] Yes. > (ii) 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 > self-contained, specifically including those that would > require processing of . [3] Not at all sure what you mean by " that is not self-contained". I _think_ what you mean is captured by this rewrite: (ii) Because the result of (i) may well fail to be a valid URI, using a URN to identify a resource (any of) whose representation(s) may contain s should be avoided. > ... > [2] Finding an appropriate Base URI is a 3986 problem, > not a URN one. If such a Base URI cannot be found in an > acceptably unambiguous way, that is a 3986 problem too. > If the community concludes that more advice (or > requirements) are required about edge or failure cases > than 3986 provides, that is a 3986-bis or 3986 update > matter, not a URN one. I'd actually argue that its a delivery-protocol problem, but the distinction is moot, since what matters is that it's _not_ a urnbis problem. > ... > In particular, I note that > >> advice to resolvers that _deliver_ >> resource representations which may contain relative >> references to be sure to deliver them in such a way that the >> base URI _for that representation_ does use an appropriate >> hierarchical locator scheme, e.g. http: or https:. > > is really advice for an improvement to 3986 because it is > independent of whatever scheme might be associated with the > resource representation and makes a scheme-independent (except > by example) statement about appropriate base URIs. Very true -- the intentional advantage of the passive voice in my reformulation of (ii) above is that it leaves open the question of who might be in a position to do the avoiding -- authors might be (your formulation), resolvers might be (the bit of my message you quote immediately above), user agents might be, etc. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Wed Sep 28 12:15:48 2016 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 47DA912B2D5 for ; Wed, 28 Sep 2016 12:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 cUKg0qLBibIK for ; Wed, 28 Sep 2016 12:15:45 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284B212B335 for ; Wed, 28 Sep 2016 12:15:44 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bpKKS-000NKi-M8; Wed, 28 Sep 2016 15:15:40 -0400 Date: Wed, 28 Sep 2016 15:15:35 -0400 From: John C Klensin To: "Henry S. Thompson" Message-ID: In-Reply-To: References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.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: Cc: urn@ietf.org Subject: [urn] Relative references in 2141bis (was: Re: version -18) 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, 28 Sep 2016 19:15:47 -0000 --On Wednesday, September 28, 2016 17:11 +0100 "Henry S. Thompson" wrote: > John C Klensin writes: >... >> Consequently, I suggest that we remove all of the present >> discussion of relative resolution from 2141bis and replace it >> with two statements, exact wording to be determined, but whose >> substance should be (the footnotes should probably not be part >> of the statement(s), but that is an editorial matter): >> >> (i) A system that encounters a [1] 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.[2] > > Yes. > >> (ii) 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 >> self-contained, specifically including those that would >> require processing of . [3] > > Not at all sure what you mean by " that is not > self-contained". I could have said " that is not strictly a as specified in RFC 3986." > I _think_ what you mean is captured by this > rewrite: > > (ii) Because the result of (i) may well fail to be a valid > URI, using a URN to identify a resource (any of) whose > representation(s) may contain s should be > avoided. Actually, I think the part about persistence and stability expectations is important, in part because it makes the recommendation squarely about URNs and anchors that in URN reasons. It thereby avoids cases implied by the "may" in the 3986 discussion of non-strict parsers that I get a headache when I try to think about. I think your rewrite drifts back toward interpretations of 3986, but see also below. I'm ok with your version if that is what others prefer. >> ... >> [2] Finding an appropriate Base URI is a 3986 problem, >> not a URN one. If such a Base URI cannot be found in an >> acceptably unambiguous way, that is a 3986 problem too. >> If the community concludes that more advice (or >> requirements) are required about edge or failure cases >> than 3986 provides, that is a 3986-bis or 3986 update >> matter, not a URN one. > > I'd actually argue that its a delivery-protocol problem, but > the distinction is moot, since what matters is that it's _not_ > a urnbis problem. Exactly. And, again, I was not proposing to put that in the document. >... > Very true -- the intentional advantage of the passive voice in > my reformulation of (ii) above is that it leaves open the > question of who might be in a position to do the avoiding -- > authors might be (your formulation), resolvers might be (the > bit of my message you quote immediately above), user agents > might be, etc. Whether I agree or not about the details above, we definitely agree that 2141bis should not address the issue. For those who are reading this, please remember that 2141bis started out saying nothing, or virtually nothing, about relative references. The text we are now talking about went in because some WG participants insisted on it. I'm delighted to be discussing the details of taking it back out but, before we do, I'd like to be confident that those who want details of relative references in 2141bis have been convinced by the argument against doing to -- I don't want to spend weeks and a draft or two getting to minimal text only to have to put the longer explanation back in again. Co-chairs, please figure out how (and if and when) to make a consensus call on this subject. john From nobody Wed Sep 28 12:27:20 2016 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 44F9412B490 for ; Wed, 28 Sep 2016 12:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 gtGnu-h1hs8m for ; Wed, 28 Sep 2016 12:27:15 -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 EDCDF12B480 for ; Wed, 28 Sep 2016 12:27:13 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bpKVc-000NOh-Hm for urn@ietf.org; Wed, 28 Sep 2016 15:27:12 -0400 Date: Wed, 28 Sep 2016 15:27:07 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <4300B72BD83BBBC17FAF1699@JcK-HP8200> 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: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] FWD: I-D Action: draft-ieee-urn-02.txt 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, 28 Sep 2016 19:27:18 -0000 I don't see any particular issues with this (and have not studied it) but, on the theory that this WG should see all URN requests... john ---------- Forwarded Message ---------- Date: Wednesday, September 28, 2016 10:09 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ieee-urn-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : URN Namespace for IEEE Author : Angela Thomas Filename : draft-ieee-urn-02.txt Pages : 6 Date : 2016-09-28 Abstract: This document describes the Namespace Identifier (NID) 'ieee' for Uniform Resource Names (URNs) used to identify resources published by the Institute of Electrical and Electronics Engineers (IEEE). IEEE specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the IEEE Registration Authority. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ieee-urn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ieee-urn-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ieee-urn-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---------- End Forwarded Message ----------