From nobody Wed Oct 1 05:05:33 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7E11A037E for ; Wed, 1 Oct 2014 05:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdQZpVCMlp7S for ; Wed, 1 Oct 2014 05:05:29 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EB11A0397 for ; Wed, 1 Oct 2014 05:05:26 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s91C5Ncn003969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 1 Oct 2014 15:05:28 +0300 Message-ID: <542BEDFE.8050501@helsinki.fi> Date: Wed, 01 Oct 2014 15:05:18 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: urn@ietf.org References: <201409060307.s86371n6031692@hobgoblin.ariadne.com> <8CCBED81E6F16B40F76AD624@JcK-HP8200.jck.com> In-Reply-To: <8CCBED81E6F16B40F76AD624@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Lp97bq8T_q9OoPItxMa1mjyq6rg Subject: Re: [urn] Names and derived identifiers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 12:05:32 -0000 Hello Dale; John, Comments to the three examples: >> Example 1: Adding a "fragment" part to a URN >> >> Let us assume that is the >> name of an HTML document. (I have administrative authority >> over that part of the OID tree, so I can make it so!) And let >> us suppose that one of the tags in the document has a >> "name" attribute with value "section1". Then (given how >> "fragment" is used in HTML URLs), it would be reasonable to >> define that >> references that location within that (abstract) HTML document. + 1. > But 3986 explicitly binds fragments to media type, so, unless > either every OID or your particular OID has a media type, that > discussion leads to a very odd place. In addition, as > previously discussed on-list and reflected in Appendix B.3 of > the current draft, there is a case to be made that the fragment > to which you refer is really a property of the HTML document and > not the OID or URN. As such, the syntax you are looking for > might be more like > > > I don't believe that, but the distinction is very fine indeed > and one that the WG may need to address. Fragments can be added to URNs if the identifier assignment rules in the namespace in question (or in a subset of that namespace) require that identifiers are applied to one manifestation of the resource only. ISBN meets that requirement (unless someone is misusing the system, but we do not need to consider that option here). In the URN context, the philosophically most acceptable solution is to say that the fragment indicates a location within a resource that is identified with the URN. A user can add a fragment any time after that URN has been assigned, provided that the media type (file format) of the identified resource allows that. > >> Example 2: Footnoting a page >> >> Sitting in front of me is a copy of the book edition with ISBN >> 978-1-59403-698-9. That book edition has the URN >> . >> >> Suppose we define an extension to the syntax to allow >> reference to a specific page of a book denoted by an ISBN: >> . (Here, I deliberately use >> the character "^" for the extension; "^" is not valid in URIs, >> and so I cannot be thought to be advocating any particular >> syntax.) This construction would be useful for scholarly >> citations. > Of course, your doing that as part of the URN requires that you > have an agreement with the particular publisher that all > instances of objects that they associate with the ISBN have the > same pagination properties. I don't believe that is a > requirement of the ISBN standard. Whether it is or not, I know > (as Juha has also pointed out), publisher assignments of ISBNs > are sometimes more flexible. Just an aside: with new electronic formats such as HTML 5 and CSS 3, page numbers are getting meaningless. For referencing purposes it will be better to use logical components of resources such as chapters and paragraphs. > >> Example 3: Retrieving bibliographic information >> >> Suppose there is a standard for providing the metadata >> (bibliographic data) about a resource. This has been called >> "URC" (Uniform Resource Characteristics) in RFC 2169. Then we >> could standardize that >> is the identifier >> of the metadata regarding . >> (Of course, this does not address how we obtain the metadata, >> it only defines a standard identifier with which to refer to >> it.) > I'll let you and Juha (and others who are interested) debate > whether that form is an identifier or a service request. I hope > that, in the process, you will explain to the rest of us how the > distinction moves the work of the WG forward. Libraries etc. do not use the same identifier system for resources and metadata records which describe those resources. Such solution would be cumbersome to maintain. One cannot safely assume that there is 1:1 relation between resources and metadata records about these resources. Of course, metadata records do contain the identifier / identifiers of resources / works. There are a lot of standards for providing (bibliographic and administrative) metadata about resources. IETF tried to develop one (URC) but decided not to, which was wise. Building and maintaining a metadata format is a major commitment. It is feasible to create a service request for retrieving metadata about the identified resource. But a user must be able to specify the preferred metadata format. So instead of this: urn:oid:1.3.6.1.4.1.14490.21.312^metadata you might say something like this: urn:oid:1.3.6.1.4.1.14490.21.312?s=I2C&p=DC or even urn:oid:1.3.6.1.4.1.14490.21.312?s=I2C&p=DC&p=simple to indicate that you want a (simple) Dublin Core metadata record describing the identified resource. This URN is then passed on to a resolver which migrates it into something that is understood as search request by a relevant target system. Juha > >> ... > best, > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Wed Oct 1 18:34:16 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7DF1A8889 for ; Wed, 1 Oct 2014 18:34:14 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQsOGy3HDTCV for ; Wed, 1 Oct 2014 18:34:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0687.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:687]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3231A8888 for ; Wed, 1 Oct 2014 18:34:12 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 2 Oct 2014 01:33:49 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.1039.011; Thu, 2 Oct 2014 01:33:49 +0000 From: Larry Masinter To: Juha Hakala , "urn@ietf.org" Thread-Topic: [urn] Names and derived identifiers Thread-Index: AQHPyX/QCeo2Z4vJHUC4PVOi+eqhlJvzrjuAgCeetACAAN+0MA== Date: Thu, 2 Oct 2014 01:33:49 +0000 Message-ID: References: <201409060307.s86371n6031692@hobgoblin.ariadne.com> <8CCBED81E6F16B40F76AD624@JcK-HP8200.jck.com> <542BEDFE.8050501@helsinki.fi> In-Reply-To: <542BEDFE.8050501@helsinki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2601:9:8380:992:cca:48ec:142b:9159] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR02MB306; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(85306004)(105586002)(106356001)(87936001)(64706001)(76482002)(2656002)(85852003)(10300001)(92566001)(106116001)(99286002)(120916001)(33646002)(95666004)(108616004)(19580395003)(107886001)(54356999)(4396001)(50986999)(21056001)(76176999)(99396003)(101416001)(46102003)(80022003)(2501002)(107046002)(97736003)(86362001)(15202345003)(31966008)(74316001)(20776003)(76576001)(15975445006)(3826002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/cTkdtvCJ7KpUP0uB_xcPMz12nlU Subject: Re: [urn] Names and derived identifiers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 01:34:14 -0000 VGhlcmUgYXJlIHR3byB3YXlzIG9mIGFkZHJlc3NpbmcgdGhlIHRlY2huaWNhbCBzcGVjaWZpY2F0 aW9uIG9mIGZyYWdtZW50IGlkZW50aWZpZXJzIGZvciBVUk5zLCBpZiB0aGF0IGlzIGFjdHVhbGx5 IGRlc2lyYWJsZSBhbmQgaW1wbGVtZW50YXRpb25zIGFncmVlIHRvIGJ1aWxkIGFuZCB0ZXN0IGl0 Lg0KDQpUaGUgZmlyc3QgYW5kIHNpbXBsZXN0IGlzIHRvIGRlY2xhcmUgdGhhdCBVUkkgc2NoZW1l cyB0aGF0IGRvbid0IG5vcm1hbGx5IGRlZmluZSBhIHJldHJpZXZhbCBvcGVyYXRpb24gZm9yIGEg cmVwcmVzZW50YXRpb24gYmUgYWxsb3dlZCB0byBkZWZpbmUgbWVhbmluZyBmb3IgZnJhZ21lbnRz LiBUaGlzIGlzbid0IGEgY29tcGF0aWJpbGl0eSBpc3N1ZSBzaW5jZSBpZiB0aGUgc2NoZW1lIGRv ZXNuJ3QgZGVmaW5lIHJldHJpZXZhbCwgdGhlcmUgY2FuJ3QgYmUgYSBNSU1FIHR5cGUuDQoNClRo ZSBzZWNvbmQgYW5kIG1vcmUgc3VidGxlIGlzIHRvIG1ha2UgdXAgYSB2aXJ0dWFsIE1JTUUgdHlw ZSwgc2F5ICJhcHBsaWNhdGlvbi91cm4tcmV0cmlldmFsLXJlc3VsdCIgYW5kIGRlZmluZSBmcmFn bWVudCBpZGVudGlmaWVycyBmb3IgdGhhdCBNSU1FIHR5cGUuICBNYWtlIGFwcGxpY2F0aW9uL3Vy bi1yZXRyaWV2YWwtcmVzdWx0IGNvbnRhaW4gJ2xhbmRpbmcgcGFnZScgaW5mb3JtYXRpb24uICBU aGVuIGRlZmluZSAncmV0cmlldmFsJyBmb3IgdXJuOiBVUklzIGFzIGFjY2Vzc2luZyB1c2luZyB3 aGF0ZXZlciBtZXRob2QgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBVUk4gbmFtZXNwYWNlLCBidXQg d2hpY2ggcmV0dXJucyBhIHZpcnR1YWwgYXBwbGljYXRpb24vdXJuLXJldHJpZXZhbC1yZXN1bHQu DQoNClRoYXQgd2F5IHlvdSBnZXQgJ29mZmljaWFsJyAzOTg2IGludGVycHJldGF0aW9ucy4gRnJh Z21lbnQgaWRlbnRpZmllcnMgYXJlIGRlZmluZWQgYnkgdGhlIE1JTUUgdHlwZSwgYnV0IHdlIGFk ZCBvbmUgTUlNRSB0eXBlIHRvIGRvIHRoZSB3b3JrIG9mIGxpZnRpbmcgdGhlIGZyYWdtZW50Lg0K DQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0K From nobody Wed Oct 1 23:34:44 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604811A0102 for ; Wed, 1 Oct 2014 23:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owrJuYTY9Uqk for ; Wed, 1 Oct 2014 23:34:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C3B1A00FF for ; Wed, 1 Oct 2014 23:34:33 -0700 (PDT) Received: from [192.168.178.36] ([93.217.83.140]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LkOaJ-1Y7H1n2BIJ-00cTNT; Thu, 02 Oct 2014 08:34:24 +0200 Message-ID: <542CF1E9.5040102@gmx.de> Date: Thu, 02 Oct 2014 08:34:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Larry Masinter , Juha Hakala , "urn@ietf.org" References: <201409060307.s86371n6031692@hobgoblin.ariadne.com> <8CCBED81E6F16B40F76AD624@JcK-HP8200.jck.com> <542BEDFE.8050501@helsinki.fi> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8dvZBgXRLoa88lqpf2XD00bSEZrPGD9EYD5Z0cgYKr/TmYpjBs0 yb/b2BOTXU5qBFuT/JyhFRQBxYFq1Bv/jPL0CqZ4dxWgJhjwlo0YXejJSyXjLLyErj2ZaGq a+wY0bw9XIjAWgr+XOLlNbNCEJgApnNIYgsG0FszpX+EIWTKD5Ef/n4JfkSYwOY2/IqtOZx jULlHTOmdbDw5G8wHpGLQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/DQehIG-VVruLCHdkepXvrswW1pY Subject: Re: [urn] Names and derived identifiers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 06:34:37 -0000 On 2014-10-02 03:33, Larry Masinter wrote: > There are two ways of addressing the technical specification of fragment identifiers for URNs, if that is actually desirable and implementations agree to build and test it. > > The first and simplest is to declare that URI schemes that don't normally define a retrieval operation for a representation be allowed to define meaning for fragments. This isn't a compatibility issue since if the scheme doesn't define retrieval, there can't be a MIME type. > ... What happens if a resolving service actually makes that URN resolvable? Best regards, Julian From nobody Wed Oct 15 15:12:33 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B471ACDDD for ; Wed, 15 Oct 2014 15:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a4LDFJOLSVq for ; Wed, 15 Oct 2014 15:12:29 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15591ACDC1 for ; Wed, 15 Oct 2014 15:12:28 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id a13so18367878igq.1 for ; Wed, 15 Oct 2014 15:12:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BXljaE0fyJt3sG2OozSZ6OcTDxdL7hhcpp/K35qRi1k=; b=CYGr7u4IOdVpMxyew8VjOMW+Dk53prxLhVWi2z63CxaEGid5NAkQxLUdvzM7vt994y yXZcLanB9L/uO0BIunql9XaBGJU9YE/TFDG8qIOZlmkrOfwf5Fz87A+qSzISSHsgpYNy 08anDVeefpeTfI/LiQww2DkVOyCL0csK1tzTYE3GnSao6GGD7hqbUpSzRbBUmex4aEo1 tKuqo46ibnB/sMDjlekgULdOsD+8hYjHicLtORExPJ0RHcwcTLOr8ZkLDyg13cpDyZ9F 6OYYXTi79rue+RyWwuj4ZZ5bFnaK9WR7lS4uUNeYMIxB33/Ij9ZAknkruP0nGhTz6NR8 lVFQ== X-Gm-Message-State: ALoCoQlddKpp78O2YIJ3sQbf5N+oLNVa0hTEivQlE+EHiUfO9fYpstFZBQt15n6fw9zADWUPfJOk X-Received: by 10.42.190.6 with SMTP id dg6mr520073icb.13.1413411148096; Wed, 15 Oct 2014 15:12:28 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id dx10sm13586343igb.4.2014.10.15.15.12.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 15:12:27 -0700 (PDT) Message-ID: <543EC8A6.5010604@andyet.net> Date: Wed, 15 Oct 2014 12:19:02 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , "Dale R. Worley" , urn@ietf.org References: <20140826001727.20837.82843.idtracker@ietfa.amsl.com> <201409052052.s85KqMcZ010849@hobgoblin.ariadne.com> <630C2513ADFE8871D5CA6C07@JcK-HP8200.jck.com> In-Reply-To: <630C2513ADFE8871D5CA6C07@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/xtWWEOepexRzPdH130KnCpLwRr0 Subject: Re: [urn] Wording draft-ietf-urnbis-semantics-clarif-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 22:12:31 -0000 On 9/5/14, 11:37 PM, John C Klensin wrote: > > --On Friday, September 05, 2014 16:52 -0400 "Dale R. Worley" > wrote: >> This goes back to the fact that we've been sloppy about the >> distinction between "URN" (per RFC 3986, things that have the >> "name" properties, that is, "identifiers" in Juha's >> terminology), and things with the scheme "urn". > > This issue was also addressed in that earlier thread, although > less directly so. I intentionally did not include it in Section > 6 and left out precisely because it relates to what this > document says (relevant only if we are going to publish it) > rather than the core substance of the WG's work. As illustrated > by the thread Leslie started, both she and I (and, I believe > from earlier threads and discussions) believe that the language > of 3986 that says there are URNs that don't follow the "urn:" > scheme is undesirable and has little value unless the goal is to > create confusion. At least in retrospect, it probably should > have said something more like "there are names and naming system > that may be URIs but are not URNs". The WG needs to decide > whether it wants to address that topic, whether it wants to > address it in a successor to this document and, if so, what it > wants to say. The current draft intended to sidestep the > issue. Another alternative would be to "update" it out of 3986 > but it is hard to do that without formally criticizing 3986. > Such criticisms seem to be painful out of proportion to their > value in moving the present URN work forward. Then we can make > any documents we intend to publish consistent with that decision. Although I agree that it's useful to limit URNs to things that follow the URI syntax and begin with the "urn:" scheme (calling nothing else a URN even if it feels like a name), I don't think it's a good idea to spend this working group's limited energy in fighting the battle of changing RFC 3986 on this point. Peter -- Peter Saint-Andre https://andyet.com/ -- Peter Saint-Andre https://andyet.com/ From nobody Wed Oct 15 15:12:38 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82C31ACDC1 for ; Wed, 15 Oct 2014 15:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1bSOOK4xoDO for ; Wed, 15 Oct 2014 15:12:30 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E45C1ACDC9 for ; Wed, 15 Oct 2014 15:12:30 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id uq10so2312587igb.13 for ; Wed, 15 Oct 2014 15:12:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A7U7FtzQ0h2JM/arCt7Gt7pKeU5CFTUcl3OtJ2RD7AU=; b=C2gH+gsqJ/p12vEdv4UarAmOjDH7dXgVlTbrYNgVy5aYoUdxxcQInjSvV2kApfcSXg kfGyDon0Al7azRE3C+jLHRYo2NBvZa4CoJOEDH+85kMtXR8m5reoPOkhAocaS3F2vy2q QiomqODGymNanUIdVGwR/YuUURWhCKHegG8h/T25o6Z0ZgIuJ+mcbgBUwYuFeJff+W6v g0B2Om1suFPq7uIpxWV+45wiDso45gPVSNV/8MaoEYz0MlT4ln13bZ8gXF5wqw3VpSAw HTQyaQDeFTonaHOq8u8EAEunjGtk7idCSFiH+JOsVnyklwi6NmmhuJMi99wQmvbUGxzA Go3g== X-Gm-Message-State: ALoCoQlAuB8QRUmrM8G3XfShmbnVF1PzBB+8m8YKXNc6gqlKUIv0FGw+L4HUNDumF/eDgbtJ721t X-Received: by 10.42.25.204 with SMTP id b12mr629057icc.14.1413411149450; Wed, 15 Oct 2014 15:12:29 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id q8sm2350499ioe.1.2014.10.15.15.12.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 15:12:28 -0700 (PDT) Message-ID: <543ECE30.20302@andyet.net> Date: Wed, 15 Oct 2014 13:42:40 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , Andrew Newton References: <540732E3.4090203@thinkingcat.com> <8637CF4A96E67FB23B5ACA13@JcK-HP8200.jck.com> <5408EA74.9080803@thinkingcat.com> <78A7111695783FBD69408759@JcK-HP8200.jck.com> <1DE44C0E1F19BFB66DE7801A@JcK-HP8200.jck.com> In-Reply-To: <1DE44C0E1F19BFB66DE7801A@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/SWOtnUsjQilzmHY5So-XaiGSvF0 Cc: urn@ietf.org Subject: Re: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 22:12:33 -0000 On 9/8/14, 9:50 AM, John C Klensin wrote: > > > --On Monday, September 08, 2014 10:42 -0400 Andrew Newton > wrote: > >> On Thu, Sep 4, 2014 at 9:42 PM, John C Klensin >> wrote: >>> >>> In both cases, we more or less need to realize that we are >>> already very far down the path to multiple types and uses of >>> URNs and that they come with different requirements. If there >>> were a collection of requirement spaces or subspaces, the >>> "pure identifier" or "indicator" uses might lie at one >>> extreme and the "URN instantiation of sundry well-established >>> external standards and management systems" (e.g., ISBNs and >>> ISSNs) might lie somewhat else (not necessarily at an >>> extreme. If we take the first approach and get it wrong, we >>> will almost certainly discover that we've run out of >>> extension room and that anything else that comes along and >>> belongs in the requirement space needs, e.g., a URS (Uniform >>> Resource Snafu), more or less along the lines of the "new >>> scheme" model proposed in Toronto. Maybe that would be an ok >>> outcome. But, if we want the URN umbrella to cover as much >>> of the requirements space as possible, generality is probably >>> our friend. >> >> I think generality is a good thing, but I wonder if we have >> enough people/bandwidth to do it. >> (fyi, that's just me thinking aloud, not guidance) > > Given the relatively small number of people who seem willing and > able to engage on the broad issues on an ongoing basis, as > distinct from focusing narrowly on some particular set of > applications and/or preserving the view of what URNs are able > that is reflected in RFC 3986, I think there is reason at this > point to believe that we do not. > > On the other hand, if we don't go for the generality, I think > there is a real and serious question about whether the WG should > continue to work on developing a solution for which > counterexample to the hypothesis of adequacy are likely. Put > differently, the IETF can cause, or contribute to, a fork by > doing a job that doesn't meet some needs or we can do it by > giving up. The latter is obviously unattractive, but might be > less painful for those of us who seem to be doing a > disproportionate fraction of the work. I don't think anyone here wants a fork, which is why we're still engaged in activity (to the extent we are). >>>>> I want to agree with you. But Section 1.1.3 appears to say >>>>> that the term "URN" refers to both the URN scheme (i.e., >>>>> what 2141 defines) and lots of other things ("any other URI >>>>> with the properties of a name"). >>>> >>>> Okay. IMNSHO, that means RFC3986 is broken and that should >>>> have been caught at the time, but I appreciate the political >>>> sensitivities (then and now) and am willing to flag it as >>>> something to come back and fix if possible. >>> >>> While you conclude from this that 3986 is broken and I, >>> personally, agree with you, it was clear in Toronto (and on >>> the mailing list before and after) that the WG does not have >>> consensus on that point. >> >> Even if we did have consensus on that (and we may), it is also >> irrelevant. The AA serenity prayer comes to mind here. > > It isn't irrelevant if --as I think some people have suggested > (or nearly so)-- the WG decides to suspend work until 3986bis > can be completely and agreed to. As I have said in response to > those suggestions before, I believe that, in practice, that > would be just a different way to give up, but that is just my > opinion. Agreed. >>> Wfm. By the way, I intend to start pulling text out as soon >>> as the WG and Andy will let me. That should not be before >>> 2141bis-08 appears, but my goal was to get all of the text >>> into one document that people could look at and think about, >>> then remove everything that was not clearly relevant. So, if >>> it is possible to make good progress from this point, I'd >>> expect that most of the text that might be confusing would >>> have disappeared before your six months are up. >> >> Rip it out! We always have the historical versions. > > I'm on travel or otherwise out of pocket for almost 3/4 of this > month and October is unlikely to= be better. As a result you are > going to get at most one more draft in the next two or three > weeks and probably no more than one more in October. So I will > tentatively start, but really would prefer to see 2141bis before > I post. I'll go ahead and generate a stripped-down version > without it if Peter tells us that we shouldn't expect that draft > any time soon but, so far, I gather we are on schedule for the > next day or two. Those hopes were dashed. However I am spending time and thought now to catch up and figure out what might need to change in 2141bis. (Of which I consider myself very much an editor at the disposal of the WG.) Peter -- Peter Saint-Andre https://andyet.com/ -- Peter Saint-Andre https://andyet.com/ From nobody Wed Oct 15 18:26:17 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD71A0079 for ; Wed, 15 Oct 2014 18:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dpZeg2IuLxO for ; Wed, 15 Oct 2014 18:26:14 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1414B1A0075 for ; Wed, 15 Oct 2014 18:26:14 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XeZpS-000CJi-S2; Wed, 15 Oct 2014 21:26:10 -0400 Date: Wed, 15 Oct 2014 21:26:05 -0400 From: John C Klensin To: Peter Saint-Andre - &yet , "Dale R. Worley" , urn@ietf.org Message-ID: In-Reply-To: <543EC8A6.5010604@andyet.net> References: <20140826001727.20837.82843.idtracker@ietfa.amsl.com> <201409052052.s85KqMcZ010849@hobgoblin.ariadne.com> <630C2513ADFE8871D5CA6C07@JcK-HP8200.jck.com> <543EC8A6.5010604@andyet.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/KE6UaCNQD5t1IVDjE8bj6gZxK7s Subject: Re: [urn] Wording draft-ietf-urnbis-semantics-clarif-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 01:26:16 -0000 --On Wednesday, October 15, 2014 12:19 -0700 Peter Saint-Andre - &yet wrote: > On 9/5/14, 11:37 PM, John C Klensin wrote: >> >> --On Friday, September 05, 2014 16:52 -0400 "Dale R. Worley" >> wrote: > > > >>> This goes back to the fact that we've been sloppy about the >>> distinction between "URN" (per RFC 3986, things that have the >>> "name" properties, that is, "identifiers" in Juha's >>> terminology), and things with the scheme "urn". >> >> This issue was also addressed in that earlier thread, although >> less directly so. I intentionally did not include it in >> Section 6 and left out precisely because it relates to what >> this document says (relevant only if we are going to publish >> it) rather than the core substance of the WG's work. As >> illustrated by the thread Leslie started, both she and I >> (and, I believe from earlier threads and discussions) believe >> that the language of 3986 that says there are URNs that don't >> follow the "urn:" scheme is undesirable and has little value >> unless the goal is to create confusion. At least in >> retrospect, it probably should have said something more like >> "there are names and naming system that may be URIs but are >> not URNs". The WG needs to decide whether it wants to >> address that topic, whether it wants to address it in a >> successor to this document and, if so, what it wants to say. >> The current draft intended to sidestep the issue. Another >> alternative would be to "update" it out of 3986 but it is >> hard to do that without formally criticizing 3986. Such >> criticisms seem to be painful out of proportion to their >> value in moving the present URN work forward. Then we can >> make any documents we intend to publish consistent with that >> decision. > > Although I agree that it's useful to limit URNs to things that > follow the URI syntax and begin with the "urn:" scheme > (calling nothing else a URN even if it feels like a name), I > don't think it's a good idea to spend this working group's > limited energy in fighting the battle of changing RFC 3986 on > this point. I hope it has been clear that I completely agree. I think the WG should be concentrating on the requirements for what it needs and the syntax (within the boundaries of URIs as specified in 3986) and semantics those requirements dictate and fighting as few battles with, or over, 3986 as possible. I think that requires saying that the only URNs that are in scope for the WG are those that use the "urn:" URI scheme. Anything else is, as the saying goes, Someone Else's Problem. john From nobody Thu Oct 16 14:11:55 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176AD1A87A0 for ; Thu, 16 Oct 2014 14:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohDELbWYp-8L for ; Thu, 16 Oct 2014 14:11:49 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF8E1A8882 for ; Thu, 16 Oct 2014 14:11:49 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id rp18so4336890iec.27 for ; Thu, 16 Oct 2014 14:11:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ADPc9K/xh867h2ggCtyjL1kVWugwsMCWNXJpRSb578g=; b=ikVSnnQuFD0VFOPDQ6uBi0YaU5yD5Bp8sRA8VFIuUuI06QSzfQcqEYrspKDNR0gUTC sqLpFEvJlGVYKknKz5ncT6K/FBW9LHfbpnDSxaIK1KEBNg1WNpmI8tA2qsKhstHqLRNb QeanZCDi0qqrb/d2hCD2UykiDpk+nuWfBZF0FOHvmZqmy5o1kPlw3DDS1k/lVGKSDkD5 NEpnnIjVEN7IrzPB+WxeUvBU/2dOvOjpZJd0LeXU29FYM/ABBV9VsNjJtvkjxSJ573P6 73Srva0vcgkDFSqtV8TvEC7LMIX9bRxWRX2XPIkfoafuHjoqbWQ8MXLw3pz/YFC8t6ew U1AQ== X-Gm-Message-State: ALoCoQnC1KloiQFgECBnEpM6swyuIhh0NQpXmjzIXA1Oeg7i4WXPkfusq5AMUrrMijpTVlS18ba6 X-Received: by 10.43.148.74 with SMTP id kf10mr6083870icc.9.1413493908648; Thu, 16 Oct 2014 14:11:48 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j4sm14920191igx.20.2014.10.16.14.11.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 14:11:47 -0700 (PDT) Message-ID: <54403493.5080808@andyet.net> Date: Thu, 16 Oct 2014 15:11:47 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/X2-bxxfY69lAB1Ixkw1L-fVvSIc Subject: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:11:52 -0000 The URNBIS WG seems to be at an impasse. Having reviewed the discussions at and after IETF 90, I'd like to make a proposal. I don't think we will quickly come to agreement on the semantics of paths, queries, and fragments in the context of the "urn:" scheme. (In fact, I suggest that we call them "p-components", "q-components", and "f-components" here so that we don't get bogged down in how their meaning in URNs might be different from their meaning in URIs.) I remain hopeful that we might someday come to such agreement, but as far as I can see it's not productive for us to wait for such agreement before making progress on the two primary tasks on the charter of this WG: updating the URN syntax definitions from RFC 2141 and updating the URN namespace identifier registration procedures from RFC 3406. I think we can complete those tasks in the relatively near future if we decide to do one thing: let go of semantics. That is, I suggest that we update the URN syntax to allow p-components, q-components, and f-components, but leave the semantics of those elements up to specifications that define specific NIDs. Now, some folks might think that's reckless, but I think it's pragmatic. Right now we don't have a clear and distinct idea of how various URN-using communities might put p-components, q-components, and f-components to work in their context. In particular, the needs of various information sciences communities are still not well-known in this WG, despite the heroic efforts of Juha Hakala and a few other folks. This pragmatic approach would enable those communities to complete their work in venues more conducive to involvement by the relevant subject-matter experts. If they are able to make progress there and define the semantics for their use of p-components, q-components, and f-components, then we will have some examples from which we can abstract broader definitions of semantics (if and when we decide that such an effort might be necessary). In the meantime, the semantics might differ by NID. Although it's good to be aware of that possibility, I think the risks involved with NID-specific semantics are smaller than the risks involved with not completing our work, leaving the syntax as it is in RFC 2141, and then having URNs forked because communities that are trying to solve real-world problems will use q-components and f-components (and perhaps p-components) no matter what RFC 2141 says. I see at least two open issues here: First, how will comparison work? I suggest that q-components and f-components would not be factored into comparison, but that p-components would be factored in (if they end up being used). Second, how is the syntax within p-components, q-components, and f-components defined? I suggest that it isn't, at least not in 2141bis. Particular NID specifications could, however, define intra-component syntax to meet their needs. Third, under this approach would we still be comfortable with a NID registration policy of Expert Review? I would be, but I can't speak for anyone else. (Naturally, there might be other open issues, as well.) I'm wondering what WG participants think about this approach. If it is acceptable, I can update 2141bis and 3406bis accordingly (I think that the changes would be relatively minor, and I could make them before the I-D submission deadline on October 28th). Thanks for your consideration. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Oct 16 15:04:25 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9359F1A8ACB for ; Thu, 16 Oct 2014 15:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swUIFeZLEB2g for ; Thu, 16 Oct 2014 15:04:22 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805201A8029 for ; Thu, 16 Oct 2014 15:04:22 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xet9h-000ELe-7D; Thu, 16 Oct 2014 18:04:21 -0400 Date: Thu, 16 Oct 2014 18:04:16 -0400 From: John C Klensin To: Peter Saint-Andre - &yet , urn@ietf.org Message-ID: <446E81991A00A531E7AA9B2B@JcK-HP8200.jck.com> In-Reply-To: <54403493.5080808@andyet.net> References: <54403493.5080808@andyet.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Hp82DppgecdKj22TNLZ4QBBdYDA Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:04:24 -0000 Hi. Speaking only for myself, I've come to conclusions about the state of the WG and the likelihood of making significant progress in the near future similar to Peter's. Much as I'd like to see a Grand Unified URN model, I think we are too divided about expectations of what URNs are likely to do for us and how to reach consensus conclusions about that any time soon. Peter's suggestion builds on some things I started to explore on list and in draft-ietf-urnbis-semantic-clarif but he figured out the logical next steps which I was unable to put together. A few comments inline below. --On Thursday, October 16, 2014 15:11 -0600 Peter Saint-Andre - &yet wrote: > The URNBIS WG seems to be at an impasse. Having reviewed the > discussions at and after IETF 90, I'd like to make a proposal. > > I don't think we will quickly come to agreement on the > semantics of paths, queries, and fragments in the context of > the "urn:" scheme. (In fact, I suggest that we call them > "p-components", "q-components", and "f-components" here so > that we don't get bogged down in how their meaning in URNs > might be different from their meaning in URIs.) > I remain hopeful that we might someday come to such agreement, > but as far as I can see it's not productive for us to wait for > such agreement before making progress on the two primary tasks > on the charter of this WG: updating the URN syntax definitions > from RFC 2141 and updating the URN namespace identifier > registration procedures from RFC 3406. While I remain hopeful too, I'm now pessimistic about whether it will ever be possible to reach such an agreement on other than a "cluster of uses" or "community of users" basis. It appears to me that the list of things for which people intend to use URNs is just too diverse for much unification unless we somehow make draconian rules and expect people to follow them. I think there is ample evidence that the latter won't happen if those rules violate a particular community's idea of good sense. > I think we can complete those tasks in the relatively near > future if we decide to do one thing: let go of semantics. That > is, I suggest that we update the URN syntax to allow > p-components, q-components, and f-components, but leave the > semantics of those elements up to specifications that define > specific NIDs. Note that this requires not only letting go of semantics, as Peter points out, but letting go of notions of syntax control across namespaces about how p/q/f-components are structured internally, making that a per-namespace matter. That is, IMO, consistent with RFC 3986 which rather carefully avoids specification of the internal structure of the corresponding generic URI components. >... > In the meantime, the semantics might differ by NID. Although > it's good to be aware of that possibility, I think the risks > involved with NID-specific semantics are smaller than the > risks involved with not completing our work, leaving the > syntax as it is in RFC 2141, and then having URNs forked > because communities that are trying to solve real-world > problems will use q-components and f-components (and perhaps > p-components) no matter what RFC 2141 says. Concur. > I see at least two open issues here: > > First, how will comparison work? I suggest that q-components > and f-components would not be factored into comparison, but > that p-components would be factored in (if they end up being > used). > > Second, how is the syntax within p-components, q-components, > and f-components defined? I suggest that it isn't, at least > not in 2141bis. Particular NID specifications could, however, > define intra-component syntax to meet their needs. Agreed. See above. This will imply that we need to put even more emphasis on clear and comprehensive registration descriptions, but we have, at least IMO, been moving in that direction anyway. > Third, under this approach would we still be comfortable with > a NID registration policy of Expert Review? I would be, but I > can't speak for anyone else. I am, but with a fairly liberal interpretation of Expert Review. In particular, I think we should be looking at a sort of editorial advisory board model in which the role of the reviewer or review team had much more to do with explaining the system and advocating for completeness and clarity than making pass/fail decisions. john From nobody Thu Oct 16 15:51:56 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D081A8AEC for ; Thu, 16 Oct 2014 15:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R92znM2jVDoM for ; Thu, 16 Oct 2014 15:51:43 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5F61A8AEB for ; Thu, 16 Oct 2014 15:51:25 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so4514276iec.15 for ; Thu, 16 Oct 2014 15:51:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b+QKX4do79Mok45oKUIi//8HURCOSv6xQSMyS71KSLk=; b=OqAcSPEyGB7RzExNFPFNlb/JsF11YobjyVNrQgrnD21DPAQjks4+kNHH/c0+27X/EE K31MKAd0oWu48HX2zDXK0Ct4UinOqelGuqqQHONrP1Ic/WdSzWvE3TceABxDjRFRaJLy PuqJJ++ukx9lAdSIS2L8QEX7NyNUVbmfvy55G6v1HXLYWk1HaT6+CmcwXKDfPFxVRNxC EHFaETzh0eikT7Hn9CkXiC7w003go1LPjsHIv3s0DABp0Q8zbaWd6O18cSD4Kh7gC0pi wjqnisuaAMDejvmxPFXCJ6miAGW2TZ8OS7yT9VEbWZAjqnziqB5Q8oTiZBu55kzi58tc ONHQ== X-Gm-Message-State: ALoCoQmpFKLDFPRUED+/tni9rC8o8344Zqdj5Jy5pY1Cn8cq3TbgVm5DAUAD/tgLuO14+iIfYVoJ X-Received: by 10.50.41.99 with SMTP id e3mr8308794igl.41.1413499884507; Thu, 16 Oct 2014 15:51:24 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id h8sm3771159ioh.35.2014.10.16.15.51.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 15:51:24 -0700 (PDT) Message-ID: <54404BEB.4090701@andyet.net> Date: Thu, 16 Oct 2014 16:51:23 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <54403493.5080808@andyet.net> <446E81991A00A531E7AA9B2B@JcK-HP8200.jck.com> In-Reply-To: <446E81991A00A531E7AA9B2B@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/X0cObekdtWlkTX67J_M_7N-irBY Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:51:46 -0000 Thanks, John. A few additional comments inline. On 10/16/14, 4:04 PM, John C Klensin wrote: > --On Thursday, October 16, 2014 15:11 -0600 Peter Saint-Andre - > &yet wrote: >> I see at least two open issues here: Actually I listed three... >> First, how will comparison work? I suggest that q-components >> and f-components would not be factored into comparison, but >> that p-components would be factored in (if they end up being >> used). >> >> Second, how is the syntax within p-components, q-components, >> and f-components defined? I suggest that it isn't, at least >> not in 2141bis. Particular NID specifications could, however, >> define intra-component syntax to meet their needs. > > Agreed. See above. This will imply that we need to put even > more emphasis on clear and comprehensive registration > descriptions, but we have, at least IMO, been moving in that > direction anyway. Good point. We'll need to revisit 3406bis on this topic. I suspect that it will require further work. >> Third, under this approach would we still be comfortable with >> a NID registration policy of Expert Review? I would be, but I >> can't speak for anyone else. > > I am, but with a fairly liberal interpretation of Expert Review. > In particular, I think we should be looking at a sort of > editorial advisory board model in which the role of the reviewer > or review team had much more to do with explaining the system > and advocating for completeness and clarity than making > pass/fail decisions. Yes. Over time, I would hope that the review board members would find patterns across registrations so that they could encourage sharing of information across the "communities of use" you mentioned. I don't know that this would be a formal suggestion to such a board, but I at least would hope for it as an outcome. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Oct 17 04:57:59 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEA41ACCE8 for ; Fri, 17 Oct 2014 04:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEJ43pyFkz7o for ; Fri, 17 Oct 2014 04:57:53 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4634B1ACC84 for ; Fri, 17 Oct 2014 04:57:53 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s9HBvs5j027640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 14:57:55 +0300 Message-ID: <5441043D.4050207@helsinki.fi> Date: Fri, 17 Oct 2014 14:57:49 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> In-Reply-To: <54403493.5080808@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/iG32YwEhl8ejvKNYC176ZntGhKg Cc: Maarit Huttunen , =?windows-1252?Q?Pekka_?= =?windows-1252?Q?J=E4rvel=E4inen?= , Laila Heinemann Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 11:57:58 -0000 Hello Peter, I hope that what you suggest below provides a basis for (rough) consensus in the WG. As far as I can tell, what you are suggesting would enable the information sciences community to create a new generation of URN resolvers, without creating a fork - our own, enriched version of the URN syntax and other URN specifications which would be managed outside IETF - in ISO, for instance. Some comments below. On 17.10.2014 0:11, Peter Saint-Andre - &yet wrote: > The URNBIS WG seems to be at an impasse. Having reviewed the > discussions at and after IETF 90, I'd like to make a proposal. > > I don't think we will quickly come to agreement on the semantics of > paths, queries, and fragments in the context of the "urn:" scheme. (In > fact, I suggest that we call them "p-components", "q-components", and > "f-components" here so that we don't get bogged down in how their > meaning in URNs might be different from their meaning in URIs.) If this the only way this WG can complete its task, then so be it. > > I remain hopeful that we might someday come to such agreement, but as > far as I can see it's not productive for us to wait for such agreement > before making progress on the two primary tasks on the charter of this > WG: updating the URN syntax definitions from RFC 2141 and updating the > URN namespace identifier registration procedures from RFC 3406. > > I think we can complete those tasks in the relatively near future if > we decide to do one thing: let go of semantics. That is, I suggest > that we update the URN syntax to allow p-components, q-components, and > f-components, but leave the semantics of those elements up to > specifications that define specific NIDs. Since there is a need to harmonize things done with q-component across multiple namespaces, it is an additional burden to create the necessary specifications at NID level. But doing what Peter suggests does not prevent several namespaces from sharing the same specification, which may or may not be published by IETF. > > Now, some folks might think that's reckless, but I think it's > pragmatic. Right now we don't have a clear and distinct idea of how > various URN-using communities might put p-components, q-components, > and f-components to work in their context. In particular, the needs of > various information sciences communities are still not well-known in > this WG, despite the heroic efforts of Juha Hakala and a few other folks. If this approach allows my community to proceed in such a way which meets our needs, fine. I look forward to leaving philosophical discussions concerning semantics of URIs, URNs etc. to IETF. My community did not create that mess, and I am glad if that Gordian knot does not prevent us from moving on any more. If it turns out that even the approach Peter advocates does not enable the WG to reach rough consensus, then it is likely that we shall go our own way, like the Handle community before us. > > This pragmatic approach would enable those communities to complete > their work in venues more conducive to involvement by the relevant > subject-matter experts. If they are able to make progress there and > define the semantics for their use of p-components, q-components, and > f-components, then we will have some examples from which we can > abstract broader definitions of semantics (if and when we decide that > such an effort might be necessary). > > In the meantime, the semantics might differ by NID. Although it's good > to be aware of that possibility, I think the risks involved with > NID-specific semantics are smaller than the risks involved with not > completing our work, leaving the syntax as it is in RFC 2141, and then > having URNs forked because communities that are trying to solve > real-world problems will use q-components and f-components (and > perhaps p-components) no matter what RFC 2141 says. > > I see at least two open issues here: > > First, how will comparison work? I suggest that q-components and > f-components would not be factored into comparison, but that > p-components would be factored in (if they end up being used). OK. > > > Second, how is the syntax within p-components, q-components, and > f-components defined? I suggest that it isn't, at least not in > 2141bis. Particular NID specifications could, however, define > intra-component syntax to meet their needs. This is what we would do for e.g. ISO standard identifiers which have registered URN namespaces. > > Third, under this approach would we still be comfortable with a NID > registration policy of Expert Review? I would be, but I can't speak > for anyone else. Such review would be more complicated, but not impossible. > > > (Naturally, there might be other open issues, as well.) > > I'm wondering what WG participants think about this approach. If it is > acceptable, I can update 2141bis and 3406bis accordingly (I think that > the changes would be relatively minor, and I could make them before > the I-D submission deadline on October 28th). Please proceed. All the best, Juha > > Thanks for your consideration. > > Peter > -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Fri Oct 17 10:34:59 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1C01A0072 for ; Fri, 17 Oct 2014 10:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igVyzicgA9Vw for ; Fri, 17 Oct 2014 10:34:55 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDD61A004D for ; Fri, 17 Oct 2014 10:34:54 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XfBQQ-000GJn-FP; Fri, 17 Oct 2014 13:34:50 -0400 Date: Fri, 17 Oct 2014 13:34:45 -0400 From: John C Klensin To: Juha Hakala , urn@ietf.org Message-ID: <47DEEF8EE5FCB94413D76600@JcK-HP8200.jck.com> In-Reply-To: <5441043D.4050207@helsinki.fi> References: <54403493.5080808@andyet.net> <5441043D.4050207@helsinki.fi> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/6UGFa_s8NNebII9uxD7cjJKNzkY Cc: Maarit Huttunen , =?UTF-8?Q?Pekka_J=C3=A4rvel=C3=A4inen?= , Laila Heinemann Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:34:57 -0000 --On Friday, October 17, 2014 14:57 +0300 Juha Hakala wrote: > Hello Peter, > > I hope that what you suggest below provides a basis for > (rough) consensus in the WG. As far as I can tell, what you > are suggesting would enable the information sciences community > to create a new generation of URN resolvers, without creating > a fork - our own, enriched version of the URN syntax and other > URN specifications which would be managed outside IETF - in > ISO, for instance. I hope Peter will agree, but let me say the above a little differently to be sure we are talking about the same thing. The expectation would be that your "own, enriched version..." would conform to the basic URN syntax. That syntax would be pretty basic, essentially reflecting the same restrictions as RFC 3986. You would also be expected to register each new namespace and NID. I'd hope that, if your community (and others) created a common set of principles and rules for how "your" URNs were structured and would work, new namespaces that conformed to them could be fast-tracked through the registration procedure based on commonality of references and practices. The broad issues about registration practices will still need to be sorted out in this WG's discussions and consensus reached, but Peter and I hope that is a much less difficult problem than trying to sort decisions about URN behavior out globally and across different types of uses and communities. More below. > Some comments below. > > On 17.10.2014 0:11, Peter Saint-Andre - &yet wrote: >> The URNBIS WG seems to be at an impasse. Having reviewed the >> discussions at and after IETF 90, I'd like to make a proposal. >> >> I don't think we will quickly come to agreement on the >> semantics of paths, queries, and fragments in the context of >> the "urn:" scheme. (In fact, I suggest that we call them >> "p-components", "q-components", and "f-components" here so >> that we don't get bogged down in how their meaning in URNs >> might be different from their meaning in URIs.) > > If this the only way this WG can complete its task, then so be > it. I see it as more positive than that, even if that is also true. It recognizes that the WG, at least in my opinion, has been moving much more toward a registration model than an IETF approval one. That change is consistent with a growing understanding of the limits to the IETF's subject matter expertise in naming and identification areas as well as acceptance that, for many communities, the IETF's saying "we don't think you should do that" is advice and not a commandment. Many of us had hoped that we could preserve at least a common syntax and set of comparison runes and operations for, and within, "fragments" and/or "queries" so that all uses of the "urn:" scheme would behave in the same way, but it appears that opinions and communities of interest, as well as concerns about the applications we haven't seen yet, are sufficiently diverse to make consensus at that level of detail. From that perspective, this is just acceptance of what can be specified and standardized scheme-wide and what is more properly left to communities of uses and users who can define their needs and how they should be implemented more effectively than the IETF can. Put differently, this looks to me like the next logical step in figuring out the role the IETF should properly play in or with specific namespaces and URNs generally. >... >> I think we can complete those tasks in the relatively near >> future if we decide to do one thing: let go of semantics. >> That is, I suggest that we update the URN syntax to allow >> p-components, q-components, and f-components, but leave the >> semantics of those elements up to specifications that define >> specific NIDs. > > Since there is a need to harmonize things done with > q-component across multiple namespaces, it is an additional > burden to create the necessary specifications at NID level. > But doing what Peter suggests does not prevent several > namespaces from sharing the same specification, which may or > may not be published by IETF. Exactly. If convenient, the IETF (or the RFC Editor) can generally publish (or republish) specifications from other bodies when that publication serves the needs of the community. If there is a publicly and generally-available specification published elsewhere, that may not be necessary. A few of us have also kicked around the idea of explicitly grouping specifications with significant similarities, such as sharing the same basic specification for what components are used and how, e.g., q-components are used in some detail, so that a registration document could reference that group specification rather than repeating all of the details. Again, the WG would need to sort that out, but my personal view is that, while it would be convenient for the IETF to ask IANA to maintain a registry of group names that could then be referenced from the registry of namespaces (NID names), it would not need to have significant other involvement in the process. >> Now, some folks might think that's reckless, but I think it's >> pragmatic. Right now we don't have a clear and distinct idea >> of how various URN-using communities might put p-components, >> q-components, and f-components to work in their context. In >> particular, the needs of various information sciences >> communities are still not well-known in this WG, despite the >> heroic efforts of Juha Hakala and a few other folks. > > If this approach allows my community to proceed in such a way > which meets our needs, fine. I look forward to leaving > philosophical discussions concerning semantics of URIs, URNs > etc. to IETF. My community did not create that mess, and I am > glad if that Gordian knot does not prevent us from moving on > any more. If it turns out that even the approach Peter > advocates does not enable the WG to reach rough consensus, > then it is likely that we shall go our own way, like the > Handle community before us. I, and I think I can say "we", are aware of that risk and, in part because there are other communities with the same problem and needs and perspectives different from yours, we are trying to cut said knot by narrowing the definition of how much all URNs have to have in common. >... >> Second, how is the syntax within p-components, q-components, >> and f-components defined? I suggest that it isn't, at least >> not in 2141bis. Particular NID specifications could, >> however, define intra-component syntax to meet their needs. > > This is what we would do for e.g. ISO standard identifiers > which have registered URN namespaces. That is my hope, i.e., we get the IETF out of your way as suggested above. >> Third, under this approach would we still be comfortable with >> a NID registration policy of Expert Review? I would be, but >> I can't speak for anyone else. > > Such review would be more complicated, but not impossible. Again, if a common specification is established by some relatively established group -- especially if that group is a recognized standards body-- I'd hope the IETF review process could examine that specification, offer whatever advice it has, and then provide a very rapid and low-pain registration process for NIDs that conformed to that specification. The main value of that registration process for such groups would be the classic one: preventing two different namespaces from using the same NID by accident and in a confusing way. best, john From nobody Fri Oct 17 14:54:38 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921EF1A8709 for ; Fri, 17 Oct 2014 14:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I64dvXmYbEY8 for ; Fri, 17 Oct 2014 14:54:32 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DFC1A8708 for ; Fri, 17 Oct 2014 14:54:32 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-09v.sys.comcast.net with comcast id 4MuT1p0012VvR6D01MuXdt; Fri, 17 Oct 2014 21:54:31 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-19v.sys.comcast.net with comcast id 4MuW1p00V1KKtkw01MuXMN; Fri, 17 Oct 2014 21:54:31 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9HLsU0w014844 for ; Fri, 17 Oct 2014 17:54:30 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9HLsUgm014843; Fri, 17 Oct 2014 17:54:30 -0400 Date: Fri, 17 Oct 2014 17:54:30 -0400 Message-Id: <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org In-reply-to: <54403493.5080808@andyet.net> (peter@andyet.net) References: <54403493.5080808@andyet.net> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413582871; bh=EPAM5osB3wKO1HJmHOuJcfqgR65xQ/TO69nHmOgVQiY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=v522Tb360VW5GK5WLrU66q3O9legUZl5/MN2SexIv9NsdwiYXbyu+Vqcs09sZoh7C i9bCQhjdM4vE96N59tNAh3OWVq2goaOKL8C7i7dvAAjZF96qb+KRRInP3xm3H6+PE0 ytXlENvgSVCI8IJ3MgEZPAjZMzBwdCJ9/8R6nyDu5L3qrrvH+MWLTwTN1NDuH5lacd yf/VxtNwRu8rncSyQdqR3N7ehznKByOnFMX1Gz5TOldoVo1d9Dl8mr1BYkmXsa9YK4 DqCvfU/Zo3Za7Gjn4GQFCFXVqKNEFX57BX7uSF5CrTAdks06soO2YNPaeilflTMBmM 9fbdWcHSAMyFA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bskQrkKC892wbbw4DI1v6mDEGbo Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 21:54:37 -0000 > From: Peter Saint-Andre - &yet > I think we can complete those tasks in the relatively near future if we > decide to do one thing: let go of semantics. That is, I suggest that we > update the URN syntax to allow p-components, q-components, and > f-components, but leave the semantics of those elements up to > specifications that define specific NIDs. This strikes me as consonant with how the IETF operates in many situations. There aren't many operations that need to work consistently on URNs qua URNs: What is the scheme? What is the namespace? A universal syntax restriction (so all URNs can be parsed from their contexts). A universal equality test (that may yield false negatives but must not yield false positives). We need to ensure that those features work consistently within a framework that lets interested parties explore alternative solutions to the problems on which we clearly have no consensus. > From: Juha Hakala > > Since there is a need to harmonize things done with q-component across > multiple namespaces, it is an additional burden to create the necessary > specifications at NID level. But doing what Peter suggests does not > prevent several namespaces from sharing the same specification, which > may or may not be published by IETF. And I don't see that as being very difficult -- One RFC can reference another. The major limitation is that it's difficult to do if the first RFC isn't written in a way that allows a clear external reference to the particular component. (My personal example of this is that the description of the SIP "digest authentication scheme" references the HTTP digest authentication scheme in a clumsy way that requires unnecessary work to understand.) > From: John C Klensin > > A few of us have also kicked around the idea of explicitly > grouping specifications with significant similarities, such as > sharing the same basic specification for what components are > used and how, I don't think that deliberate grouping would be very fruitful at this stage unless a group was generated naturally by the proposers of the NIDs in the group. I would expect that these groups would develop organically over time, and eventually there would be a series of -bis RFCs regularizing their similarity. (By analogy, there is no official grouping of all the SIP RFCs.) > From: Peter Saint-Andre - &yet > First, how will comparison work? I suggest that q-components and > f-components would not be factored into comparison, but that > p-components would be factored in (if they end up being used). Without any additional input, I suggest that the generic comparison includes all q-/f-/p-components. That is because the current generic comparison errs on the side of false-negatives and but avoids false-positives. NIDs are allowed to define lexical comparison rules that cause more URNs to be "equal" than the generic comparison rule, but cannot cause more URNs to be "not equal" than the generic comparison rule. If the generic comparison rule includes all additional components taken literally, then we can maintain this pattern regardless of how the equality definition evolves in particular NIDs. > Second, how is the syntax within p-components, q-components, and > f-components defined? I suggest that it isn't, at least not in 2141bis. > Particular NID specifications could, however, define intra-component > syntax to meet their needs. That makes sense. That is, the component syntax is defined simply as the iteration of a particular set of characters (that does not include any of the demarcating characters). > Third, under this approach would we still be comfortable with a NID > registration policy of Expert Review? I would be, but I can't speak for > anyone else. Again, that makes sense to me. Expert Review is rather flexible. Certainly, it is expected to include "editorial oversight" to make sure that the definition is clear and comprehensive (per JCK). But experts also make suggestions as to how a new NID definition can be improved. E.g., ensuring that it has extensibility, making its constructions similar to those of other NIDs, etc. And the writers of NIDs generally adopt such suggestions. > From: John C Klensin > > I'd hope the IETF review process could examine that specification, > offer whatever advice it has, and then provide a very rapid and > low-pain registration process for NIDs that conformed to that > specification. The main value of that registration process for such > groups would be the classic one: preventing two different namespaces > from using the same NID by accident and in a confusing way. And additionally, the IETF can advise on matters within its specific expertise, such as ways to maximize regularity of the entire URN universe and ensureing that the proposal has good extensibility properties. Dale From nobody Sat Oct 18 00:16:27 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB53F1A0396 for ; Sat, 18 Oct 2014 00:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQzcz5XVLx4c for ; Sat, 18 Oct 2014 00:16:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24871A038C for ; Sat, 18 Oct 2014 00:16:21 -0700 (PDT) Received: from [192.168.2.160] ([84.187.59.222]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MKu9E-1XfOFP08K8-00005M; Sat, 18 Oct 2014 09:16:19 +0200 Message-ID: <544213BD.7010605@gmx.de> Date: Sat, 18 Oct 2014 09:16:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Dale R. Worley" , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> In-Reply-To: <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:dD46+UuBYZobyJMbnqPJ3ptOca0Bvs5IVeu73NZwAh4w/9CZtV3 pvZ+IawvMIYHD1BB8CNBzYfl/OeKBR5Qlr1iFNV0ORNc1TcRRQOYcq9FTYbIYP/In8ZoSMz eSJug4XWGsmWVuBgdy4zLAvQSkGSR18JdRrFhr0UL1gZA44XCDuVfYyI/Twk6x2slIUoMt2 KfmolI2aC9ffojmnuoodw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/6XmsmmVg21wf7hDG2-1UZJ9I4sM Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 07:16:23 -0000 On 2014-10-17 23:54, Dale R. Worley wrote: >> From: Peter Saint-Andre - &yet > >> I think we can complete those tasks in the relatively near future if we >> decide to do one thing: let go of semantics. That is, I suggest that we >> update the URN syntax to allow p-components, q-components, and >> f-components, but leave the semantics of those elements up to >> specifications that define specific NIDs. > > This strikes me as consonant with how the IETF operates in many > situations. There aren't many operations that need to work > consistently on URNs qua URNs: What is the scheme? What is the > namespace? A universal syntax restriction (so all URNs can be parsed > from their contexts). A universal equality test (that may yield false > negatives but must not yield false positives). We need to ensure that > those features work consistently within a framework that lets > interested parties explore alternative solutions to the problems on > which we clearly have no consensus. Well, if URNs can be used everywhere URIs are used, there is at least one more common operation which needs to be defined somewhere: resolution of a reference against a base URN. > ... Best regards, Julian From nobody Sat Oct 18 01:32:46 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428B11A038B for ; Sat, 18 Oct 2014 01:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ooewk6dvcZ8W for ; Sat, 18 Oct 2014 01:32:44 -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 0202C1A00FA for ; Sat, 18 Oct 2014 01:32:44 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XfPRG-000Hpp-Hz; Sat, 18 Oct 2014 04:32:38 -0400 Date: Sat, 18 Oct 2014 04:32:33 -0400 From: John C Klensin To: Julian Reschke , "Dale R. Worley" , urn@ietf.org Message-ID: <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> In-Reply-To: <544213BD.7010605@gmx.de> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/thc0k4hHCAvXUuO2ursSFyIjCfU Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 08:32:45 -0000 --On Saturday, October 18, 2014 09:16 +0200 Julian Reschke wrote: > > Well, if URNs can be used everywhere URIs are used, there is > at least one more common operation which needs to be defined > somewhere: resolution of a reference against a base URN. Given that there is no requirement that URNs be resolved at all and that some URNs are not intended to be resolved, I don't understand your comment. Could you explain further? john From nobody Sat Oct 18 01:37:39 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8C51A1A16 for ; Sat, 18 Oct 2014 01:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7C7vbq-tluo for ; Sat, 18 Oct 2014 01:37:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333711A038B for ; Sat, 18 Oct 2014 01:37:36 -0700 (PDT) Received: from [192.168.2.160] ([84.187.59.222]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MFgxF-1Xtxr432gP-00Eeav; Sat, 18 Oct 2014 10:37:33 +0200 Message-ID: <544226BD.2090309@gmx.de> Date: Sat, 18 Oct 2014 10:37:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John C Klensin , "Dale R. Worley" , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> In-Reply-To: <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:itQ34OFjfAfl1eyuihwkviBLS7/zNP2jJcgZjjGSyFYKdrbPIsa xbZ6CrVz3Dz5nLZP5ykgit+Pnc5/RWu+YXogufTmJCYEvDPniB98KdO8ZgL4Sx2+cDmy6uJ aa0c/hOTIoeB6nj+9LKPmBgS+pP+qGuaRh3EzkV4X/cmZB24IuydPCYmB/fBaqNKTphF+PP S75QESg3xozO4aZRR1dow== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/cTHfZ9lzcFJwAotBZLPrSYBv4Jg Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 08:37:38 -0000 On 2014-10-18 10:32, John C Klensin wrote: > > > --On Saturday, October 18, 2014 09:16 +0200 Julian Reschke > wrote: > >> >> Well, if URNs can be used everywhere URIs are used, there is >> at least one more common operation which needs to be defined >> somewhere: resolution of a reference against a base URN. > > Given that there is no requirement that URNs be resolved at all > and that some URNs are not intended to be resolved, I don't > understand your comment. Could you explain further? The other kind of "resolution" -- see . Best regards, Julian From nobody Sat Oct 18 02:42:41 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76871A1B4F for ; Sat, 18 Oct 2014 02:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSyLyuSSTTOK for ; Sat, 18 Oct 2014 02:42:38 -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 EBBD41A1B49 for ; Sat, 18 Oct 2014 02:42:37 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XfQWv-000HwM-S6; Sat, 18 Oct 2014 05:42:33 -0400 Date: Sat, 18 Oct 2014 05:42:28 -0400 From: John C Klensin To: Julian Reschke Message-ID: <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> In-Reply-To: <544226BD.2090309@gmx.de> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/AD0fpHvAxjg50Xf5pPqjrGKigF0 Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 09:42:39 -0000 --On Saturday, October 18, 2014 10:37 +0200 Julian Reschke wrote: >> Given that there is no requirement that URNs be resolved at >> all and that some URNs are not intended to be resolved, I >> don't understand your comment. Could you explain further? > > The other kind of "resolution" -- see > ution>. Julian, To the best of my knowledge, there has never been such a thing as a "relative URN". Certainly RFC 2141 doesn't mention such a thing and its syntax doesn't appear to me to allow for it. It seems to me that this takes us back to the circle we have been going around, so, at the risk of reviewing the core of that impasse in this context. (1) Any assumption that URNs were required to have partial or relative forms was intended to be eliminated by draft-ietf-urnbis-semantics-clarif. It that document has to enumerate such assumptions, I would appreciate help in making the list. But the "nothing but the syntax" approach would seem to eliminate Section 5 of RFC 3986 because it is not about syntax but a relatively complex set of rules for interpreting one URI into another. (2) RFC 3986 does not update or obsolete RFC 2141. It appears to me that the closest it comes to requiring that all URI schemes conform to everything it mentions is the discussion in Section 1.1.3 that concludes 'Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305].'. That doesn't strike me as imposing any requirement other than a terminology suggestion. (3) Even if that were not the case, 3986 introduces the concept of "relative reference" in Section 1.2.2 with an introduction that makes them, and "resolving" them, "common terminology for use", not "requirement to support". Since that takes us back into the exercise of 3986 exegesis, the relevant sentences are "Such operations are defined by the protocols that make use of URIs, not by this specification. However, we do use a few general terms for describing common operations on URIs." The paragraph there, starting "A relative reference ((Section 4.2) refers to a resource by describing the difference within a hierarchical name space...." does not impose a requirement that all URI types support relative references either. Indeed, it goes on to say "As relative references can only be used within the context of a hierarchical URI, designers of new URI schemes should use a syntax consistent with the generic syntax's hierarchical components unless there are compelling reasons to forbid relative referencing within that scheme." Now, I suppose we could get far into the domain of protocol lawyers and debate "should" and what constitutes "compelling reasons", but I note that this is not a conformance statement but a recommendation and that "urn:" is certainly not a "new URI scheme" nor was it a new URI scheme at the time of 3968's writing. (4) I don't see anything in Section 4 that requires all URI schemes to support relative references either. It appears to me to just define a syntax model for them if they are allowed and used. (5) Finally, Section 5 ("Reference Resolution"), particularly in 5.2, contains the same type of "if this is not applicable, one can try that" language that appears in Section 6 ("Normalization and Comparison"). I think that any argument that Section 6 is just guidance and suggestions abut what might be done, rather than a normative requirement on all URIs (much of the discussion in Toronto if I understood it correctly) has to be taken as applying equally to Section 5.1 and 5.2. So, either I still don't understand what you are suggesting or it seems to me that it is not relevant to URNs. Again, if more words are required in draft-ietf-urnbis-semantics-clarif, please suggest text. john From nobody Sat Oct 18 03:15:18 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFACB1A1B8F for ; Sat, 18 Oct 2014 03:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb8oV3kfEiZt for ; Sat, 18 Oct 2014 03:14:59 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8621A1B8B for ; Sat, 18 Oct 2014 03:14:59 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XfR2H-000I0N-UF; Sat, 18 Oct 2014 06:14:57 -0400 Date: Sat, 18 Oct 2014 06:14:52 -0400 From: John C Klensin To: "Dale R. Worley" , urn@ietf.org Message-ID: <019C8C4D8E78A3F52A53CFB3@JcK-HP8200.jck.com> In-Reply-To: <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tbmyOyGyitcBauTWN1zMpkhCebM Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 10:15:01 -0000 Dale, One area of clarification, one of possible disagreement... --On Friday, October 17, 2014 17:54 -0400 "Dale R. Worley" wrote: >> From: John C Klensin >> >> A few of us have also kicked around the idea of explicitly >> grouping specifications with significant similarities, such as >> sharing the same basic specification for what components are >> used and how, > > I don't think that deliberate grouping would be very fruitful > at this stage unless a group was generated naturally by the > proposers of the NIDs in the group. I would expect that these > groups would develop organically over time, and eventually > there would be a series of -bis RFCs regularizing their > similarity. (By analogy, there is no official grouping of all > the SIP RFCs.) Dale, we may be thinking about this a bit differently, so let me explain what I meant by "grouping" (an attempt to choose a neutral term). As Juha pointed out, the library community (and its close collaborators) may respond to our going down this path by generating their own specification for how a set of namespaces (present and future) that meet their needs will behave. It is clear to me that they understand their needs even if many of the rest of us have been unsuccessful in being confident that we shared that understanding. It is clear that they require more than one namespace: after all, there are three of them (ISBN, ISSN, and NBN) specifically called out in this WG's original charter. Now, suppose that community produces "Grand Unified Library URN Specification #1" (with no expectation that there will ever be a number #2, but that is not the IETF's problem or anything the IETF can or should control). I'd assume they would then rewrite the ISBN, ISSN, NBN and probably DOI URN specifications in thems fo that one and that those that reference it and established International Standards would be very short. That is, in the sense in which I used the term, a "group" of URN namespaces, one that shares a definition that is much more specific about what components are allowed, what syntax they use internally, and how they are used than 2141 or 2141bis but that is still consistent with the latter. > From: Peter Saint-Andre - &yet > >> First, how will comparison work? I suggest that q-components >> and f-components would not be factored into comparison, but >> that p-components would be factored in (if they end up being >> used). > > Without any additional input, I suggest that the generic > comparison includes all q-/f-/p-components. That is because > the current generic comparison errs on the side of > false-negatives and but avoids false-positives. NIDs are > allowed to define lexical comparison rules that cause more > URNs to be "equal" than the generic comparison rule, but > cannot cause more URNs to be "not equal" than the generic > comparison rule. If the generic comparison rule includes all > additional components taken literally, then we can maintain > this pattern regardless of how the equality definition evolves > in particular NIDs. I think that misses the point. If one uses the completely generic URI comparison model laid out in 3986, then the above is what you get: lots of false negatives, few if any false positives, and, along with it, some vague ideas that the ultimate way to compare URIs is to resolve them and look at the results. That is what one would expect a generic URI engine that is not scheme sensitive to do and I read 3986 as saying just that. But we'd heard arguments on this mailing list that there are some information elements (independent of binding to syntax components) that really should be included in comparisons (if they don't match, the URNs don't either) and others that should not (if they don't match, it isn't important and the URNs are equal anyway). So, remembering that 2141 does not allow q-components, f-components, or (past-NSS) p-components, this is out opportunity to say -- these components must match for the URN to be equal; those don't count in an equality comparison. -- designers of URN namespaces that utilize any of f/q/p-components must make decisions about what information or requests go in to what queries based on an understanding of their equality comparison implications. It seems to me that is a perfectly reasonable position to take on a per-scheme basis and that it is actually a position consistent with 3986. It doesn't prevent even stronger rules if one has NID-specific information but, if a system knows about the "urn:" scheme, it seems to me that one loses a lot, especially for namespaces that are not resolved or whose resolution involves subtle issues, by saying what amounts to "there are not equality comparisons other than bit-for-bit string matching". >... >> From: John C Klensin >> >> I'd hope the IETF review process could examine that >> specification, offer whatever advice it has, and then provide >> a very rapid and low-pain registration process for NIDs that >> conformed to that specification. The main value of that >> registration process for such groups would be the classic >> one: preventing two different namespaces from using the same >> NID by accident and in a confusing way. > > And additionally, the IETF can advise on matters within its > specific expertise, such as ways to maximize regularity of the > entire URN universe and ensureing that the proposal has good > extensibility properties. As long as it is advice and timely, no problem. Especially after this long period of little progress and much confusion, I am still concerned that, if the IETF starts telling others what to do, they will ignore us, create their own independent definitions, and not bothering trying to register the NIDs associated with those namespaces. john From nobody Sat Oct 18 03:45:10 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8551A1A7B for ; Sat, 18 Oct 2014 03:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 863_sk-sf0bD for ; Sat, 18 Oct 2014 03:45:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AAC1A1BBE for ; Sat, 18 Oct 2014 03:45:04 -0700 (PDT) Received: from [192.168.2.160] ([84.187.59.222]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MH0eg-1Xs955188g-00DlEO; Sat, 18 Oct 2014 12:45:01 +0200 Message-ID: <544244A5.1000301@gmx.de> Date: Sat, 18 Oct 2014 12:44:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John C Klensin References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> In-Reply-To: <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9Kig4CbeQFmSHCCTWbIa8tlHW0GUT2+hMsxDsI/WXg3WVF/Qgqx O+WCMAOwJvy2L6obfkA6qnbNO11XRygBWlUt8OGxK6QDDaT96kkUB+qYfwVQ4MFZZkPKwcE zKIhP13giCekHhWvkY8kKTH1p2gJCAbqfG7OvmNdMQVqc7IFuy0iHZ9j0RMbA2pRgl9aPod dAerOTUyyRLuSfDxFP5tA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/KVcg3jT8l4sL1a9T3_YakI4lVqw Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 10:45:06 -0000 On 2014-10-18 11:42, John C Klensin wrote: > ... > (5) Finally, Section 5 ("Reference Resolution"), particularly in > 5.2, contains the same type of "if this is not applicable, one > can try that" language that appears in Section 6 ("Normalization > and Comparison"). I think that any argument that Section 6 is > just guidance and suggestions abut what might be done, rather > than a normative requirement on all URIs (much of the discussion > in Toronto if I understood it correctly) has to be taken as > applying equally to Section 5.1 and 5.2. > > So, either I still don't understand what you are suggesting or > it seems to me that it is not relevant to URNs. Again, if more > words are required in draft-ietf-urnbis-semantics-clarif, please > suggest text. > ... With the risk of repeating myself. If URNs are supposed to appear where URIs can go, resolution of a relative reference against a URN base URI will need to be defined somewhere (and yes, it'll be ok if it's exactly what RFC 3986 says). Concretely: what do you suggest what Java should do in http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#resolve%28java.net.URI%29 for a URN base URI? (And the same thing needs to be answered of xml:base, or the base attribute in HTML). Best regards, Julian From nobody Sat Oct 18 07:01:59 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2741A8860 for ; Sat, 18 Oct 2014 07:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90Gqejnv1jdq for ; Sat, 18 Oct 2014 07:01:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE3A1A885E for ; Sat, 18 Oct 2014 07:01:56 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 97377509B5 for ; Sat, 18 Oct 2014 10:01:55 -0400 (EDT) Message-ID: <54427288.2000802@seantek.com> Date: Sat, 18 Oct 2014 07:00:40 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> In-Reply-To: <544244A5.1000301@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/BlUhsQpzwgdluRBMt6PG6hbZcXA Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 14:01:58 -0000 On 10/18/2014 3:44 AM, Julian Reschke wrote: > On 2014-10-18 11:42, John C Klensin wrote: >> ... >> (5) Finally, Section 5 ("Reference Resolution"), particularly in >> 5.2, contains the same type of "if this is not applicable, one >> can try that" language that appears in Section 6 ("Normalization >> and Comparison"). I think that any argument that Section 6 is >> just guidance and suggestions abut what might be done, rather >> than a normative requirement on all URIs (much of the discussion >> in Toronto if I understood it correctly) has to be taken as >> applying equally to Section 5.1 and 5.2. >> >> So, either I still don't understand what you are suggesting or >> it seems to me that it is not relevant to URNs. Again, if more >> words are required in draft-ietf-urnbis-semantics-clarif, please >> suggest text. >> ... > > With the risk of repeating myself. If URNs are supposed to appear=20 > where URIs can go, resolution of a relative reference against a URN=20 > base URI will need to be defined somewhere (and yes, it'll be ok if=20 > it's exactly what RFC 3986 says). > > Concretely: what do you suggest what Java should do in > > > http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#resolve%28ja= va.net.URI%29=20 > > > for a URN base URI? Absolutely nothing. I don't see any conceptual problem with this when compared with the cid: = URL [RFC2392] or the data: URL [RFC2397]. Check those out. As I understand it, URNs are not hierarchical in nature. They identify=20 things of interest to Internet users in a universal, context-free way. Consider urn:ietf [RFC2648]: urn:ietf:rfc:2141 urn:ietf:mtg:90 What is the base URI for these URNs? Nothing. Are we so lazy that=20 instead of writing "urn:ietf:rfc:3986" you have to say and ? The whole point is to make= =20 URNs context-free, and that means hierarchy-free. Hierarchy is context. "ietf:rfc" and "ietf:mtg" illustrate a convenient means to divide the=20 namespace logically. But URNs are not retrievable in the protocol sense. = If anything, "urn:ietf:rfc:2141" should refer to the plain text file,=20 which is a format utterly lacking in support for URIs, so the point is=20 moot. In fact "urn:ietf:rfc:2141" names an abstract=20 thing-of-interest-to-the-Internet-community, namely: an IETF-named=20 object, which is an RFC, which has the number 2141. Now that we have=20 named the abstract thing, we can /resolve/ it to more concrete things=20 (HTTP URL, text/plain, text/html, etc.) depending on what we want. Another point: well-designed URNs are short. Whenever an identifier gets = long, there are natural impulses to try to shorten it (e.g., make=20 relative URIs). So, keep URNs short, and you'll never fret about using=20 them in their full forms. Thoughts? Sean From nobody Sat Oct 18 14:46:18 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF441A1ACA for ; Sat, 18 Oct 2014 14:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAPB5LCiDK-e for ; Sat, 18 Oct 2014 14:46:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1F11A036B for ; Sat, 18 Oct 2014 14:46:15 -0700 (PDT) Received: from [192.168.2.160] ([93.217.82.226]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lq9oW-1YJ3FU3oiu-00doQQ; Sat, 18 Oct 2014 23:46:13 +0200 Message-ID: <5442DFA0.5080405@gmx.de> Date: Sat, 18 Oct 2014 23:46:08 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Leonard , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> In-Reply-To: <54427288.2000802@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kbSGAW4FthVTMugJwHFUcfuuVY3hMDZNkcplZ4zD9DmgCLRoTwi +E4i6NFuASYHXy62TpaN84YSHk++b1rfnexp0lmP8vlu87py17BB5UPGR3etUIWkmA/DD7a erATNlTLTB8LFn8AGeqEbw0VL/IQk0NXrWU+KMl+xQ4k/Exov3IczzviS6uNUZ8Jn1t+056 tBzgPwPAS9piQPBhZcGAw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/N69Adh5zFSfK8BQyW572tyXvsUQ Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 21:46:17 -0000 On 2014-10-18 16:00, Sean Leonard wrote: > On 10/18/2014 3:44 AM, Julian Reschke wrote: >> On 2014-10-18 11:42, John C Klensin wrote: >>> ... >>> (5) Finally, Section 5 ("Reference Resolution"), particularly in >>> 5.2, contains the same type of "if this is not applicable, one >>> can try that" language that appears in Section 6 ("Normalization >>> and Comparison"). I think that any argument that Section 6 is >>> just guidance and suggestions abut what might be done, rather >>> than a normative requirement on all URIs (much of the discussion >>> in Toronto if I understood it correctly) has to be taken as >>> applying equally to Section 5.1 and 5.2. >>> >>> So, either I still don't understand what you are suggesting or >>> it seems to me that it is not relevant to URNs. Again, if more >>> words are required in draft-ietf-urnbis-semantics-clarif, please >>> suggest text. >>> ... >> >> With the risk of repeating myself. If URNs are supposed to appear >> where URIs can go, resolution of a relative reference against a URN >> base URI will need to be defined somewhere (and yes, it'll be ok if >> it's exactly what RFC 3986 says). >> >> Concretely: what do you suggest what Java should do in >> >> >> http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#resolve%28java.net.URI%29 >> >> >> for a URN base URI? > > Absolutely nothing. What should it return, or should it throw an exception? > I don't see any conceptual problem with this when compared with the cid: > URL [RFC2392] or the data: URL [RFC2397]. Check those out. I agree that all of these should get the same treatment; and that treatment is defined in RFC 3986 (and yes, I realize that java.net.URI does not do that). > As I understand it, URNs are not hierarchical in nature. They identify > things of interest to Internet users in a universal, context-free way. Yes, but that doesn't answer the question. > Consider urn:ietf [RFC2648]: > urn:ietf:rfc:2141 > urn:ietf:mtg:90 > > What is the base URI for these URNs? Nothing. Are we so lazy that "base URI" of a "URI" doesn't make any sense at all. > instead of writing "urn:ietf:rfc:3986" you have to say href="urn:ietf:rfc"> and ? The whole point is to make > URNs context-free, and that means hierarchy-free. Hierarchy is context. You don't have to, but our specs still should define what the above means. > "ietf:rfc" and "ietf:mtg" illustrate a convenient means to divide the > namespace logically. But URNs are not retrievable in the protocol sense. Unless you define a resolver. > If anything, "urn:ietf:rfc:2141" should refer to the plain text file, Why? > which is a format utterly lacking in support for URIs, so the point is If you mean fragments, not URIs: yes, they are defined. > moot. In fact "urn:ietf:rfc:2141" names an abstract > thing-of-interest-to-the-Internet-community, namely: an IETF-named > object, which is an RFC, which has the number 2141. Now that we have > named the abstract thing, we can /resolve/ it to more concrete things > (HTTP URL, text/plain, text/html, etc.) depending on what we want. See :-) > Another point: well-designed URNs are short. Whenever an identifier gets > long, there are natural impulses to try to shorten it (e.g., make > relative URIs). So, keep URNs short, and you'll never fret about using > them in their full forms. > > Thoughts? It doesn't answer the question I asked. Resolving a relative reference against a URI is a common operation. Please do not pretend it doesn't need to be defined just because the URI is a URN. Best regards, Julian From nobody Sat Oct 18 14:57:32 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BE41A1B1D for ; Sat, 18 Oct 2014 14:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rPnMX8r6Beq for ; Sat, 18 Oct 2014 14:57:27 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82AC1A000F for ; Sat, 18 Oct 2014 14:57:27 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4D37E50A84; Sat, 18 Oct 2014 17:57:26 -0400 (EDT) Message-ID: <5442E1FA.6060409@seantek.com> Date: Sat, 18 Oct 2014 14:56:10 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Julian Reschke , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> In-Reply-To: <5442DFA0.5080405@gmx.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080104050300050501070900" Archived-At: http://mailarchive.ietf.org/arch/msg/urn/yth59uWkHSFwGdxT79D93r7CmJU Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 21:57:30 -0000 This is a cryptographically signed message in MIME format. --------------ms080104050300050501070900 Content-Type: multipart/alternative; boundary="------------010000080101040401040706" This is a multi-part message in MIME format. --------------010000080101040401040706 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/18/2014 2:46 PM, Julian Reschke wrote: > On 2014-10-18 16:00, Sean Leonard wrote: >> On 10/18/2014 3:44 AM, Julian Reschke wrote: >>> [SNIP] >>> Concretely: what do you suggest what Java should do in >>> >>> >>> http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#resolve%28= java.net.URI%29=20 >>> >>> >>> >>> for a URN base URI? >> >> Absolutely nothing. > > What should it return, or should it throw an exception? from that same URI (lol): publicURI resolve(URI uri) Resolves the given URI against this URI. If the given URI is already absolute, or if this URI is opaque, then the given URI is returned. Definition: An/opaque/URI is an absolute URI whose scheme-specific part does not begin with a slash character ('/'). Opaque URIs are not subject to further parsing. Some examples of opaque URIs are: mailto:java-net@java.sun.com =09 news:comp.lang.java =09 urn:isbn:096139210x The documentation itself uses URN as an example! :) The end. > >> If anything, "urn:ietf:rfc:2141" should refer to the plain text file, > > Why? Only because the plain text file is (currently) the canonical form of=20 RFCs (at least I thought that they are, by default). Perhaps I should=20 have said "if you NEED to assume that all urn:ietf:rfc named items are=20 some kind of Internet media type content, it is safest to assume that a=20 text/plain content for it exists". (Which is a much more elliptical=20 statement.) > >> which is a format utterly lacking in support for URIs, so the point is= > > If you mean fragments, not URIs: yes, they are defined. I mean that plain text is an abstract sequence of characters. The text=20 http://foo is not guaranteed to be processed by a given text editor or=20 "cat" command at the terminal in any particular way. Similarly, in HTML, =

Hello I am http://foo

does not contain a "supported URI".=20

Hello I am foo

contains a supported URI= ,=20 because it will treat that URI as a URI and not an undifferentiated=20 sequence of abstract characters. -Sean --------------010000080101040401040706 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 10/18/2014 2:46 PM, Julian Reschke wrote:
On 2014-10-18 16:00, Sean Leonard wrote:
On 10/18/2014 3:44 AM, Julian Reschke wrote:
[SNIP]
Concretely: what do you suggest what Java should do in


http://docs.oracl= e.com/javase/7/docs/api/java/net/URI.html#resolve%28java.net.URI%29


for a URN base URI?

Absolutely nothing.

What should it return, or should it throw an exception?

from that same URI (lol):
public=A0URI=A0resolve(URI=A0uri)
Resolves the given URI against this URI.

If the given URI is already absolute, or if this URI is opaque, then the given URI is returned.


Definition:

An=A0opaque=A0URI is an absolute UR= I whose scheme-specific part does not begin with a slash character ('/'). Opaque URIs are not subject to further parsing. Some examples of opaque URIs are:

=
<= tt style=3D"font-size: 1.2em;">mailto:java-net@java.sun.co= m <= br>
<= tt style=3D"font-size: 1.2em;">news:comp.lang.java <= br>
<= tt style=3D"font-size: 1.2em;">urn:isbn:096139210x

The documentation itself uses URN as an example! :) The end.


If anything, "urn:ietf:rfc:2141" should refer to the plain text file,

Why?

Only because the plain text file is (currently) the canonical form of RFCs (at least I thought that they are, by default). Perhaps I should have said "if you NEED to assume that all urn:ietf:rfc named items are some kind of Internet media type content, it is safest to assume that a text/plain content for it exists". (Which is a much more elliptical statement.)


which is a format utterly lacking in support for URIs, so the point is

If you mean fragments, not URIs: yes, they are defined.

I mean that plain text is an abstract sequence of characters. The text http:= //foo is not guaranteed to be processed by a given text editor or "cat" command at the terminal in any particular way. Similarly, in HTML, <p>Hello I am http://foo</p> does not contain a "supported URI". <p>Hello I am <a href=3D"http://foo">foo</a></p> contains a supported URI, because it will treat that URI as a URI and not an undifferentiated sequence of abstract characters.


-Sean
--------------010000080101040401040706-- --------------ms080104050300050501070900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3 3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp 3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6 hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MTAxODIxNTYxMFowIwYJKoZIhvcNAQkEMRYEFHXoAq1Dx7vbnVZL nUHd7eKml/f4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8 MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQBjqDdF2xtRWD0q2mUv5+HhpSxRUmGW jAp1mPhHL73QQJC0sJYt1HkZGk6vggmPzCkSa5Rnb9Dk6tQ0O1UyB6m3LNNZAjHEDel3jscF riKmr2y0vb6Xr3R4G2JIqEmfO3f+yYt0+Ebrq+sF7H9vV8U0LBBGTw4HC9Xe2gQ4f2QTxZTH duBdLnEajcdnwC2nWPx3jHIXPucLSDVWLKcFoQF6SoVJNWsSZ5i70UCzfNwwaAR3hLkKEd+R aBdPIUsi0j/bJq1llOz4YdHzmttcobhCVIaeQ/NFqjN96wuF2QkP/i12QsY2xPu9x0VaxaEc W9JsrKLOkRSrYR5qK/aX6WTJAAAAAAAA --------------ms080104050300050501070900-- From nobody Sat Oct 18 15:21:11 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA931A1B57 for ; Sat, 18 Oct 2014 15:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmxjQVTRA43H for ; Sat, 18 Oct 2014 15:21:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E8E1A1B44 for ; Sat, 18 Oct 2014 15:21:05 -0700 (PDT) Received: from [192.168.2.160] ([93.217.82.226]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Mbxdm-1XOUen0CXO-00JHYf; Sun, 19 Oct 2014 00:21:03 +0200 Message-ID: <5442E7CA.9050208@gmx.de> Date: Sun, 19 Oct 2014 00:20:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Leonard , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> In-Reply-To: <5442E1FA.6060409@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1LAGYFS5b/DEb4AuyNertbDYJHWef1jLbXph0iVx/hrIFyVvnSa bKha6s3it2ixrdRrCo9nDmmOTODw1bxBu2yH1s/dfWFzqNMvZQxz+4XfvbdyWtzU1somnVr GjhUog61kVM8ko99jbYuuYbbrl8yJqucI5Ch7Jt0pTOBkX8DNddMVn0mTR0pzZCJNmPdTB2 Ry6lNW3b6Esl6UZNYZnuQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/LYlyrPCLyCjEaRo5EOIJMqW8F4w Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 22:21:07 -0000 On 2014-10-18 23:56, Sean Leonard wrote: > ... > from that same URI (lol): > > publicURI resolve(URI uri) > > Resolves the given URI against this URI. > > If the given URI is already absolute, or if this URI is opaque, then > the given URI is returned. > > > Definition: > > An/opaque/URI is an absolute URI whose scheme-specific part does not > begin with a slash character ('/'). Opaque URIs are not subject to > further parsing. Some examples of opaque URIs are: > > mailto:java-net@java.sun.com > news:comp.lang.java > urn:isbn:096139210x > > > The documentation itself uses URN as an example! :) The end. OK, so did you just change your position to "yes, it should be defined, and the definition from the java.net.URI javadocs makes sense to me"? In which case, we ought to discuss whether the scheme-agnostics resolution defined in RFC 3986 needs to be revised. BTW: I happen to believe that Java's definition yields surprising results for, for instance, data URIs. base: data:text/html/...stuff... rel: #x I would expect the result of the resolution to be data:text/html/...stuff...#x >>> If anything, "urn:ietf:rfc:2141" should refer to the plain text file, >> >> Why? > > Only because the plain text file is (currently) the canonical form of > RFCs (at least I thought that they are, by default). Perhaps I should > have said "if you NEED to assume that all urn:ietf:rfc named items are > some kind of Internet media type content, it is safest to assume that a > text/plain content for it exists". (Which is a much more elliptical > statement.) I note that the RFC Editor seems to believe that "The RFC status page for that RFC" is a better answer (I happen to disagree with that). >>> which is a format utterly lacking in support for URIs, so the point is >> >> If you mean fragments, not URIs: yes, they are defined. > > I mean that plain text is an abstract sequence of characters. The text > http://foo is not guaranteed to be processed by a given text editor or > "cat" command at the terminal in any particular way. Similarly, in HTML, >

Hello I am http://foo

does not contain a "supported URI". >

Hello I am foo

contains a supported URI, > because it will treat that URI as a URI and not an undifferentiated > sequence of abstract characters. Oh, I see what you meant to say, but it's irrelevant here. The media type doesn't need to support URIs in any way -- resolution of relative references still needs to be defined. Best regards, Julian From nobody Sat Oct 18 15:42:11 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5291A1B72 for ; Sat, 18 Oct 2014 15:42:09 -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 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 B1rABUJf7UT2 for ; Sat, 18 Oct 2014 15:42:07 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DBC1A1B57 for ; Sat, 18 Oct 2014 15:42:07 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 02802509B6; Sat, 18 Oct 2014 18:42:05 -0400 (EDT) Message-ID: <5442EC72.9000605@seantek.com> Date: Sat, 18 Oct 2014 15:40:50 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Julian Reschke , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> <5442E7CA.9050208@gmx.de> In-Reply-To: <5442E7CA.9050208@gmx.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040806070305090309010908" Archived-At: http://mailarchive.ietf.org/arch/msg/urn/B9YxKo_ihZg-CoTOw-mtlTVtgH4 Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 22:42:09 -0000 This is a cryptographically signed message in MIME format. --------------ms040806070305090309010908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/18/2014 3:20 PM, Julian Reschke wrote: > On 2014-10-18 23:56, Sean Leonard wrote: >> ... >> from that same URI (lol): >> >> publicURI=20 >> =20 >> resolve(URI=20 >> uri) >> >> Resolves the given URI against this URI. >> >> If the given URI is already absolute, or if this URI is opaque, th= en >> the given URI is returned. >> >> >> Definition: >> >> An/opaque/URI is an absolute URI whose scheme-specific part does n= ot >> begin with a slash character ('/'). Opaque URIs are not subject to= >> further parsing. Some examples of opaque URIs are: >> >> mailto:java-net@java.sun.com >> news:comp.lang.java >> urn:isbn:096139210x >> >> >> The documentation itself uses URN as an example! :) The end. > > OK, so did you just change your position to "yes, it should be=20 > defined, and the definition from the java.net.URI javadocs makes sense = > to me"? > > In which case, we ought to discuss whether the scheme-agnostics=20 > resolution defined in RFC 3986 needs to be revised. > > BTW: I happen to believe that Java's definition yields surprising=20 > results for, for instance, data URIs. > > base: data:text/html/...stuff... > rel: #x > > I would expect the result of the resolution to be > > data:text/html/...stuff...#x The most telling thing is that Java's definition yields "surprising=20 results". Overall the thing is that URIs that are not path-oriented do not support = a concept of relative references. You can ask the question, but the=20 answer will not make sense. We need not inquire further about what Java=20 or any other particular implementation would do. Example 1: base URI: mid:5442E7CA.9050208@gmx.de given relative URI: =2E./foo.html What does it mean when you combine them? Answer: Don't do that. It doesn't make sense. Example 2: base URI: data:text/html;base64,PGh0bWw+PGhlYWQ+PHRpdGxlPkhlbGxvPz8/PzwvdGl0bGU+PC9= oZWFkPjxib2R5PkhpIHRoZXJlLjwvYm9keT48L2h0bWw+ given relative URI: =2E./foo.html What does it mean when you combine them? Answer: Don't do that. It doesn't make sense. Your algorithm might see ...Pz8/Pzwvd... and slice the URI at that point.= Don't do that. It doesn't make sense. > The media type doesn't need to support URIs in any way -- resolution=20 > of relative references still needs to be defined. Not obvious to me. Where are you going to get the relative references=20 from? If you're not getting it from the content, where else are you=20 getting it? Sean --------------ms040806070305090309010908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3 3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp 3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6 hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MTAxODIyNDA1MFowIwYJKoZIhvcNAQkEMRYEFF8JmMZpUU9NPfBS IB27U/9KSd/aMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8 MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQA50t5UyJFYTAcqdRI1jz8yIJe+oka5 G1ZqQhb4rtRmMW8FSz8+sw/zZJoWE7kHyDmi6kVxlLAmxwKBVGoY33r1cyRNJOsFT7mVpIS4 1HMjgYj/GBYFfJ7s2fzEAvv3EF6bvvCgYAgUZQlHB9fEOdwclcHCvZSPgm2zuqPuYOq+Uens 8MtyaStMtJ7A0+PkwjN1vRje7QVkS1ZZScG/87a9aSpGwsWhIl1v6Xo0V2KTm/sbBoirkKom uthBF2GYmR2G79U64hzMPID+0CNGzzxzAma1o34GLXwn6Btl8HZu/eRJ40LuLVIcPKh+7+Jr b1lwfRB0sykIejbMIERwcYpUAAAAAAAA --------------ms040806070305090309010908-- From nobody Sat Oct 18 18:52:33 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EBD1A003A for ; Sat, 18 Oct 2014 18:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpTBrkypnmpF for ; Sat, 18 Oct 2014 18:52:30 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A711A001E for ; Sat, 18 Oct 2014 18:52:30 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id x19so2861789ier.39 for ; Sat, 18 Oct 2014 18:52:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eqklFGAaC7g0OL9CzGKiZK66LRRd/Ua6ZzRDO5pw+dg=; b=HygyCEn2gDpzgDu8CObFk5mVC0EtLoAp2/4c/P0Hc0ItmDHVzHcPdKk5sZNq64DPRT Ek7L/LLZugZrpQhvZoTrUfUWspPtlesQmL94P+RkvER73C+HTf7BO9eYRvdV/WzlSkQe irYLixmoWVJAyuKF5VyDvulKr87wPkBMakLKfIxMuy2FCTV0/3lNtK9NLSazUbx7FRee YdteNO6xU2V+rZHzxSROv84Giahp7bE2t+WfWL/i+uwJ7kV2Fc0ZB5HIGIcT70d7ugaC J3wn50xP8Naaqof7WMW29tVyf3Na6GVLKlXwXKlQTAw4ZJ1iEe1zhcpYJf9QIx67Z4ip am1w== X-Gm-Message-State: ALoCoQl0H5ScTxCAcSZhTDKoMyKM4HxSOpfh68gFt7e8Zw2Fcx0wmWxCcOhYb4RcfAf6+Uj7J+Oe X-Received: by 10.107.19.203 with SMTP id 72mr18349735iot.27.1413683550045; Sat, 18 Oct 2014 18:52:30 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ki5sm2844685igb.2.2014.10.18.18.52.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Oct 2014 18:52:29 -0700 (PDT) Message-ID: <5443195C.8010105@andyet.net> Date: Sat, 18 Oct 2014 19:52:28 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> In-Reply-To: <544244A5.1000301@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/xGY_bR-43zndl7q9iIUnskIWGG0 Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 01:52:32 -0000 On 10/18/14, 4:44 AM, Julian Reschke wrote: > On 2014-10-18 11:42, John C Klensin wrote: >> ... >> (5) Finally, Section 5 ("Reference Resolution"), particularly in >> 5.2, contains the same type of "if this is not applicable, one >> can try that" language that appears in Section 6 ("Normalization >> and Comparison"). I think that any argument that Section 6 is >> just guidance and suggestions abut what might be done, rather >> than a normative requirement on all URIs (much of the discussion >> in Toronto if I understood it correctly) has to be taken as >> applying equally to Section 5.1 and 5.2. >> >> So, either I still don't understand what you are suggesting or >> it seems to me that it is not relevant to URNs. Again, if more >> words are required in draft-ietf-urnbis-semantics-clarif, please >> suggest text. >> ... > > With the risk of repeating myself. If URNs are supposed to appear where > URIs can go, resolution of a relative reference against a URN base URI > will need to be defined somewhere (and yes, it'll be ok if it's exactly > what RFC 3986 says). > > Concretely: what do you suggest what Java should do in > > > http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#resolve%28java.net.URI%29 > > > for a URN base URI? > > (And the same thing needs to be answered of xml:base, or the base > attribute in HTML). Julian, are you implying that there might be different answers to those three questions? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sun Oct 19 01:04:28 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B331A0029 for ; Sun, 19 Oct 2014 01:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlVFqWhICm9j for ; Sun, 19 Oct 2014 01:04:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAF31A0023 for ; Sun, 19 Oct 2014 01:04:24 -0700 (PDT) Received: from [192.168.2.160] ([93.217.82.226]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Ls8Qd-1Y8gjT1Vxn-013sTI; Sun, 19 Oct 2014 10:04:20 +0200 Message-ID: <5443707F.6000609@gmx.de> Date: Sun, 19 Oct 2014 10:04:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Leonard , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> <5442E7CA.9050208@gmx.de> <5442EC72.9000605@seantek.com> In-Reply-To: <5442EC72.9000605@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9eKMycQoVmy3hv+XiCFIQnwtuFpxvTWRM0ienag7wA+SuHhb0C8 5JvxPmRGIUsaPvyJcHF9SlhW7XftAAErFelren0vLd9LOLE/Otd0s7u3SbPi4T1PnF0IBGU Ox/OKksmk08fiu3qFWgo2JQw6yB+CNL8bH15yLupJSMdHKdtxtTkK5YKgJEJ+9XtvQuBS3h m2PpNcNiSVIE2+jOvWEbg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/vH-TVr1xJVe--meWLd_dwPiGcIk Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 08:04:26 -0000 On 2014-10-19 00:40, Sean Leonard wrote: > ... > The most telling thing is that Java's definition yields "surprising > results". > > Overall the thing is that URIs that are not path-oriented do not support > a concept of relative references. You can ask the question, but the > answer will not make sense. We need not inquire further about what Java > or any other particular implementation would do. > > Example 1: > base URI: > mid:5442E7CA.9050208@gmx.de > > given relative URI: > ../foo.html > > What does it mean when you combine them? > Answer: Don't do that. It doesn't make sense. I agree mostly. But I disagree that we can pretend not to have to answer the question. > Example 2: > base URI: > data:text/html;base64,PGh0bWw+PGhlYWQ+PHRpdGxlPkhlbGxvPz8/PzwvdGl0bGU+PC9oZWFkPjxib2R5PkhpIHRoZXJlLjwvYm9keT48L2h0bWw+ > > > given relative URI: > ../foo.html > > What does it mean when you combine them? Something weird. > Answer: Don't do that. It doesn't make sense. > Your algorithm might see ...Pz8/Pzwvd... and slice the URI at that point. > Don't do that. It doesn't make sense. Yes. But what if the relative reference is "#a" (and assuming the HTML contains that anchor)? Still meaningless? >> The media type doesn't need to support URIs in any way -- resolution >> of relative references still needs to be defined. > > Not obvious to me. Where are you going to get the relative references > from? If you're not getting it from the content, where else are you > getting it? I see your point. Yes, if the format doesn't have this information, relative reference resolution will not happen frequently. It doesn't mean it never happens, though. Best regards, Julian From nobody Sun Oct 19 01:09:20 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D647A1A0039 for ; Sun, 19 Oct 2014 01:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-O3RArQGbRT for ; Sun, 19 Oct 2014 01:09:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F231A0037 for ; Sun, 19 Oct 2014 01:09:17 -0700 (PDT) Received: from [192.168.2.160] ([93.217.82.226]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MFPyK-1Xu19z1hEi-00ENWu; Sun, 19 Oct 2014 10:09:15 +0200 Message-ID: <544371A3.4010409@gmx.de> Date: Sun, 19 Oct 2014 10:09:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> In-Reply-To: <5443195C.8010105@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fTIyg67YHLWxyIf7JN5iaP7zNtSAUQu/H5i5k6c9xIaDq7GIgTW /aUjCQUitvwpukB/WmyyCvmMbJBkNbj8EeUI+5SNKWDIizuJBBlPHWWeMKP5UxwcfoSqhJ0 GmGGwMAEasDfD7zbHUv0EhKcN6hCrGJE+qO5HZpV+4fL0SOSY7kZini2sr5sq/BLAIrSdbs DTnrwDEkG5brXdYdAC30g== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/cYSdmpYxCBnO42pj2ywGtCzWevU Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 08:09:19 -0000 On 2014-10-19 03:52, Peter Saint-Andre - &yet wrote: > ... >> for a URN base URI? >> >> (And the same thing needs to be answered of xml:base, or the base >> attribute in HTML). > > Julian, are you implying that there might be different answers to those > three questions? In a perfect world, there'lll be a single definition that makes sense for hierarchical URIs (for some value "hierarchical") and does something predictable (but maybe weird) for all other schemes. Optimally, that definition would be the one in RFC 3986. The problem here is that if groups get away with the idea that they just can define what they want (and are not bound by the base spec), we *will* end up with different definitions. That's why I tried to make clear that even if relative reference resolution isn't *important*, it still needs to be defined. Best regards, Julian From nobody Mon Oct 20 07:35:50 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC281A8915 for ; Mon, 20 Oct 2014 07:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD8WLo5nT2-1 for ; Mon, 20 Oct 2014 07:35:29 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8B11A9078 for ; Mon, 20 Oct 2014 07:14:39 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so5283395pab.32 for ; Mon, 20 Oct 2014 07:14:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bbGzfz8K6TmkYuSougqQvBAEHm8sdl0EbyLxoSOekN4=; b=MiEKRfkYPtq5Hzhn1V1plpS0U1DKQDB4+bdZ+1HE6AuFw6B5OMFwiwZc0AHSQWf7CV OoVFefQapHbgotcers6yoYT1FsxXk5LSvgeeY6uRxFhhRFeLen3j6HU2OoImy2NprD2d NHo0q3qSCKoltHS9nr0CwwHTnva6yL+DqCSEG5RFgf2GpxYGXEYCVbkF0uEy4E4REtCb 6c/8j8Wq5y93myjGjCtzyFOwvbgun0f5hBurOXX0p4rTfzSCYM8G52/Kr0G4a9DE+owH 36QgASka7Rh+VAf7meSYeLTgPrcUWDlKJAopHhv9AC6qxWyfZMA0G+BOHaWDLmFKwxrl qkAw== X-Gm-Message-State: ALoCoQkOJ15bHMfhITziwJzaPof+DzY6vrtr/c1l0Wb0/C9cpbqQ+X1ecMa8ZaHVXtzr3NKdo0aK MIME-Version: 1.0 X-Received: by 10.70.140.34 with SMTP id rd2mr3052632pdb.146.1413814478660; Mon, 20 Oct 2014 07:14:38 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Mon, 20 Oct 2014 07:14:38 -0700 (PDT) X-Originating-IP: [2001:500:4:15:804e:b86:3798:f930] In-Reply-To: <544371A3.4010409@gmx.de> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> Date: Mon, 20 Oct 2014 10:14:38 -0400 Message-ID: From: Andrew Newton To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1mnf-_MVT_rwwRsmEDMLCNtbFNM Cc: "urn@ietf.org" , Peter Saint-Andre - &yet Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:35:40 -0000 On Sun, Oct 19, 2014 at 4:09 AM, Julian Reschke wrote: > The problem here is that if groups get away with the idea that they just can > define what they want (and are not bound by the base spec), we *will* end up > with different definitions. That's why I tried to make clear that even if > relative reference resolution isn't *important*, it still needs to be > defined. I agree that we should not gloss over relative reference resolution (i.e. it is important). But I am unclear as to what you feel we should do. Should we have a definition for URNs? Is it ok if we say this behavior is undefined? Or are we to somehow align ourselves with the mess that already exists with URIs in general? -andy From nobody Mon Oct 20 08:06:39 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8691A892B for ; Mon, 20 Oct 2014 08:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyw-gFI0k6xa for ; Mon, 20 Oct 2014 08:06:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E081A899E for ; Mon, 20 Oct 2014 07:41:58 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LvUwp-1Y78eu4B7b-010g7i; Mon, 20 Oct 2014 16:41:56 +0200 Message-ID: <54451F2E.3060909@gmx.de> Date: Mon, 20 Oct 2014 16:41:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andrew Newton References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fftLrcU58FUbp6X3oYgTkvIFuNx2Nqq8C9bwy6mq1+Hq/VHUGCH K8j71ZDN8WPJPT2fGU2sJ0JS4vfwhan2IEnQOYLXpW/PFc7cE3keBRNALaMg+PAyQYvwmu0 m8KJBQTC4aLxLZJmGnrTdd526JbSn65YHuuAgoICCPyCnO13EtXObNsV0e6+gTdHU+TArI4 mYbl1MNqVQofCrgw1rSfg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/G1ZCFk9TrnKVoD1Iw9-BS_xSbQQ Cc: "urn@ietf.org" , Peter Saint-Andre - &yet Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:06:36 -0000 On 2014-10-20 16:14, Andrew Newton wrote: > On Sun, Oct 19, 2014 at 4:09 AM, Julian Reschke wrote: >> The problem here is that if groups get away with the idea that they just can >> define what they want (and are not bound by the base spec), we *will* end up >> with different definitions. That's why I tried to make clear that even if >> relative reference resolution isn't *important*, it still needs to be >> defined. > > I agree that we should not gloss over relative reference resolution > (i.e. it is important). But I am unclear as to what you feel we should > do. Should we have a definition for URNs? Is it ok if we say this > behavior is undefined? Or are we to somehow align ourselves with the > mess that already exists with URIs in general? I believe you should say that URIs using the "URN" scheme work exactly the same way as any other URI, and that that behavior is defined by RFC 3986. And no, it's not a mess. Best regards, Julian From nobody Mon Oct 20 08:12:16 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E661A8899 for ; Mon, 20 Oct 2014 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uFbWrMKCYC2 for ; Mon, 20 Oct 2014 08:12:07 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BF11A8A79 for ; Mon, 20 Oct 2014 07:50:01 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-05v.sys.comcast.net with comcast id 5Sp71p0062N9P4d01Spzkf; Mon, 20 Oct 2014 14:49:59 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-13v.sys.comcast.net with comcast id 5Spy1p00R1KKtkw01SpzpL; Mon, 20 Oct 2014 14:49:59 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9KEnvZn012088; Mon, 20 Oct 2014 10:49:57 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9KEnupo012087; Mon, 20 Oct 2014 10:49:56 -0400 Date: Mon, 20 Oct 2014 10:49:56 -0400 Message-Id: <201410201449.s9KEnupo012087@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Julian Reschke In-reply-to: <544244A5.1000301@gmx.de> (julian.reschke@gmx.de) References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413816599; bh=c0SJDZc1EDQ5IaDcr7HTxoHAhn1ncT1stiIakAjSBr0=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=SSaTbH65RQODXN0gS8+MlZtv1cMq/vyNSN8X447jY3oD8nMWXnamYv/18mMrmgKm8 YzL+rNS8dn/HwojokJqPGXWYpmbEzx9JRl2huOFv7J5efRXh/62S6xCcKRigrpGnJs 6hp5xI+IpETKwwzGQHabgYjplH5FN+FFAxCikzvv+Bq/WSuNxUD2WvL7WrUFpiJT1U 1y5D27XPYd31o3IOAffCTcDgs1jR2VuQylXMhZp9fgIfG/CYTiFgYt0pYbeuKXWtsI L9CAEpbB/nk304m7XNVg1ES+PVM0tCBKYplGTWZLLJMpx1RIZMUMaKHJb58DZHYtWs DsGYeg5qxo/xA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/j9xQSqzngwawx5ijUA76orXvmj4 Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:12:13 -0000 > From: Julian Reschke > With the risk of repeating myself. If URNs are supposed to appear where > URIs can go, resolution of a relative reference against a URN base URI > will need to be defined somewhere (and yes, it'll be ok if it's exactly > what RFC 3986 says). > > Concretely: what do you suggest what Java should do in > > http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#resolve%28java.net.URI%29 > > for a URN base URI? To me, the immediate analogy is, what should Java do if the base URI is a sip: URI? Within the sip: scheme, there is no hierarchy expressed in the syntax, and (as far as I've ever heard) no conceptual hierarchy system within which a relative URI could be assigned a meaning. What Java *does* is outside my ken, but quite naively, I'd expect the function to throw an exception. Basically, "You've attempted to use this URI as if it has a hierarchical structure, but it doesn't." (Describing how you really want to handle that situation within the design of the Java language may be different.) Now there is a caveat: Perhaps some future NIDs of URNs will have a hierarchical structure defined for them, and within that a relative URI has a meaning. In which case, the function can be extended to handle those in the conceptually correct way. Dale From nobody Mon Oct 20 08:19:19 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66071A0191 for ; Mon, 20 Oct 2014 08:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZu5WMtve_sa for ; Mon, 20 Oct 2014 08:19:06 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED331A87C5 for ; Mon, 20 Oct 2014 08:04:36 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XgEVZ-00055m-7o; Mon, 20 Oct 2014 11:04:29 -0400 Date: Mon, 20 Oct 2014 11:04:24 -0400 From: John C Klensin To: Andrew Newton , Julian Reschke Message-ID: <149580D9175A5CA24390D217@JcK-HP8200.jck.com> In-Reply-To: References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/NKxF_sny9cBdhcprNDM0l5wqbwk Cc: urn@ietf.org, Peter Saint-Andre - &yet Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:19:10 -0000 --On Monday, October 20, 2014 10:14 -0400 Andrew Newton wrote: > I agree that we should not gloss over relative reference > resolution (i.e. it is important). But I am unclear as to what > you feel we should do. Should we have a definition for URNs? > Is it ok if we say this behavior is undefined? Or are we to > somehow align ourselves with the mess that already exists with > URIs in general? And, noting Dale's comments, if 3986 is taken to imply that all URIs are expected to support relative forms, then what should be done about SIP and other URIs, some very heavily-used, that don't support relative references either? For URNs, would a revised version of draft-ietf-urnbis-semantics-clarif do the job of clarifying that relative references are not applicable, or does something have to be done to 3986? john From nobody Mon Oct 20 08:20:13 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3F71A017D for ; Mon, 20 Oct 2014 08:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5f9ToKu_Nf5 for ; Mon, 20 Oct 2014 08:20:09 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899A01A896B for ; Mon, 20 Oct 2014 08:08:04 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-10v.sys.comcast.net with comcast id 5T5k1p00B2XD5SV01T83i4; Mon, 20 Oct 2014 15:08:03 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-20v.sys.comcast.net with comcast id 5T821p00F1KKtkw01T82Q2; Mon, 20 Oct 2014 15:08:03 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9KF815K013020; Mon, 20 Oct 2014 11:08:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9KF80oM013018; Mon, 20 Oct 2014 11:08:00 -0400 Date: Mon, 20 Oct 2014 11:08:00 -0400 Message-Id: <201410201508.s9KF80oM013018@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Julian Reschke In-reply-to: <544371A3.4010409@gmx.de> (julian.reschke@gmx.de) References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413817683; bh=ZInRQD2jF1QdlB7rf7nIMPN24vhpu4U/psHEiBZm5tU=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=DHXC0ztwUnAYqHycMGsYJNlIcx/ZENA/tGdw910mQZijCKzxi+TiLxWJxiwycQHsj LrMHDFfo2Mv2BIzRMvHd6G+7lYiRV8aXPKdBLxGcoZu5yNq/ZoH03joI427AypGQtA s3M+1HgNuEs1pLfR3w26noX1A6P3eThK9uzgxT1tbLENOBviSjlgJDM3XQZlDexHzH td4JIYkX7Pfeh2pUSeNr2RVJMHN1jAcJBXr8QZHUWe/q7MpyMdHDoDM92BdEbtQtmX knKIvQLV4Cwr04mPLLaKaxxq7KbzBpJ5baiPqldDBFn9a/mLMX44ID2dGnNfZcR3BJ /I8ibcPhlatVw== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/_UDvrfJDARgRxDH-DMmku_Ie5Hs Cc: urn@ietf.org, peter@andyet.net Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:20:11 -0000 > From: Julian Reschke > In a perfect world, there'lll be a single definition that makes sense > for hierarchical URIs (for some value "hierarchical") and does something > predictable (but maybe weird) for all other schemes. Optimally, that > definition would be the one in RFC 3986. Actually, that sort of thing is not universal in a perfect world. There are numerous situations in programming languages where the outcome of an operation is not strictly defined, and it is agreed that the programming language is better for it. And there are various flavors of "not strictly defined". In practice, they all mean that your program should avoid attempting to make such an operation happen unless it takes special precautions. An even more elaborate version is the definition in the VAX CPU architecture definition of what is and is not allowed within the definition of "the result of the operation is not defined". > The problem here is that if groups get away with the idea that they just > can define what they want (and are not bound by the base spec), we > *will* end up with different definitions. That's why I tried to make > clear that even if relative reference resolution isn't *important*, it > still needs to be defined. I'd say that we need to make it clear what is defined and what is not defined. If someone wants to extend the official definition with an unofficial one, that's their problem. > But what if the relative reference is "#a" (and assuming the HTML > contains that anchor)? Still meaningless? If we decide to extend the use of the syntax "#a" to URNs to indicate fragments when the URN denotes (one or more) MIME-typed data objects, then it would make sense to extend the rules of relative URI resolution to interpret a relative URI like "#a" on that URN as a base in the way described in RFC 3986; it becomes the fragment-part of the target URI that is generated by the resolution process. Dale From nobody Mon Oct 20 08:23:36 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13311A6D3F for ; Mon, 20 Oct 2014 08:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ea1D-i3pjbKQ for ; Mon, 20 Oct 2014 08:23:33 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477BA1A8882 for ; Mon, 20 Oct 2014 08:12:05 -0700 (PDT) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-06v.sys.comcast.net with comcast id 5TBM1p0065Clt1L01TC4Pq; Mon, 20 Oct 2014 15:12:04 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-17v.sys.comcast.net with comcast id 5TC31p00L1KKtkw01TC4cg; Mon, 20 Oct 2014 15:12:04 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9KFC24U013271; Mon, 20 Oct 2014 11:12:02 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9KFC2Au013270; Mon, 20 Oct 2014 11:12:02 -0400 Date: Mon, 20 Oct 2014 11:12:02 -0400 Message-Id: <201410201512.s9KFC2Au013270@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: John C Klensin In-reply-to: <019C8C4D8E78A3F52A53CFB3@JcK-HP8200.jck.com> (john@jck.com) References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <019C8C4D8E78A3F52A53CFB3@JcK-HP8200.jck.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413817924; bh=hrJuOYOdMyzA+vw77IbDELAT3m1Eyx/hCsX54cTeHyo=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=O9OYjOtrrNaK98MYJRbFU0lp2HIpx7af/i45J2/+mWFD7LM0i0Kgly8n7tkJrgT58 c32/rKJakESS6tqjU9O4HzIYxPNsNqHlo3CVjzvMZlBTpilrL+02rm250YnIs9M6kF w5qFtL6ZudIysj6g2NGkEUnaS2a/zmu8hgCwfU9KD2vDLEkTC/3j1a965VmO3qL1nS T/XYaOumAzy+rkS5gCYkCeMhAEj4rBj+am28hJ5jbYKqoVbGzW6tL72NhJ3g7ZINDl D0yQrFevxU8pyVdmHxXXDn5p42QpETEmqSj70PVOHiFR/FXwwiLKlO6kWr483GveEv NTijMTA9LQ0hA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/RvynaAiZYl8P8zcttWHcJIJ7Jrc Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:23:35 -0000 > From: John C Klensin > But we'd heard arguments on this mailing list that there are some > information elements (independent of binding to syntax components) > that really should be included in comparisons (if they don't match, > the URNs don't either) and others that should not (if they don't > match, it isn't important and the URNs are equal anyway). I see the designation at this time that a component is not significant for equality comparison as risky. If in the generic URN specification all components are significant, then NID definitions can later say that particular components are not significant. But if we say in the generic URN specification that a particular component is not significant, then all NID definitions inherit that rule. I am willing to be swayed if somone proposes that a *particular* component should be non-significant, and everyone agrees that that is so. But in a discussion of this high level of generality, I don't see that happening. Saying in the generic specification that all components are significant is the safe choice with regard to future extensibility. Dale From nobody Mon Oct 20 08:25:30 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DAF1A008A for ; Mon, 20 Oct 2014 08:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OOwpE02bWDD for ; Mon, 20 Oct 2014 08:25:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEDD1A01F0 for ; Mon, 20 Oct 2014 08:17:15 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M86PB-1Y2BNE1PlJ-00vfGL; Mon, 20 Oct 2014 17:17:01 +0200 Message-ID: <54452768.6050604@gmx.de> Date: Mon, 20 Oct 2014 17:16:56 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John C Klensin , Andrew Newton References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <149580D9175A5CA24390D217@JcK-HP8200.jck.com> In-Reply-To: <149580D9175A5CA24390D217@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EeRl4o5EXpJFXvH4duZ4tJLC/k8xHIR8H+6dnbev+xfq9kOYqVN FPYqBDDm7o1fD1x+R6ngSQSw2UubHqDYkUUa4yomlvWGdhE3Tc2HAS2oklp33YSXr+/vgd1 vyJG1qhk0jMrqWB1+YqWWFmZuxWbbjYAfdl8UH9TLfbZgZiPpMsDxibiN//id6pyJHnKJUq vNVvJZdCbeGHGUJ7eAo8Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/ytRLHHzHGMq7MceMz3yIVtV20VY Cc: urn@ietf.org, Peter Saint-Andre - &yet Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:25:25 -0000 On 2014-10-20 17:04, John C Klensin wrote: > > > --On Monday, October 20, 2014 10:14 -0400 Andrew Newton > wrote: > >> I agree that we should not gloss over relative reference >> resolution (i.e. it is important). But I am unclear as to what >> you feel we should do. Should we have a definition for URNs? >> Is it ok if we say this behavior is undefined? Or are we to >> somehow align ourselves with the mess that already exists with >> URIs in general? > > And, noting Dale's comments, if 3986 is taken to imply that all > URIs are expected to support relative forms, then what should be > done about SIP and other URIs, some very heavily-used, that > don't support relative references either? For URNs, would a > revised version of draft-ietf-urnbis-semantics-clarif do the job > of clarifying that relative references are not applicable, or > does something have to be done to 3986? I believe that a URI scheme shouldn't say "they aren't applicable". What it *can* say is "they don't make sense, so be careful". Best regards, Julian From nobody Mon Oct 20 08:28:43 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EA81A1B36 for ; Mon, 20 Oct 2014 08:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPTlBSRCgRJR for ; Mon, 20 Oct 2014 08:28:32 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8685B1A1AD8 for ; Mon, 20 Oct 2014 08:21:29 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XgElw-000570-Gq; Mon, 20 Oct 2014 11:21:24 -0400 Date: Mon, 20 Oct 2014 11:21:19 -0400 From: John C Klensin To: Julian Reschke , Andrew Newton Message-ID: <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> In-Reply-To: <54451F2E.3060909@gmx.de> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/HvMwhlA2etscjil7Fad74vn6x04 Cc: urn@ietf.org, Peter Saint-Andre - &yet Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:28:36 -0000 --On Monday, October 20, 2014 16:41 +0200 Julian Reschke wrote: > I believe you should say that URIs using the "URN" scheme work > exactly the same way as any other URI, and that that behavior > is defined by RFC 3986. Just trying to understand here... In other words, you believe that all URIs are required to be hierarchical and to support relative references into that hierarchy? How do you reconcile that with the distinctly non-hierarchical URNs specified in RFC 2141, the many documented and deployed URNs that follow that model, including the ones I've described as "indicators" (i.e., the presence or absence of the URN conveys information without any further semantics associated with its value), and other URIs, such as the SIP ones Dale has referenced, that don't have enough implicit or hierarchical structure for relative references to make any sense? Are you suggesting that all of those URIs became non-conforming and invalid with the publication of RFC 3986, even those that appeared after it? john From nobody Mon Oct 20 08:42:47 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227121A01C6 for ; Mon, 20 Oct 2014 08:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Nx4KzNJQ0GP for ; Mon, 20 Oct 2014 08:42:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819541A1AE4 for ; Mon, 20 Oct 2014 08:40:52 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mcgur-1XOR6m05PV-00Hu5A; Mon, 20 Oct 2014 17:40:49 +0200 Message-ID: <54452CFA.4080301@gmx.de> Date: Mon, 20 Oct 2014 17:40:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John C Klensin , Andrew Newton References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> In-Reply-To: <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:wdiHqtdSCun28RjyZZzXRjCIFb6CoeXtE1w4j6YpfyIRiQfOXQA jI3ZonKxMiIJ3UoqooDzE5xz6Y7FiRr+nBH+dZ+WcJ1/ngqVB0NpOcOEnlZPFJOTn6td5it ZyfucMH9jrcJgzSLz8WymigqXbMyazRbpa21c18UtwyAofWrhg/hA4EzMq/tUKJUXJToRrQ 6ZrnGHVEMX2UKeA7Vz17w== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/dE5ofUs6ydyLfFuk_e1JjndlrHc Cc: urn@ietf.org, Peter Saint-Andre - &yet Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:42:45 -0000 On 2014-10-20 17:21, John C Klensin wrote: > > > --On Monday, October 20, 2014 16:41 +0200 Julian Reschke > wrote: > >> I believe you should say that URIs using the "URN" scheme work >> exactly the same way as any other URI, and that that behavior >> is defined by RFC 3986. > > Just trying to understand here... > > In other words, you believe that all URIs are required to be > hierarchical and to support relative references into that > hierarchy? No. I believe that the rules for the relative reference resolution need to be independent of the URI scheme. It's fine if a URI scheme isn't hierarchical, in which case these rules will yield "surprising" results. > ... Best regards, Julian From nobody Mon Oct 20 10:25:07 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955E91A6F3F for ; Mon, 20 Oct 2014 10:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6ZNInKMCj2z for ; Mon, 20 Oct 2014 10:25:01 -0700 (PDT) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140C21A7014 for ; Mon, 20 Oct 2014 10:25:01 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id at20so5180061iec.12 for ; Mon, 20 Oct 2014 10:25:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=33s9maeUpjsT5pqQob3yCpfwBLyYqMcjpBMBWvdx/Qc=; b=YplPg9nn7ub/eg0YeQs3Fo1xGops6f7CN+hQdLS9BMffHUsbc7OEoqak5gjb6neKRS verlnEXigyHf19XmyxqzY2zX9NF+6cjVIEV//mCPOjnH7QFyaafp7I6OwLF5Qi0xSPzp feIGAfCLRsio3ckWhEfsoIiMgwYNjhKsLHAdycIfun0kpL4QVkFy5zMxOytTSV6+u2OC xaCtsXWl/Kimy3rzh9cphOI87RUcSX7nwtMNjxFI8Fj/KlIuq9PSIiBY8Ni+uJ2dr58d PVoF3TK7YHoISuWIC0FmS+P5TpAtYIfDsfEoJ4+gubmkpMlW82HxYQVJJFyfw2UAsbt3 8kWw== X-Gm-Message-State: ALoCoQlK6jofAnvtNWUOSAbNZctvOzRKvwWOzohFLekUXrPXq/MUidYGy73srypbcbPpWvwm9Uvf X-Received: by 10.50.43.231 with SMTP id z7mr20300686igl.36.1413825900379; Mon, 20 Oct 2014 10:25:00 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id w8sm4082208igl.13.2014.10.20.10.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 10:24:59 -0700 (PDT) Message-ID: <54454569.9040606@andyet.net> Date: Mon, 20 Oct 2014 11:24:57 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julian Reschke , John C Klensin , Andrew Newton References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> In-Reply-To: <54452CFA.4080301@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/GfeH1ZS42cim3vJUsMgOmtrsxPE Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 17:25:03 -0000 On 10/20/14, 9:40 AM, Julian Reschke wrote: > On 2014-10-20 17:21, John C Klensin wrote: >> >> >> --On Monday, October 20, 2014 16:41 +0200 Julian Reschke >> wrote: >> >>> I believe you should say that URIs using the "URN" scheme work >>> exactly the same way as any other URI, and that that behavior >>> is defined by RFC 3986. >> >> Just trying to understand here... >> >> In other words, you believe that all URIs are required to be >> hierarchical and to support relative references into that >> hierarchy? > > No. > > I believe that the rules for the relative reference resolution need to > be independent of the URI scheme. It's fine if a URI scheme isn't > hierarchical, in which case these rules will yield "surprising" results. Julian, do you think that 2141bis needs to have some text on this point? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Oct 20 11:03:35 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351821A8A95 for ; Mon, 20 Oct 2014 11:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5dTxV06sySR for ; Mon, 20 Oct 2014 11:03:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CED71A8A90 for ; Mon, 20 Oct 2014 11:03:32 -0700 (PDT) Received: from [192.168.2.160] ([93.217.94.54]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MVsUW-1Xe3I62nuq-00X2DW; Mon, 20 Oct 2014 20:03:18 +0200 Message-ID: <54454E5F.9030702@gmx.de> Date: Mon, 20 Oct 2014 20:03:11 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , John C Klensin , Andrew Newton References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <54454569.9040606@andyet.net> In-Reply-To: <54454569.9040606@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:YXJ8U+SA7G3x4I7kCQpNEg55RKgH/7SSO+1gfIWqOzyTde4CCwh 0TAHI6nZogz/Qq41+qtEYThUmYiLupCA2Vpiiyd/H9xMC3romrzkrG8ioq9T43XW15OVzIb RJMCCDHUtcVAqSTlu5ZOn6ixqTHcJGKJ1GqywxcXwvsM3aWIEGHS0HsKlwprUnWPFwDdTMU lNtcKU9iTmbrPgJX5lJow== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/yy53VggXLCeYCu1vJ2yuOodY9hw Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:03:34 -0000 On 2014-10-20 19:24, Peter Saint-Andre - &yet wrote: > On 10/20/14, 9:40 AM, Julian Reschke wrote: >> On 2014-10-20 17:21, John C Klensin wrote: >>> >>> >>> --On Monday, October 20, 2014 16:41 +0200 Julian Reschke >>> wrote: >>> >>>> I believe you should say that URIs using the "URN" scheme work >>>> exactly the same way as any other URI, and that that behavior >>>> is defined by RFC 3986. >>> >>> Just trying to understand here... >>> >>> In other words, you believe that all URIs are required to be >>> hierarchical and to support relative references into that >>> hierarchy? >> >> No. >> >> I believe that the rules for the relative reference resolution need to >> be independent of the URI scheme. It's fine if a URI scheme isn't >> hierarchical, in which case these rules will yield "surprising" results. > > Julian, do you think that 2141bis needs to have some text on this point? It it's completely silent that would be technically ok. However, it might cause confusion among some readers that somehow come to the conclusion that RFC 3986 does not apply. Thus, it would be good to state once for all and upfront that "URN" URIs are really URIs with all implications stated by RFC 3986. Best regards, Julian From nobody Mon Oct 20 11:10:20 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126371A8A08 for ; Mon, 20 Oct 2014 11:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5V6j1IhcCNGD for ; Mon, 20 Oct 2014 11:09:51 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605A01A8AAC for ; Mon, 20 Oct 2014 11:09:38 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so5280739ieb.14 for ; Mon, 20 Oct 2014 11:09:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DlNQEwmqWW6Tc4kiMTMHnMyVO4jdTmZIcCkDUo1LktM=; b=E9al7xyOqwDkqbg0iAMYMk92PYC4YOjZYR5MxW5uWCTnPiZNjPS5gi/YXG+GC43zV2 J2yNVFbvpplfxJctowhY2F0xDeOTcAPdLD27wZ59aBcwGil1TRBoesOOC2GoJiAXag// Bx4xy3sqhHoaSxsvPSzDL12LZ7EgoVeMSeNbiwoL17E8vS3oIglz+PXW5+p/QJMbS5jt p+wLi32EJrekj4nAJ8NxZYOegghAtexGC2m8LWKvFuKUr8guSqIKc9wKXLqlXiMkmJT0 UIjCNaZZabiWOvSARrwxSFzGg87ahauy+Z4zcmbWAtUoUmMvFCX9oTmtZifPw40kr7XL ClLA== X-Gm-Message-State: ALoCoQlgnxgxHceozlg8h/lPUNpyqbLyiOM82kz82wVhmR4J1hWQHLZpO7E8HeQ2FV1Cz8Oejt8u X-Received: by 10.42.212.7 with SMTP id gq7mr29275180icb.32.1413828577747; Mon, 20 Oct 2014 11:09:37 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id b4sm4837676iod.37.2014.10.20.11.09.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 11:09:37 -0700 (PDT) Message-ID: <54454FDF.4070603@andyet.net> Date: Mon, 20 Oct 2014 12:09:35 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julian Reschke , John C Klensin , Andrew Newton References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <54454569.9040606@andyet.net> <54454E5F.9030702@gmx.de> In-Reply-To: <54454E5F.9030702@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/nPu0OZ9CyJNRKXAL0IFUWxXRfuE Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:10:02 -0000 On 10/20/14, 12:03 PM, Julian Reschke wrote: > On 2014-10-20 19:24, Peter Saint-Andre - &yet wrote: >> On 10/20/14, 9:40 AM, Julian Reschke wrote: >>> On 2014-10-20 17:21, John C Klensin wrote: >>>> >>>> >>>> --On Monday, October 20, 2014 16:41 +0200 Julian Reschke >>>> wrote: >>>> >>>>> I believe you should say that URIs using the "URN" scheme work >>>>> exactly the same way as any other URI, and that that behavior >>>>> is defined by RFC 3986. >>>> >>>> Just trying to understand here... >>>> >>>> In other words, you believe that all URIs are required to be >>>> hierarchical and to support relative references into that >>>> hierarchy? >>> >>> No. >>> >>> I believe that the rules for the relative reference resolution need to >>> be independent of the URI scheme. It's fine if a URI scheme isn't >>> hierarchical, in which case these rules will yield "surprising" results. >> >> Julian, do you think that 2141bis needs to have some text on this point? > > It it's completely silent that would be technically ok. However, it > might cause confusion among some readers that somehow come to the > conclusion that RFC 3986 does not apply. > > Thus, it would be good to state once for all and upfront that "URN" URIs > are really URIs with all implications stated by RFC 3986. I think that 2141bis already effectively says this, but I will review the text again to make sure that the next version is as clear as possible. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Oct 20 11:27:12 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBA11A8ADE for ; Mon, 20 Oct 2014 11:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7hLhhqiKRWN for ; Mon, 20 Oct 2014 11:27:05 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A894B1A8AA7 for ; Mon, 20 Oct 2014 11:27:05 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XgHfW-0005Sf-HQ; Mon, 20 Oct 2014 14:26:58 -0400 Date: Mon, 20 Oct 2014 14:26:53 -0400 From: John C Klensin To: Julian Reschke , Andrew Newton Message-ID: <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> In-Reply-To: <54452CFA.4080301@gmx.de> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/QCelyG0MdwcUVJO9DncwMcst3PE Cc: urn@ietf.org, Peter Saint-Andre - &yet Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:27:08 -0000 --On Monday, October 20, 2014 17:16 +0200 Julian Reschke wrote: > I believe that a URI scheme shouldn't say "they aren't > applicable". What it *can* say is "they don't make sense, so > be careful". --On Monday, October 20, 2014 17:40 +0200 Julian Reschke wrote: >> In other words, you believe that all URIs are required to be >> hierarchical and to support relative references into that >> hierarchy? > > No. > > I believe that the rules for the relative reference resolution > need to be independent of the URI scheme. It's fine if a URI > scheme isn't hierarchical, in which case these rules will > yield "surprising" results. Ok. At least now I understand what you are suggesting. That is progress. However, it identifies a small (or maybe not-so-small) philosophical disagreement. First, I think that, when Section 1.2.3 of RFC 3896 says "For some URI schemes, the visible hierarchy is limited to the scheme itself: everything after the scheme component delimiter (":") is considered opaque to URI processing." it implies that we can say "For the 'urn' scheme, there is no URI processing beyond scheme identification. Therefore relative reference processing (which is definitely URI processing) does not apply and, incidentally, any discussion of 3986 beyond basic parsing of into components is irrelevant." Second and more fundamentally, I believe that designing protocols with the intent that even the most carefully-written implementations will cause potentially-nasty surprises is just wrong, to the point that words like "evil" and "immoral" occur to me. If 3986 actually requires that any system evaluating URIs apply relative reference processing even when it will yield bizarre and meaningless results, then I would contend that is a seriously bad specification. I don't see any such requirement in 3986. What is see instead is a set of rules for applying and interpreting relative references for schemes for which they are relevant. I wish that were a lot more clear (either way), but don't see a problem with my reading. I wish this had come up in Toronto when it looked like separating URNs more clearly from 3986 semantics --or, if one prefers, treating all of the semantics in 3986 as advisory rather than mandatory issues to be decided on a per-scheme basis. If I had thought about relative references at all at that time, I would have assumed they were part of what we were discussing as semantics because they are clearly not part of the ABNF or even discussions of it. But here we are, back to discussing what 3986 requires URNs to be or do. And, fwiw, even if we simply discarded "urn:" (something that would not fly in the marketplace and would just lead to non-IETF URN specs) and started moving forward with some new URx", we would still have this relative reference problem. That said, if it would get us unstuck and this were absolutely the last "URNs can't do or be that because of what 3986 can be interpreted to say" discussion we needed to have, I could live with "they don't make sense, so be careful" language in the spec. I wouldn't be happy, but we really do need to get unstuck unless the goal is kill URNs, or at least an IETF URN definition, by raising objections one at a time until everyone gives up. john From nobody Mon Oct 20 12:14:42 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A8E1A923B for ; Mon, 20 Oct 2014 12:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysMUexCObqZe for ; Mon, 20 Oct 2014 12:14:37 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7FEF1A9233 for ; Mon, 20 Oct 2014 12:14:36 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XgIPb-0005Vp-O9; Mon, 20 Oct 2014 15:14:35 -0400 Date: Mon, 20 Oct 2014 15:14:30 -0400 From: John C Klensin To: "Dale R. Worley" Message-ID: <7A72CB34E0CA5230634E06FB@JcK-HP8200.jck.com> In-Reply-To: <201410201512.s9KFC2Au013270@hobgoblin.ariadne.com> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <019C8C4D8E78A3F52A53CFB3@JcK-HP8200.jck.com> <201410201512.s9KFC2Au013270@hobgoblin.ariadne.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/npw-zD72OmOZmKnSM4vgM1bjob4 Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 19:14:40 -0000 --On Monday, October 20, 2014 11:12 -0400 "Dale R. Worley" wrote: >> From: John C Klensin > >> But we'd heard arguments on this mailing list that there are >> some information elements (independent of binding to syntax >> components) that really should be included in comparisons (if >> they don't match, the URNs don't either) and others that >> should not (if they don't match, it isn't important and the >> URNs are equal anyway). > > I see the designation at this time that a component is not > significant for equality comparison as risky. If in the > generic URN specification all components are significant, then > NID definitions can later say that particular components are > not significant. But if we say in the generic URN > specification that a particular component is not significant, > then all NID definitions inherit that rule. Yes, they do. On the other hand, at least to my knowledge, no one has yet shown a requirement for a p-component for any NID, at least a requirement that cannot be satisfied by a q-component or f-component. I've argued for allowed p-components precisely to allow a piece of syntax that makes a URN-wide comparison distinction that is not covered by the NID and NSS. If there is no need to have such a distinction -- that all URNs are either character-for-character identical (see 3986 Section 6.2.1) or they will not compare equal by anything that doesn't understand the details of the NSS -- then I don't see a need for the syntactic clutter of allowing p-components at all. Again, because of the generic comparison rules in 3986, a processor that is not specific to the URN scheme is free to treat just about anything it likes other than an exact bit-for-bit comparison as not-matching so it isn't even clear that the rule you are asking for has any practical effect. So, unless you are thinking about example cases that haven't occurred to me (in which case your explaining them would help), what problem do you see with: (i) Allowing p-components, remembering the RFC 2141 does not allow them (or q- or f-components) at all. (ii) Telling designers of new URN namespaces and associated syntax that they are not allowed to use p-components unless they want this particular comparison behavior. If they want the comparison behavior you think appropriate, they should confine themselves to the use of q- and/or f-components (or avoid components in addition to the NID:NSS combination entirely). It seems to me that allows namespace URN syntax designers maximum flexibility without costing us any functionality, but maybe I'm missing something. There _is_ another difficulty wrt p-components, which is associated with the way the syntax of RFC 3986 is defined. If you look at Section 3 of that document, and compare the "hier-part" syntax in its first paragraph with the syntax in Section 3.3 and the examples in the third paragraph of Section 3, you will discover that... (i) There is no ABNF production with on the RHS but the beginning of Section 3 has , , , and on the RHS of . Then Section 3.3 has on the LHS and five separate "* definitions on the RHS. The second paragraph of Section 3 does say "five different ABNF rules..." and points to 3.3, so it is plausible to believe that the omission of was just an error in the list, but it then seems to invoke an RHS pattern-matching operation that is definitely not allowed by anything I can find in RFC 5234. Given the absence of a RHS pattern matching in ABNF, and since has no RSH anchor, it is not clear that is valid for use in URIs at all or how it connects to the syntax if it is. (ii) The examples and small piece of artwork identify URNs as being part of the "path", with no authority. If we accept that, then Peter's p-component is really not the whole path, but only the part of the path that follows the first slash if it is present, i.e., that the generic syntax for the URN scheme is "urn:"NID ":" NSS ["/" p-component] ["?" q-component] ["#" f-component] and not "urn:" path ["?" q-component] ["#" f-component] as one might infer from 3986. > I am willing to be swayed if somone proposes that a > *particular* component should be non-significant, and everyone > agrees that that is so. But in a discussion of this high > level of generality, I don't see that happening. First, note that 3986 requires that "two URIs that differ only by the suffix "#" are considered different regardless of the scheme". While that very global statement is buried in Section 6.2.3, it can be read as applying to all comparisons that are not strictly character by character equal. On the other hand, if what is really means is that two URIs, one of which has no "#" and the other of which has "#" and an empty fragment (which 3986 appears to allow because in not in brackets on the RHS of but has an RHS starting in "*" and not, e.g., "1*" on its RHS in Section 3.5), and two URNs with different non-empty fragements might still be the same on a scheme basis, then we might define it either way for URNs. [1] But I think what is being proposed is exactly that, for comparison): * The NID is significant * The NSS is significant * Any p-component that is present is significant (of course the NID definition may make any URN-string containing a p-component invalid) * As part of what 3986 describes as Scheme-based Normalization, any q-component that is present is not significant (with the same comment about the NID -- two URNs comparing equal or not equal doesn't make either one valid). * If we follow what I infer from the above is the intent of RFC 3968 (see above), any f-component that is present is significant. If not, we can treat it either way but probably should be clear about it. > Saying in the generic specification that all components are > significant is the safe choice with regard to future > extensibility. Yes. But is is also the worst choice with regard to functionality and to any URN that really wants comparison to succeed, regardless of the value or presence or absence of some of those components. See the remarks about 3986 above, but also note that Juha and others have made what I believe is a strong case for some syntax out on the right end of a URN, I think particularly fragments, not counting toward matching whether two URNs are equivalent. We can push it down and specify that on a per-NID basis... or maybe we can't, because: People in this WG should take a careful look at the recently-published RFC 7320, which appears to me to impose very strong constraints on what can be specified below the scheme level. If that is a correct reading, then we really cannot make comparison rules per-NID and, if comparison is important, may be in deep trouble (or at have to justify violating an alleged best practice). I didn't comment on it earlier because I really don't have time to follow even this WG carefully and because, when it was under active discussion, I assumed it wouldn't apply to URNs [2]. best, john [1] FWIW at this point, it is this exact type of discussion, including the one about relative references (which I had not spotted earlier) that led me to believe six months ago that the only way for the URN effort to move forward was to completely separate it from whatever 3986 said or whatever people could read into it. I understand and agree with the principle that a generic URI parser should be able to parse a URN, at least to the extent represented by the production in 3986. But, as we are taken into territory in which we have to worry about whether something is permitted (or prohibited) on an NID basis rather than for all URNs or about whether 3986 requires support for particular operations, it seems to me that 3986 and discussions about it are impeding actual discussion about URN requirements, rather than moving us forward. As we came out of the Toronto discussion, I hoped, as did others, that "URI syntax only" would untie the knot without the far more drastic approach of "URNs are now URIs". But I'm now starting to wonder. From nobody Mon Oct 20 12:50:42 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E52A1ACD49 for ; Mon, 20 Oct 2014 12:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H525i3gVMqWw for ; Mon, 20 Oct 2014 12:50:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F181ACD48 for ; Mon, 20 Oct 2014 12:50:28 -0700 (PDT) Received: from [192.168.2.160] ([93.217.94.54]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lev1D-1YUCMj1HlX-00qm32; Mon, 20 Oct 2014 21:50:22 +0200 Message-ID: <54456777.90202@gmx.de> Date: Mon, 20 Oct 2014 21:50:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John C Klensin , Andrew Newton References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> In-Reply-To: <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zgRP8F8A2TF0evRzLSjwgK7uwqRrwR7j7kDDoSsHCWwhsoAIgUc SHgTcKLYMjzVGnRL7gsQKAHZgr8UWaUGaFlOYujOC3hOn8cga3BtPsnFWoQbrxJfrD3c9n7 nmCA9xsj2R7cLddPk9bUea6tLXvoGDFB+F2EUATfNB+oGjybdP7MauMkHG3zQtXgb4H5GyW wQyVDwr3m57uKRXPijIng== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/kjTNVLJsv8nHNNYr99mU_ohdW9I Cc: urn@ietf.org, Peter Saint-Andre - &yet Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 19:50:33 -0000 On 2014-10-20 20:26, John C Klensin wrote: > ... > Ok. At least now I understand what you are suggesting. That is > progress. > > However, it identifies a small (or maybe not-so-small) > philosophical disagreement. I wouldn't call it "philosophical". > First, I think that, when Section 1.2.3 of RFC 3896 says > > "For some URI schemes, the visible hierarchy is limited > to the scheme itself: everything after the scheme > component delimiter (":") is considered opaque to URI > processing." > > it implies that we can say > > "For the 'urn' scheme, there is no URI processing beyond > scheme identification. Therefore relative reference > processing (which is definitely URI processing) does not > apply and, incidentally, any discussion of 3986 beyond > basic parsing of into components is irrelevant." I think that would be misleading, as relative referencing *does* happen. > Second and more fundamentally, I believe that designing > protocols with the intent that even the most carefully-written > implementations will cause potentially-nasty surprises is just > wrong, to the point that words like "evil" and "immoral" occur > to me. If 3986 actually requires that any system evaluating > URIs apply relative reference processing even when it will yield > bizarre and meaningless results, then I would contend that is a > seriously bad specification. It would be helpful if you could propose a less "immoral" way to resolve relative references that is both scheme-agnostic *and* consistent with what the world expects from widely deployed URI schemes (such as FTP and HTTP). > I don't see any such requirement in 3986. What is see instead > is a set of rules for applying and interpreting relative > references for schemes for which they are relevant. I wish that > were a lot more clear (either way), but don't see a problem with > my reading. > > I wish this had come up in Toronto when it looked like > separating URNs more clearly from 3986 semantics --or, if one > prefers, treating all of the semantics in 3986 as advisory > rather than mandatory issues to be decided on a per-scheme > basis. If I had thought about relative references at all at > that time, I would have assumed they were part of what we were > discussing as semantics because they are clearly not part of the > ABNF or even discussions of it. But here we are, back to > discussing what 3986 requires URNs to be or do. And, fwiw, even > if we simply discarded "urn:" (something that would not fly in > the marketplace and would just lead to non-IETF URN specs) and > started moving forward with some new URx", we would still have > this relative reference problem. Could you clarify what the actual "problem" is that you are referring to? > ... Best regards, Julian From nobody Mon Oct 20 13:18:10 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD871ACD91 for ; Mon, 20 Oct 2014 13:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWpEbtBvz6il for ; Mon, 20 Oct 2014 13:18:05 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1100F1AC3CE for ; Mon, 20 Oct 2014 13:18:04 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id a13so18949igq.10 for ; Mon, 20 Oct 2014 13:18:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=r4OKz96RMKGWZ7V/ZKwFmxFYlVaRVK3+h2DXn0aHrls=; b=UKUtzjF/5h9WNBPWX7Wv3ncdsC7fgmcTsiI7vOFI/VMiKhOvo37dWlVHhjRag07GTi JsjHggGEpwbT0VDe1vglsvj1aRNGuoMm/NVQv8N8uwdT0ukNlgdu7Y1NdhDJM8UGBSni Bd8z/CFbtuTvtvB46oCmvmHXUkw+ElpmyjLIBCj0L/FR2rGifBdqVcR0E0auKqCj21GU 3CL5VbDu8dtGf0TJHkrAztArmqGBmvLvtuHFPq1o8Hk5Qm5n/yzD2b8C6rU/F5CGraGP FPG/XUoLvWzcNITJ+Fis0ca72Mp+AR5KAHYjknNVUzIMZBKWwK9041Hz/hOxAxHtG3bz 1eIQ== X-Gm-Message-State: ALoCoQnFOySGAkmFmE5HU5VCwmaH00qIbmuNTrecW6MM+oiRioQ+bkNVP88TzPjhwutRM7OGK1hG X-Received: by 10.107.15.80 with SMTP id x77mr4682154ioi.13.1413836284240; Mon, 20 Oct 2014 13:18:04 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id v133sm5012987ioe.18.2014.10.20.13.18.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 13:18:03 -0700 (PDT) Message-ID: <54456DF9.5000501@andyet.net> Date: Mon, 20 Oct 2014 14:18:01 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julian Reschke , John C Klensin , Andrew Newton References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> <54456777.90202@gmx.de> In-Reply-To: <54456777.90202@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/uAYBvhpYBlUkkllp-2g7K8sIMKo Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:18:08 -0000 On 10/20/14, 1:50 PM, Julian Reschke wrote: > On 2014-10-20 20:26, John C Klensin wrote: >> ... >> Ok. At least now I understand what you are suggesting. That is >> progress. >> >> However, it identifies a small (or maybe not-so-small) >> philosophical disagreement. > > I wouldn't call it "philosophical". > >> First, I think that, when Section 1.2.3 of RFC 3896 says >> >> "For some URI schemes, the visible hierarchy is limited >> to the scheme itself: everything after the scheme >> component delimiter (":") is considered opaque to URI >> processing." >> >> it implies that we can say >> >> "For the 'urn' scheme, there is no URI processing beyond >> scheme identification. Therefore relative reference >> processing (which is definitely URI processing) does not >> apply and, incidentally, any discussion of 3986 beyond >> basic parsing of into components is irrelevant." > > I think that would be misleading, as relative referencing *does* happen. > >> Second and more fundamentally, I believe that designing >> protocols with the intent that even the most carefully-written >> implementations will cause potentially-nasty surprises is just >> wrong, to the point that words like "evil" and "immoral" occur >> to me. If 3986 actually requires that any system evaluating >> URIs apply relative reference processing even when it will yield >> bizarre and meaningless results, then I would contend that is a >> seriously bad specification. > > It would be helpful if you could propose a less "immoral" way to resolve > relative references that is both scheme-agnostic *and* consistent with > what the world expects from widely deployed URI schemes (such as FTP and > HTTP). Morality aside, I don't understand why it is the responsibility of the URNBIS WG to define a scheme-independent and consistent way to resolve relative references in URIs. Consider the transition from RFC 2368 to RFC 6068 for the "mailto" scheme. RFC 6068 doesn't talk about relative references, and it surely doesn't attempt to clarify RFC 3986 in this regard. All it does it modernize the definition of the "mailto" scheme from the pre-3986 world to the post-3986 world. Why would the transition for the "urn" scheme be any different in this respect? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Oct 20 13:34:32 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCCC1ACE24 for ; Mon, 20 Oct 2014 13:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyHvXtpl70bQ for ; Mon, 20 Oct 2014 13:34:30 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F541ACE15 for ; Mon, 20 Oct 2014 13:34:30 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so5871292pad.22 for ; Mon, 20 Oct 2014 13:34:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iW6i9FZGcixY2nzAPAn8Aldmz8PdzkyP3H6G+5hIBLE=; b=D959pEcROY91FABL43/hW5DyM+6VqP/kS6Es3DgcwCgHOeI4KKte67Mjs/QJdW4RsD jrseak5d117ShUIARo4GYJA1zUGEhZmXuv/3SXie4ubABFGnDByh5qmQ4kVXJUAt+yOa qlpOB1xwvxiyeci+EvVOdkXzGIMmvadlifp6N4zsJQsAclPq5IlTR5Y+L9imZ8N2XsfZ U2qFbKCKFSB75yPTnEkz0WLxSjzP5QTTCjKQXtCXPpYnD0ru+Pk8OSs1OMub0oEh2v+H ++6CfrpCr+bjtObNvkaG1HtQLQlTPhMBhBdcCgsEnYxe9sywFD4rrGlsL2d+BZHIOuy6 HcEA== X-Gm-Message-State: ALoCoQkCJOkGbQRy1+uJ6gJ4AnG8VkWxbxauhthbBUZQv/jgxfvuHKDmCO4G7XTR27KFoFARBEK9 MIME-Version: 1.0 X-Received: by 10.70.48.202 with SMTP id o10mr30180086pdn.63.1413837270281; Mon, 20 Oct 2014 13:34:30 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Mon, 20 Oct 2014 13:34:30 -0700 (PDT) X-Originating-IP: [2001:500:4:15:dd36:f138:c0f0:cbf2] In-Reply-To: <54456DF9.5000501@andyet.net> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> <54456777.90202@gmx.de> <54456DF9.5000501@andyet.net> Date: Mon, 20 Oct 2014 16:34:30 -0400 Message-ID: From: Andrew Newton To: "Peter Saint-Andre - &yet" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/ezLND2BDA2uowr9vFN_Su3jghow Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:34:32 -0000 On Mon, Oct 20, 2014 at 4:18 PM, Peter Saint-Andre - &yet wrote: > On 10/20/14, 1:50 PM, Julian Reschke wrote: >> >> It would be helpful if you could propose a less "immoral" way to resolve >> relative references that is both scheme-agnostic *and* consistent with >> what the world expects from widely deployed URI schemes (such as FTP and >> HTTP). > > > Morality aside, I don't understand why it is the responsibility of the > URNBIS WG to define a scheme-independent and consistent way to resolve > relative references in URIs. I agree. It is not the job of this WG to fix generic URIs problems. Relative referencing seems to be problematic for many URI schemes. If we'd like to clarify how it works with URNs, that is a different matter. -andy From nobody Mon Oct 20 13:40:09 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C441ACE56 for ; Mon, 20 Oct 2014 13:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of-A1meZulOO for ; Mon, 20 Oct 2014 13:40:02 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021F81ACE4F for ; Mon, 20 Oct 2014 13:40:01 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id g10so5686392pdj.32 for ; Mon, 20 Oct 2014 13:40:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=MKruLj4VpUZwbeUhsSaHih7+SKnNyR1GsACvj78v4JY=; b=DBzdWbz8xw0NID0knBNw5cLCHsF2PdxaL0PhpGcZjE6GfoTWUa9IpTQQx9Ct1dQ8ux k2cLU2zpVxiS1UQkOfmL5ZEgBTS0uFKZ1geVv3nS9PgQG8rITUBFQxOkrzd/vDcWeMb1 BkCNTdBfZGnweMbB2vaw/0MA4I/URB9qTfP37fbQ+CgqrsXvqKAVVhZuSkJ5vlOPOlJ6 4SS3Gx/nNPUF2JkPCkoH18HhbSO19aqgILuqbC8lqJk4PO+WB8X1RJYUsmhM+lUQMEE8 otneTiNWTEff1f6NEH+YV8qXtOUZ76gC3mXin7SprHoq5nEOb87wFf4L95GjWGRccV8F zZag== X-Gm-Message-State: ALoCoQnoYQqncaB8R6BO2noWYW7xK7CSBtAPXV0AuQXnTFdziElvWxqM6mieFpjs5NAg0m+Kwcpg MIME-Version: 1.0 X-Received: by 10.70.43.141 with SMTP id w13mr29750993pdl.3.1413837601536; Mon, 20 Oct 2014 13:40:01 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Mon, 20 Oct 2014 13:40:01 -0700 (PDT) X-Originating-IP: [2001:500:4:15:dd36:f138:c0f0:cbf2] In-Reply-To: References: Date: Mon, 20 Oct 2014 16:40:01 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/78A6Wd97ePVfrJtYe6pXOq80fiY Subject: Re: [urn] Consensus Question Regarding Direction of Work X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:40:03 -0000 It looks like I never officially declared consensus on this. So to put this to rest and set the direction of the working group, it is my opinion that we have rough consensus to proceed with changing the semantics of URN components while trying to remain syntactically compatible with URIs. -andy On Tue, Aug 5, 2014 at 11:50 AM, Andrew Newton wrote: > During our recently completed meeting in Toronto at IETF 90, we > achieved necessary consensus from the meeting participants to focus > our energies on the semantics of the components of URNs with a hopeful > goal of keeping syntax compatible with URIs. In other words, the > separation of URNs from URIs is to be about semantics instead of > syntax (the implication being that we are not wholly separating URNs > from URIs). > > The driving mechanism for this work will be a revision to the > separation Internet-Draft as mentioned by John Klensin. That draft may > or may not turn into an RFC depending on the needed changes to > 2141bis. > > As is IETF practice, I am seeking input from individuals on this > mailing list regarding this decision. Specifically, I am seeking > objections that have not been previously raised. > > -andy > co-chair From nobody Mon Oct 20 14:34:22 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892471ACEFB for ; Mon, 20 Oct 2014 14:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PDZwh0bwIS5 for ; Mon, 20 Oct 2014 14:34:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD65D1A00B7 for ; Mon, 20 Oct 2014 14:34:18 -0700 (PDT) Received: from [192.168.2.160] ([93.217.94.54]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lf0M7-1YUAkC1fH5-00qlP8; Mon, 20 Oct 2014 23:34:15 +0200 Message-ID: <54457FD1.7020007@gmx.de> Date: Mon, 20 Oct 2014 23:34:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , John C Klensin , Andrew Newton References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> <54456777.90202@gmx.de> <54456DF9.5000501@andyet.net> In-Reply-To: <54456DF9.5000501@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fu32sWZTDZ4ZqtL/+9UhIRT3Rbicur5ui6SDtX2U5d947CDUbXo s+1Q7J9ObB4aiaOQ9YRtZHxoUkwpl5j5hLPLzeAaGBKINuWd9Gn5VMyKePYYM2YkkwS8BJL TRJMoCrInGYyxjWDO2WB1PirO5qUpKS+q23cYLw0HsJ9JbH+az07lVZZm/+oAoHhSYVL9FS 3ZMpPINqwu1ZesDDvgCXw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/9NCRM7RGYY8SOK24Q9tXW1hrsEo Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:34:21 -0000 On 2014-10-20 22:18, Peter Saint-Andre - &yet wrote: > ... > Morality aside, I don't understand why it is the responsibility of the > URNBIS WG to define a scheme-independent and consistent way to resolve > relative references in URIs. I agree. My comment was with respect to John: "If 3986 actually requires that any system evaluating URIs apply relative reference processing even when it will yield bizarre and meaningless results, then I would contend that is a seriously bad specification." I read between the lines that he had some idea how this could have been done in a better way; that's why I was asking for a concrete proposal. > Consider the transition from RFC 2368 to RFC 6068 for the "mailto" > scheme. RFC 6068 doesn't talk about relative references, and it surely > doesn't attempt to clarify RFC 3986 in this regard. All it does it > modernize the definition of the "mailto" scheme from the pre-3986 world > to the post-3986 world. Why would the transition for the "urn" scheme be > any different in this respect? The reason why we got here was Dale Worley saying: "This strikes me as consonant with how the IETF operates in many situations. There aren't many operations that need to work consistently on URNs qua URNs: What is the scheme? What is the namespace? A universal syntax restriction (so all URNs can be parsed from their contexts). A universal equality test (that may yield false negatives but must not yield false positives). We need to ensure that those features work consistently within a framework that lets interested parties explore alternative solutions to the problems on which we clearly have no consensus. " To which I replied: "Well, if URNs can be used everywhere URIs are used, there is at least one more common operation which needs to be defined somewhere: resolution of a reference against a base URN." And yes, I failed to mention that this *is* defined by RFC 3986, so we just need to make sure we don't either screw that up. Best regards, Julian From nobody Mon Oct 20 16:48:17 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E6A1A1A3B for ; Mon, 20 Oct 2014 16:48:14 -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 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 NYdmoosIO-S2 for ; Mon, 20 Oct 2014 16:48:13 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4371ACEEC for ; Mon, 20 Oct 2014 16:48:13 -0700 (PDT) Received: from [192.168.1.138] (unknown [74.113.134.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F1DA0509B5 for ; Mon, 20 Oct 2014 19:48:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Mon, 20 Oct 2014 16:48:09 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> <54456777.90202@gmx.de> <54456DF9.5000501@andyet.net> To: "urn@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/uVC3_VMTCd2WRSlD1wK7FrjdCm0 Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 23:48:15 -0000 On Oct 20, 2014, at 1:34 PM, Andrew Newton wrote: > On Mon, Oct 20, 2014 at 4:18 PM, Peter Saint-Andre - &yet > wrote: >> On 10/20/14, 1:50 PM, Julian Reschke wrote: >>> >>> It would be helpful if you could propose a less "immoral" way to resolve >>> relative references that is both scheme-agnostic *and* consistent with >>> what the world expects from widely deployed URI schemes (such as FTP and >>> HTTP). >> >> >> Morality aside, I don't understand why it is the responsibility of the >> URNBIS WG to define a scheme-independent and consistent way to resolve >> relative references in URIs. > > I agree. It is not the job of this WG to fix generic URIs problems. +1 > Relative referencing seems to be problematic for many URI schemes. If > we'd like to clarify how it works with URNs, that is a different > matter. > > -andy > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Mon Oct 20 17:13:29 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAED1ACF96 for ; Mon, 20 Oct 2014 17:13:26 -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 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 Cc6ro03qJzP1 for ; Mon, 20 Oct 2014 17:13:24 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB661ACF8B for ; Mon, 20 Oct 2014 17:13:24 -0700 (PDT) Received: from [192.168.1.138] (unknown [74.113.134.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 86D41509B5 for ; Mon, 20 Oct 2014 20:13:23 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <5443707F.6000609@gmx.de> Date: Mon, 20 Oct 2014 17:13:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <94AADBA3-4677-4B01-A4A1-AF045B1F8C26@seantek.com> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> <5442E7CA.9050208@gmx.de> <5442EC72.9000605@seantek.com> <5443707F.6000609@gmx.de> To: urn@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/w1E5D9SuYZO8Hu46Rb4hsEPJ5U0 Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 00:13:26 -0000 On Oct 19, 2014, at 1:04 AM, Julian Reschke = wrote: > But what if the relative reference is "#a" (and assuming the HTML = contains that anchor)? Still meaningless? Having taken a brief hiatus from this thread, I see that it has now = blown up. :) Let=92s be clear: RFC 3986 says that a relative reference (Section 4.2) = can have some (including none or all) of: p-component (which may or may = not be / delimited), q-component, and f-component (fragment). Relative references only make sense in certain kinds of resources that = are identified by URIs. If the resource is something like HTML and has well-defined fragment = semantics, the fragment component alone, like #a, doesn=92t even need to = invoke URI resolution. It doesn't matter (practically) what the base URI = is because navigation will occur entirely within the document, without = resorting to URI dereferencing machinery. Schemes like mailto: don=92t identify resources that can contain = relative references. Generally speaking, URIs can be used to launch = computing processes or identify things of interest (not necessarily = =93resources=94 of interest). tel: identifies telephone numbers of = interest and generally causes a telephony application to launch; mailto: = only causes a new e-mail message to be created (its purpose really is = not to identify e-mail addresses in any practical sense). So too it is with URNs. The error in reasoning is to assume that a = text/html =93resource=94 is available at urn:ietf:rfc:3986. *If* such a = resource were available, and the resource has a relative reference like = ... and =85, then = mechanically, urn:ietf:rfc:3986#a means something. But urn:ietf:rfc:3986 doesn=92t represent a text/html content like http = does. You=92re supposed to take the information blob =93urn:ietf:rfc:3986=94= and URN-resolve it to something else (possibly the text/html document = itself, in which case, I would argue that the base URI is nothing at = all). It is like saying =93If I am standing on a cloud and am told to go = one step left, where will I be standing?=94 You can=92t stand on clouds = in the sky. To try to bring this back on-point, it is probably best if URNs are not = considered suitable for base URIs. Just like mailto: . Think of a URN as a compact universal nickname, shortcut, or pointer to = somewhere else. *Anywhere* else. Just not itself. It is an interesting thought experiment whether q-components have = meaning in the context of the URN scheme. Then Turn to page 6 in = the paper version of this RFC could make sense. The thought = experiment is defused by saying that URNs can=92t be base URIs. Since a = URN doesn=92t serve as a base URI=97just a pointer to other things=97you = wouldn=92t write that reference anyway. Sean= From nobody Mon Oct 20 18:52:21 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1021ACE42 for ; Mon, 20 Oct 2014 18:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dn912_YoEJFk for ; Mon, 20 Oct 2014 18:52:17 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C591A1A0D for ; Mon, 20 Oct 2014 18:52:17 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id r2so426089igi.11 for ; Mon, 20 Oct 2014 18:52:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mdZ27M0E5Qs5oFpASiM0n9TGQdJHJym7WODjefYhAKw=; b=Z8P2FSE6UisLheVaxvdvdQYcbohWFq6/MRneqE3mRBbgP+mMgVugZhpbazWoOggTmD 9ACENwUH971Yz4hwNniRePXY7bQmrAa5P7Srd1eVsX0G4N1d04Wc8JE4GrRRRIcXTGIE fs7L+WDH+ghRThCj+e3ZfMYNTiI8qlGE5tIsKEFFyIw1zyu+rfpX/WOGOOegcohk7co6 tp1E/Gs0OXW2f0/Gwixj/MR1DgNEZS7fzt1ymdrUxraCcmZDJtkYQKOS/xlORkY6467t eJqW491OWvvLedxoupC9+W/KNIPFMdmDaUEkNwjmgGqpUrwcjRU89NkYenGT76AiJ9IP PjCA== X-Gm-Message-State: ALoCoQnD0cD7zjq6hbnEFdOd3G9BwfJZL/8yZC9e5xUFeYDDvtnvTIWAwM25DLt+jtgca1DDINNh X-Received: by 10.50.30.4 with SMTP id o4mr22219190igh.10.1413856336775; Mon, 20 Oct 2014 18:52:16 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id o192sm5417935ioe.11.2014.10.20.18.52.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 18:52:15 -0700 (PDT) Message-ID: <5445BC4D.4060700@andyet.net> Date: Mon, 20 Oct 2014 19:52:13 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Leonard , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> <5442E7CA.9050208@gmx.de> <5442EC72.9000605@seantek.com> <5443707F.6000609@gmx.de> <94AADBA3-4677-4B01-A4A1-AF045B1F8C26@seantek.com> In-Reply-To: <94AADBA3-4677-4B01-A4A1-AF045B1F8C26@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/exzj5wvXQaFhXjy7UANMHN_W4BI Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 01:52:20 -0000 On 10/20/14, 6:13 PM, Sean Leonard wrote: > > On Oct 19, 2014, at 1:04 AM, Julian Reschke > wrote: > >> But what if the relative reference is "#a" (and assuming the HTML >> contains that anchor)? Still meaningless? > > Having taken a brief hiatus from this thread, I see that it has now > blown up. :) > > Let’s be clear: RFC 3986 says that a relative reference (Section 4.2) > can have some (including none or all) of: p-component (which may or > may not be / delimited), q-component, and f-component (fragment). > > Relative references only make sense in certain kinds of resources > that are identified by URIs. > > If the resource is something like HTML and has well-defined fragment > semantics, the fragment component alone, like #a, doesn’t even need > to invoke URI resolution. It doesn't matter (practically) what the > base URI is because navigation will occur entirely within the > document, without resorting to URI dereferencing machinery. > > Schemes like mailto: don’t identify resources that can contain > relative references. Generally speaking, URIs can be used to launch > computing processes or identify things of interest (not necessarily > “resources” of interest). tel: identifies telephone numbers of > interest and generally causes a telephony application to launch; > mailto: only causes a new e-mail message to be created (its purpose > really is not to identify e-mail addresses in any practical sense). > > So too it is with URNs. The error in reasoning is to assume that a > text/html “resource” is available at urn:ietf:rfc:3986. *If* such a > resource were available, and the resource has a relative reference > like ... and …, then mechanically, > urn:ietf:rfc:3986#a means something. > > But urn:ietf:rfc:3986 doesn’t represent a text/html content like http > does. You’re supposed to take the information blob > “urn:ietf:rfc:3986” and URN-resolve it to something else (possibly > the text/html document itself, in which case, I would argue that the > base URI is nothing at all). It is like saying “If I am standing on a > cloud and am told to go one step left, where will I be standing?” You > can’t stand on clouds in the sky. > > To try to bring this back on-point, it is probably best if URNs are > not considered suitable for base URIs. Just like mailto: . > > Think of a URN as a compact universal nickname, shortcut, or pointer > to somewhere else. *Anywhere* else. Just not itself. > > It is an interesting thought experiment whether q-components have > meaning in the context of the URN scheme. Then href=“?getmimetype=application/pdf#page=6”>Turn to page 6 in the > paper version of this RFC could make sense. The thought > experiment is defused by saying that URNs can’t be base URIs. Since a > URN doesn’t serve as a base URI—just a pointer to other things—you > wouldn’t write that reference anyway. To address this and other points, I propose that we make the following change to the section "Handling of URNs by URI Processors" in 2141bis: OLD The URN syntax has been defined so that URNs can be used in places where URIs are expected. NEW Because a URN is, syntactically, a URI under the "urn" scheme, in theory a URN can be placed in any protocol slot that allows for a URI (e.g., an XML namespace name [XML-NAMES]). However, this does not imply that, semantically, it makes sense in practice to place a URN in a given URI protocol slot; in particular, because a URN does not specify the location of a resource, it is not appropriate to place a URN in a URI protocol slot that points to a resource (examples include the 'href' and 'src' attributes and the element in HTML, as well as the 'xml:base' attribute in XML [XML-BASE]). Where the (informational) references are as follows: [XML-BASE] = http://www.w3.org/TR/2009/REC-xmlbase-20090128 [XML-NAMES] = http://www.w3.org/TR/2009/REC-xml-names-20091208 I would include an informational reference for HTML, but at this point I have no idea what to cite as a stable reference for the HTML specification... Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Oct 20 22:40:33 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862B11AD05F for ; Mon, 20 Oct 2014 22:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8LTJw3PRAAn for ; Mon, 20 Oct 2014 22:40:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA171AD05E for ; Mon, 20 Oct 2014 22:40:29 -0700 (PDT) Received: from [192.168.2.160] ([93.217.94.54]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MVedf-1XdK2m189v-00Z2F7; Tue, 21 Oct 2014 07:40:27 +0200 Message-ID: <5445F1C5.7000203@gmx.de> Date: Tue, 21 Oct 2014 07:40:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Sean Leonard , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> <5442E7CA.9050208@gmx.de> <5442EC72.9000605@seantek.com> <5443707F.6000609@gmx.de> <94AADBA3-4677-4B01-A4A1-AF045B1F8C26@seantek.com> <5445BC4D.4060700@andyet.net> In-Reply-To: <5445BC4D.4060700@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:534MJHdma+5IMY+SC4lP/gD+yqYG23DO+1/mXJVX1rzxh0gVIp/ y7Z9ny50siVwUlkCckkAxxfKeV5MkYK6I/kEj/kO4GUer57wsJswY2xg35OhxwtB6bj84mn +4RTfH30Gg0hviPi7PfLAvEAn5XDUnc40aCx1fkyiamI0rBrm0A0UgzNNb/+55ziwFFxQ9d Tx1Fb5RSuoWJzR4hC1Fjg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/6O9_HFxYwT-yp5AT_3Ue0aPJjTo Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 05:40:31 -0000 On 2014-10-21 03:52, Peter Saint-Andre - &yet wrote: > ... > To address this and other points, I propose that we make the following > change to the section "Handling of URNs by URI Processors" in 2141bis: > > OLD > The URN syntax has been defined so that URNs can be used in places > where URIs are expected. > > NEW > Because a URN is, syntactically, a URI under the "urn" scheme, in > theory a URN can be placed in any protocol slot that allows for a URI > (e.g., an XML namespace name [XML-NAMES]). However, this does not > imply that, semantically, it makes sense in practice to place a URN > in a given URI protocol slot; in particular, because a URN does not > specify the location of a resource, it is not appropriate to place a ...until a resolver is defined. > URN in a URI protocol slot that points to a resource (examples > include the 'href' and 'src' attributes and the element in > HTML, as well as the 'xml:base' attribute in XML [XML-BASE]). I'm ok with "doesn't make sense", but you're still avoiding the answer to "what if it *is* used that way". Can we just clarify that this doesn't overrule RFC 3986? > Where the (informational) references are as follows: > > [XML-BASE] = http://www.w3.org/TR/2009/REC-xmlbase-20090128 > [XML-NAMES] = http://www.w3.org/TR/2009/REC-xml-names-20091208 > > I would include an informational reference for HTML, but at this point I > have no idea what to cite as a stable reference for the HTML > specification... I hear that the W3C is trying to get HTML5 to Full Recommendation before the end of the year. Best regards, Julian From nobody Mon Oct 20 23:09:25 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2312F1AD062 for ; Mon, 20 Oct 2014 23:09:21 -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 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 IwqHkbwNC-3L for ; Mon, 20 Oct 2014 23:09:19 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4CF91A6F9C for ; Mon, 20 Oct 2014 23:09:18 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 74AD9509B5; Tue, 21 Oct 2014 02:09:17 -0400 (EDT) Message-ID: <5445F841.70402@seantek.com> Date: Mon, 20 Oct 2014 23:08:01 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> <5442E7CA.9050208@gmx.de> <5442EC72.9000605@seantek.com> <5443707F.6000609@gmx.de> <94AADBA3-4677-4B01-A4A1-AF045B1F8C26@seantek.com> <5445BC4D.4060700@andyet.net> In-Reply-To: <5445BC4D.4060700@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/KHKxhGbYUy7MPMe70mH0lXq8IxI Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 06:09:21 -0000 On 10/20/2014 6:52 PM, Peter Saint-Andre - &yet wrote: > On 10/20/14, 6:13 PM, Sean Leonard wrote: >> >> On Oct 19, 2014, at 1:04 AM, Julian Reschke >> wrote: >> >>> But what if the relative reference is "#a" (and assuming the HTML >>> contains that anchor)? Still meaningless? >> >> Having taken a brief hiatus from this thread, I see that it has now >> blown up. :) >> >> Let=92s be clear: RFC 3986 says that a relative reference (Section 4.2= ) >> can have some (including none or all) of: p-component (which may or >> may not be / delimited), q-component, and f-component (fragment). >> >> Relative references only make sense in certain kinds of resources >> that are identified by URIs. >> >> If the resource is something like HTML and has well-defined fragment >> semantics, the fragment component alone, like #a, doesn=92t even need >> to invoke URI resolution. It doesn't matter (practically) what the >> base URI is because navigation will occur entirely within the >> document, without resorting to URI dereferencing machinery. >> >> Schemes like mailto: don=92t identify resources that can contain >> relative references. Generally speaking, URIs can be used to launch >> computing processes or identify things of interest (not necessarily >> =93resources=94 of interest). tel: identifies telephone numbers of >> interest and generally causes a telephony application to launch; >> mailto: only causes a new e-mail message to be created (its purpose >> really is not to identify e-mail addresses in any practical sense). >> >> So too it is with URNs. The error in reasoning is to assume that a >> text/html =93resource=94 is available at urn:ietf:rfc:3986. *If* such = a >> resource were available, and the resource has a relative reference >> like ... and =85, then m= echanically, >> urn:ietf:rfc:3986#a means something. >> >> But urn:ietf:rfc:3986 doesn=92t represent a text/html content like htt= p >> does. You=92re supposed to take the information blob >> =93urn:ietf:rfc:3986=94 and URN-resolve it to something else (possibly= >> the text/html document itself, in which case, I would argue that the >> base URI is nothing at all). It is like saying =93If I am standing on = a >> cloud and am told to go one step left, where will I be standing?=94 Yo= u >> can=92t stand on clouds in the sky. >> >> To try to bring this back on-point, it is probably best if URNs are >> not considered suitable for base URIs. Just like mailto: . >> >> Think of a URN as a compact universal nickname, shortcut, or pointer >> to somewhere else. *Anywhere* else. Just not itself. >> >> It is an interesting thought experiment whether q-components have >> meaning in the context of the URN scheme. Then > href=3D=93?getmimetype=3Dapplication/pdf#page=3D6=94>Turn to page 6 in= the >> paper version of this RFC could make sense. The thought >> experiment is defused by saying that URNs can=92t be base URIs. Since = a >> URN doesn=92t serve as a base URI=97just a pointer to other things=97y= ou >> wouldn=92t write that reference anyway. > > To address this and other points, I propose that we make the following = > change to the section "Handling of URNs by URI Processors" in 2141bis: > > OLD > The URN syntax has been defined so that URNs can be used in places > where URIs are expected. > > NEW > Because a URN is, syntactically, a URI under the "urn" scheme, in > theory a URN can be placed in any protocol slot that allows for a UR= I > (e.g., an XML namespace name [XML-NAMES]). However, this does not > imply that, semantically, it makes sense in practice to place a URN > in a given URI protocol slot; in particular, because a URN does not > specify the location of a resource, it is not appropriate to place a= > URN in a URI protocol slot that points to a resource (examples > include the 'href' and 'src' attributes and the element in > HTML, as well as the 'xml:base' attribute in XML [XML-BASE]). Despite my rather strongly opinionated series of e-mails, I actually disagree with this new text. Let me explain. Because URNs have a sort of "wildcard" nature about them, they are very=20 useful as a permanent identifier for an abstract resource that might=20 change over time. Therefore, even though it does not make sense for a=20 web browser to receive an HTML page with a purported base of=20 urn:ietf:rfc:3986, or link to , or whatever= ,=20 it makes sense for a content management system to record those URNs in=20 those places for dynamic substitution when served. Consider, for example, a book recommendation service like Wikipedia.=20 Wikipedia as a non-profit institution probably does not want to be=20 accused of bias by promoting amazon.com links over bn.com links (or=20 whatever bookstore is popular in some local market). Rather than=20 recording hard links to amazon.com AND bn.com and fifteen other=20 bookstores and Google Books and iBooks and whatever, Wikipedia can just=20 record in the content. When served, = Wikipedia can dynamically substitute the URNs for actual, locatable URIs = (URLs) appropriate to the client. A "URN Resolver" service might be said to be the missing link that=20 performs this just-in-time service! Yay. That at least deals with the issue of outbound links. Using a URN in a=20 element is a bit harder to justify off-hand...the overall point=20 being, however, that it might be okay as long as it is substituted for a = true URL that is appropriate to the destination context at the=20 appropriate time. (Which, by the way, is probably a good reason to use=20 this stuff as sparingly as possible in the first place, since a=20 resource retrieved by a functioning URL will supply a healthy dose of=20 context.) Sean From nobody Tue Oct 21 09:23:05 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEFD1A8927 for ; Tue, 21 Oct 2014 09:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNeKRHMZ-dfM for ; Tue, 21 Oct 2014 09:22:59 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2481A8925 for ; Tue, 21 Oct 2014 09:22:59 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-02v.sys.comcast.net with comcast id 5sNo1p0035E3ZMc01sNzev; Tue, 21 Oct 2014 16:22:59 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-18v.sys.comcast.net with comcast id 5sNx1p00S1KKtkw01sNyCy; Tue, 21 Oct 2014 16:22:58 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9LGMvYX019356; Tue, 21 Oct 2014 12:22:57 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9LGMuug019355; Tue, 21 Oct 2014 12:22:56 -0400 Date: Tue, 21 Oct 2014 12:22:56 -0400 Message-Id: <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Julian Reschke In-reply-to: <54451F2E.3060909@gmx.de> (julian.reschke@gmx.de) References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413908579; bh=x8T10ewEa3YIbJltgcatmO+HL9ClwMCMFnZWIN745dk=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Va5qSbToS7m9m/yZY18zmsMuEinAaPu4C2tLnQ2J4xX36lTiHZjPyrgsTeLv0s+9r LtmejK+JswK4Fjv8zojp8wcqFNVMG9CaNRHsdIhYLlqGJsCUNdCKPqMX50yqNV2feX T4q/N4dv66kqFUBdydwK2sqSj46pnU44UwK62CIvBZBJi3ahK5VncDeysLDhgNNkhi FbqE7RRhtfowg7ug/LJ90nkrr36uL8cq2sVtrrO5qNxmwSefXxLrGHWmAi0FjjWs8g q2Yzzx/7Mwhohd2G3V5muNKUDH4hoLmkRI6tXL57fPWe1MjFsV2DoT3rHzxrbhqvOg 4hZu8yCmVNnbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/_RUd10W-XbSHJ1S-lqBkqJ-SSy0 Cc: urn@ietf.org, peter@andyet.net Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:23:01 -0000 > From: Julian Reschke > >> The problem here is that if groups get away with the idea that they just can > >> define what they want (and are not bound by the base spec), we *will* end up > >> with different definitions. That's why I tried to make clear that even if > >> relative reference resolution isn't *important*, it still needs to be > >> defined. > > > > I agree that we should not gloss over relative reference resolution > > (i.e. it is important). But I am unclear as to what you feel we should > > do. Should we have a definition for URNs? Is it ok if we say this > > behavior is undefined? Or are we to somehow align ourselves with the > > mess that already exists with URIs in general? > > I believe you should say that URIs using the "URN" scheme work exactly > the same way as any other URI, and that that behavior is defined by RFC > 3986. > > And no, it's not a mess. I haven't thoroughly checked all the relevant text, but my reading of RFC 3986 in regard to the processing of relative references against a base URI that conforms to RFC 2141 yields this: - The relative reference consists of a "path" part alone, and that path consists of one "segment" (because it does not contain '/'). - The base URI consists of a "scheme" part and a "path" part alone, and the path consists of one "segment". - The target (what the relative reference resolves into) is the scheme of the base URI with the path part of the relative reference. That is, the target URI is the same as the relative reference, with "urn:" prepended. So it seems to me that it's pretty unlikely that anyone has attempted to use in practice relative references relative to a urn: base URI. (Although it appears to be possible in principle. If a document was named by a URN, and retrieved by some mechanism, that URN could be the base URI of relative references in the document.) If we were to extend 2141 to allow "query" and "fragment" parts -- or anything we wanted to consider to be analogous to those -- the direct application of RFC 3986 says that the quasi-query and quasi-fragment parts of the target URI would be copied from those of the relative reference. Which leaves us in the situation where a relative URI provides essentially no additional semantic power. (All of this stems from the fact that, in the notation of RFC 3986 sectoin 5.2.2., (1) R.scheme is undefined (i.e., this is "really" a relative reference, because it has no scheme part), (2) R.authority is undefined (because URNs have no authority part), (3) R.path is non-empty (because the NID is part of the path), (4) R.path does not start with '/', and (5) Base.path does not contain '/'. Given those facts, the resolution algorithm collapses into essentially "T = R".) Now, given this as background, it's not clear to me what you're pushing for. It seems that the current situation is that RFC 3986 applies to relative references against a urn: base URI, and there's no reason for anyone to ever exploit that. And that the current proposals don't seem to change either fact. I suspect that I'm overlooking something. Dale From nobody Tue Oct 21 10:19:06 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340B41A19F6 for ; Tue, 21 Oct 2014 10:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH7sJQYkLtQv for ; Tue, 21 Oct 2014 10:18:59 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8B81A1A05 for ; Tue, 21 Oct 2014 10:18:59 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xgd5E-0008z2-Fk; Tue, 21 Oct 2014 13:18:56 -0400 Date: Tue, 21 Oct 2014 13:18:51 -0400 From: John C Klensin To: Sean Leonard , Peter Saint-Andre - &yet , urn@ietf.org Message-ID: In-Reply-To: <5445F841.70402@seantek.com> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> <5442E7CA.9050208@gmx.de> <5442EC72.9000605@seantek.com> <5443707F.6000609@gmx.de> <94AADBA3-4677-4B01-A4A1-AF045B1F8C26@seantek.com> <5445BC4D.4060700@andyet.net> <5445F841.70402@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/10lB-vJ7VpsRmBVQEAlF2lf-htg Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:19:03 -0000 --On Monday, October 20, 2014 23:08 -0700 Sean Leonard wrote: > Because URNs have a sort of "wildcard" nature about them, they > are very useful as a permanent identifier for an abstract > resource that might change over time. Therefore, even though > it does not make sense for a web browser to receive an HTML > page with a purported base of urn:ietf:rfc:3986, or link to href="urn:ietf:rfc:3986">, or whatever, it makes sense for a > content management system to record those URNs in those places > for dynamic substitution when served. > > Consider, for example, a book recommendation service like > Wikipedia. Wikipedia as a non-profit institution probably does > not want to be accused of bias by promoting amazon.com links > over bn.com links (or whatever bookstore is popular in some > local market). Rather than recording hard links to amazon.com > AND bn.com and fifteen other bookstores and Google Books and > iBooks and whatever, Wikipedia can just record href="urn:isbn:978-0345803481"> in the content. When served, > Wikipedia can dynamically substitute the URNs for actual, > locatable URIs (URLs) appropriate to the client. > > A "URN Resolver" service might be said to be the missing link > that performs this just-in-time service! Yay. > > That at least deals with the issue of outbound links. Using a > URN in a element is a bit harder to justify > off-hand...the overall point being, however, that it might be > okay as long as it is substituted for a true URL that is > appropriate to the destination context at the appropriate > time. (Which, by the way, is probably a good reason to use > this stuff as sparingly as possible in the first place, > since a resource retrieved by a functioning URL will supply a > healthy dose of context.) Sean, Whether the text Peter proposes is adequate or not is another question, but it seems to me that your discussion is mixing "resolve relative references to base URIs", "resolve some UNRs in various creative ways", and a certain amount of DWIM activity together. We also many need some new terminology to avoid confusing ourselves because forms of "resolve" at used for too many different things. urn:isbn:978-0345803481 is just a name or, if you prefer, an embedding of a name. The only thing it "resolves to" globally is ISSN: 978-0345803481 Unless there is mechanism in HTML5 that I don't know about, "" isn't nearly powerful enough to do what you want. Moreover, especially if we want the web to be global, the notion of Wikipedia being able to "resolve" an ISBN URN to a list of one or more booksellers on the basis of the element alone leads us into bad trouble. What you are looking for would be more reasonably represented by something akin to http://www.favority-bookseller-list.wikipedia.com/?urn="isbn:1-4012-9876-1" Which is a perfectly valid http-URL. See Appendix B.3 of draft-ietf-urnbis-semantics-clarif-00.txt for more discussion of that general model More generally, and noting 3986's comments about the loose binding between "scheme" and "protocol", the thing that makes the "urn" scheme different from most or all other URIs (and certainly from the URL ones) is that, for the others, the resolution mechanism is bound to the scheme name, often in conjunction with the authority. In the URN case, the scheme just tells you that everything else is a name, there is no authority, and the NID (which a hypothetical generic URI processor could not parse out or otherwise recognize as more than just part of a no-authority path) cannot be bound to a resolution mechanism because: (1) The hypothetical generic URI processor doesn't work that way; it can use schemes at most because of the 3986 scheme-dependent opacity rule. (2) Unless we develop a whole different theory about what URNs and NIDs are about, any binding of an NID to a resolver must be essentially universal. In other words, Wikipedia cannot, at least without significantly more information that I wouldn't characterize as "resolution" map urn:ietf:rfc:3986 as an href argument of an element into either http://www.favorite-bookseller-list.wikipedia.com/?isbn=1-4012-9876-1 or http://bn.com/?isbn=1-4012-9876-1 while Juha maps the same thing into a shelf reference and someone else maps it to the actual ISBN registry record. Expecting those to work requires a huge dose of DWIM pixie dust or what would essentially be an HTML preprocessor that would seek out hrefs with urn schemes and map them into something else (or some family of other things). We _do_ expect URNs to be used in exactly that way, but some mechanism has to be used to specify how they are to be dereferenced (not necessarily "resolved") to something else. We've talked about that mechanism as part of an extended URN-string (i.e., as part of a p/q/f-component) and about expressing it in the embedded style mentioned above and discussed in the Appendix B of "semantics-clarif-00". I've probably forgotten some other "resolution" discussions -- there have been a lot of them (although not as many distinct ones). Context, as in an information retrieval system used to access specific types of things or that collects information to do its work beyond the URN itself, works too. But HTML , at least unless HTML5 contains provisions for magic, just doesn't. And, AFAICT, none of the above has anything to do with relative references except to further illustrate why they really make no sense, or at least no consistent and predictable sense, for URNs. john p.s. I also believe Dale's "T = R" conclusion and that Andy's consensus note yesterday and draft-ietf-urnbis-semantics-clarif make discussion of relative references essentially moot for URNs unless someone wants to explicitly introduce and require them. From nobody Tue Oct 21 11:07:03 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9B11A876E for ; Tue, 21 Oct 2014 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I55HbNTsSy6 for ; Tue, 21 Oct 2014 11:06:58 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05561A8773 for ; Tue, 21 Oct 2014 11:04:49 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4863450A89; Tue, 21 Oct 2014 14:04:47 -0400 (EDT) Message-ID: <54469FF4.10907@seantek.com> Date: Tue, 21 Oct 2014 11:03:32 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John C Klensin , Peter Saint-Andre - &yet , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> <5442E7CA.9050208@gmx.de> <5442EC72.9000605@seantek.com> <5443707F.6000609@gmx.de> <94AADBA3-4677-4B01-A4A1-AF045B1F8C26@seantek.com> <5445BC4D.4060700@andyet.net> <5445F841.70402@seantek.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090204060105080400050200" Archived-At: http://mailarchive.ietf.org/arch/msg/urn/mbJK3MN7LZat24WfGs3G8VS7W78 Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:07:01 -0000 This is a cryptographically signed message in MIME format. --------------ms090204060105080400050200 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/21/2014 10:18 AM, John C Klensin wrote: > > --On Monday, October 20, 2014 23:08 -0700 Sean Leonard > wrote: > >> Because URNs have a sort of "wildcard" nature about them, they >> are very useful as a permanent identifier for an abstract >> resource that might change over time. Therefore, even though >> it does not make sense for a web browser to receive an HTML >> page with a purported base of urn:ietf:rfc:3986, or link to > href=3D"urn:ietf:rfc:3986">, or whatever, it makes sense for a >> content management system to record those URNs in those places >> for dynamic substitution when served. >> >> Consider, for example, a book recommendation service like >> Wikipedia. Wikipedia as a non-profit institution probably does >> not want to be accused of bias by promoting amazon.com links >> over bn.com links (or whatever bookstore is popular in some >> local market). Rather than recording hard links to amazon.com >> AND bn.com and fifteen other bookstores and Google Books and >> iBooks and whatever, Wikipedia can just record > href=3D"urn:isbn:978-0345803481"> in the content. When served, >> Wikipedia can dynamically substitute the URNs for actual, >> locatable URIs (URLs) appropriate to the client. >> >> A "URN Resolver" service might be said to be the missing link >> that performs this just-in-time service! Yay. >> >> That at least deals with the issue of outbound links. Using a >> URN in a element is a bit harder to justify >> off-hand...the overall point being, however, that it might be >> okay as long as it is substituted for a true URL that is >> appropriate to the destination context at the appropriate >> time. (Which, by the way, is probably a good reason to use >> this stuff as sparingly as possible in the first place, >> since a resource retrieved by a functioning URL will supply a >> healthy dose of context.) > Sean, > > Whether the text Peter proposes is adequate or not is another > question, but it seems to me that your discussion is mixing > "resolve relative references to base URIs", "resolve some UNRs > in various creative ways", and a certain amount of DWIM activity > together. > > We also many need some new terminology to avoid confusing > ourselves because forms of "resolve" at used for too many > different things. > > urn:isbn:978-0345803481 > > is just a name or, if you prefer, an embedding of a name. The > only thing it "resolves to" globally is > ISSN: 978-0345803481 > > Unless there is mechanism in HTML5 that I don't know about, This is not about HTML5. Nor is it about being particularly creative. It = is about processes using syntactically valid inputs and transforming=20 them in such a way that is appropriate for other consumers. urn:isbn:978-0345803481 is a stand-in for any resource related to a book = or publication identified by the ISBN. If you have a server side process = that resolves it into a http: URL (universally compatible) or a data:=20 URL (only compatible with the majority of web browsers since ~2009), the = client web browser will be able to do something useful with it. If you=20 know that the client specifically handles urn:isbn namespaces, you can=20 send it to the client and the client will do its preferred thing with it.= I don't see an operational difference between this and, say, charset=20 capabilities. If a server has text in some charset (iso-2022-jp) and=20 knows that the client doesn't support iso-2022-jp, it can transform the=20 text into a form that the client can understand. > " href...>" isn't nearly powerful enough to do what you want. > Moreover, especially if we want the web to be global, the notion > of Wikipedia being able to "resolve" an ISBN URN to a list of > one or more booksellers on the basis of the element alone > leads us into bad trouble. It's not done on the basis of the element alone. It's done with=20 additional information in the surrounding context or environment--what=20 RFC 2276 identifies as "hints". > What you are looking for would be > more reasonably represented by something akin to > > > http://www.favority-bookseller-list.wikipedia.com/?urn=3D"isbn:1-4012-9= 876-1" No, because: a) that HTTP URL has a hard-coded authority of=20 "www.favority-bookseller-list.wikipedia.com"; b) how can the operator of "www.favority-bookseller-list.wikipedia.com"=20 store its content in a universal way, even if the operator changes its=20 host name or path structure? A very convenient strategy is to use=20 urn:isbn:... directly internally, and transforming that into appropriate = references that a client can understand when the content (HTML) leaves=20 the server. URNs are (or can be) effectively the "environment variable" $(ENV_VAR)=20 of URIs. The specific location can change based on context but the name=20 "ENV_VAR" remains the same. > More generally, and noting 3986's comments about the loose > binding between "scheme" and "protocol", the thing that makes > the "urn" scheme different from most or all other URIs (and > certainly from the URL ones) is that, for the others, the > resolution mechanism is bound to the scheme name, often in > conjunction with the authority. In the URN case, the scheme > just tells you that everything else is a name, there is no > authority, and the NID (which a hypothetical generic URI > processor could not parse out or otherwise recognize as more > than just part of a no-authority path) cannot be bound to a > resolution mechanism because We are in agreement here. URNs are perhaps most useful when they are not = definitionally bound to any *particular* resolution mechanism. But they=20 can be resolved. The resolution is context-dependent. Sean --------------ms090204060105080400050200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3 3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp 3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6 hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MTAyMTE4MDMzMlowIwYJKoZIhvcNAQkEMRYEFIm0n2AszlbJSXH9 T7GDsVWdbvYgMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8 MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQAAdD5/RyRZoCZESHJ5+LPqqQe2vjW1 f3U3x8aob5zD13+kWoHWZ6Bjd8T57e05XHjNFXFcrbqm8aXMWQe0gm+sB/g3MmorEQ63Izge eAJONEIFKulHfCJSqrh8eE3hJmzf2e49d3trZ4iK1jZV+FrmoFri/nr41LhvYs9ZlaYq9Aiw 8lbG0IOW0DbbCRt/ZIa+SmlfP8qRjVUbrllfPFUNw33Jc+U5mis3XFNQH8D288fBO7uV3Ihq YtMcKfZwWjdlopUYICTOB90mYmld9HME4gTwIoh+COUFk/0zAOtsQd+4Ha9FbuKbbUZ9QLms rtuTiERBArh7w8T6Zdjn6vMTAAAAAAAA --------------ms090204060105080400050200-- From nobody Tue Oct 21 11:37:44 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025D61A87AD for ; Tue, 21 Oct 2014 11:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dlv5Wjiz8VLI for ; Tue, 21 Oct 2014 11:37:39 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40721A87A5 for ; Tue, 21 Oct 2014 11:37:28 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-09v.sys.comcast.net with comcast id 5ubH1p0042D5gil01udTJM; Tue, 21 Oct 2014 18:37:27 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-06v.sys.comcast.net with comcast id 5udT1p0041KKtkw01udTWe; Tue, 21 Oct 2014 18:37:27 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9LIbQOn027315; Tue, 21 Oct 2014 14:37:26 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9LIbQlQ027314; Tue, 21 Oct 2014 14:37:26 -0400 Date: Tue, 21 Oct 2014 14:37:26 -0400 Message-Id: <201410211837.s9LIbQlQ027314@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Andrew Newton In-reply-to: (andy@hxr.us) References: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413916647; bh=hZL8ZWJ8aEhkDPEdcaBHa9G8d+LKhszrusC9q/B77iQ=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=qQaYLiOwBIy4RZQh/2YusotKk45m/oCmd/PTbMFGwYjnAT09dOM34ZYP/btFo1mdj vuV663i6QL9gyQDRyrC45nzolELSxWIZyx7tfEZHstJSnwVcbeEP1aTlc9tFAuGKJY QXRUdOGFLO1T4rrCUAKZDA1/m9j3VNH+0mGcGJpi2J49fUNkepfDahdCmoghWT7hh5 9hUK5IgOLm67iaDh6s9LmXixY8W3/m0za2KGuZorDTB+oM/61XXb5K2iHcpq4iGqNQ nbDUxHkhKwNJLDL+TLZ1rizceUppYUZjYgXgMc7+l9UpvuLdIm+8DDaYJyCBSQKu3o zRAbccNlUj5MA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/n1JSHjBenN0qxVqNwtOymohQrOo Cc: urn@ietf.org Subject: Re: [urn] Consensus Question Regarding Direction of Work X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:37:41 -0000 > From: Andrew Newton > > It looks like I never officially declared consensus on this. So to put > this to rest and set the direction of the working group, it is my > opinion that we have rough consensus to proceed with changing the > semantics of URN components while trying to remain syntactically > compatible with URIs. It seems to me that the consensus (though quite rough) is moving toward: - Remaining syntactically compatible with URIs (RFC 3986). - Being upward-compatible with the status quo URN syntax (RFC 2141). - Defining "generic" syntactic extensions to URNs that are analogous to "path segment", "query", and "fragment" in URIs, but placing little or no syntactic constraint on their components. - Minimizing the semantic constraints we place on these extensions. - Explicitly delegating the definition of the semantics and detailed syntax of these extensions to the NID definitions. Dale From nobody Tue Oct 21 11:40:57 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE0B1A6F34 for ; Tue, 21 Oct 2014 11:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_MCPz5NBb1N for ; Tue, 21 Oct 2014 11:40:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B420A1A1BCA for ; Tue, 21 Oct 2014 11:40:54 -0700 (PDT) Received: from [192.168.2.160] ([93.217.123.73]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LsChr-1Y7lil24OV-013vET; Tue, 21 Oct 2014 20:40:52 +0200 Message-ID: <5446A8AE.9050601@gmx.de> Date: Tue, 21 Oct 2014 20:40:46 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Dale R. Worley" References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> In-Reply-To: <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:nJMtJ3+lotAL4TClSQDvBacyUM3qHSyGvXVbiywYbvrN5RtzIDn yqnp0AWYatWj0lwgkebzEo/PZLX7CTDe+YQwYxLhJDXhTGA+ykTDlvTsZLWqA5QpHCV3lKy W7ureQ8laTkTPBBGM5o2KpkTvRXIMXF2WF3vbG/HxYPjTLJnoUGwCoaqSYIcZGKcR2Q9Xhj SI103NgR7TjLqPioGJ9DQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/IYhc4_2cb3CLcCzMfDETWRyL0kQ Cc: urn@ietf.org, peter@andyet.net Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:40:56 -0000 On 2014-10-21 18:22, Dale R. Worley wrote: > ... > Now, given this as background, it's not clear to me what you're > pushing for. It seems that the current situation is that RFC 3986 > applies to relative references against a urn: base URI, and there's no > reason for anyone to ever exploit that. And that the current > proposals don't seem to change either fact. I suspect that I'm > overlooking something. > ... What I'm pushing for is a spec that is sufficiently clear that the relative resolution algorithm defined by RFC 3986 indeed applies to URN URIs, even though the results it yields for most URN schemes might not be very useful. Best regards, Julian From nobody Tue Oct 21 11:42:19 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9AD1A6F34 for ; Tue, 21 Oct 2014 11:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmD_UY7ksRCl for ; Tue, 21 Oct 2014 11:42:13 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738D21A1BCA for ; Tue, 21 Oct 2014 11:42:13 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id h15so1926920igd.16 for ; Tue, 21 Oct 2014 11:42:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=kEYJEo4fzwXVA1egAn4AuNQkjducs5kUdVMbmP6PYK0=; b=cWexumbQ73/UNuCuAdKTe2Avn7lc88lIgMq7sHmC8u5Fx/INCbJVcty+4yx4Qyix1d WKc7pQlQhVJsM8COxq04vuoUw2Nk4+dw3oY3A8qyI7Rev+Z6zVr9/Uaukg7xPY40Beie CD5azp9dqVzSE0EfkTSxwjFTxbfa3tWkIrJik1x8lYhbGc+Am3t3V6RAM2+iHgvUjm4p 6pO4TceGVyj9n/3a2Buq8I7Si/gS9Q0yF9Ngq+q6RiwZyCP4OycmwoUwEKU3A8xg7H4z h4ZQFGoAYNyZG7LOJze2uKdIsNBiHvKCfrplKRXwcJTtiZTPi7i/WEVTs8R6ihZjvcq7 QKsw== X-Gm-Message-State: ALoCoQkga4+NpAK8fuLJmTuQVXbN9QiyVPC/Tx+QOBLIzNF34eBPFqZsYk39QzrUIQmHOhkHtVuL X-Received: by 10.50.234.164 with SMTP id uf4mr28959014igc.46.1413916932911; Tue, 21 Oct 2014 11:42:12 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n84sm6439398ioe.19.2014.10.21.11.42.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 11:42:12 -0700 (PDT) Message-ID: <5446A902.4030904@andyet.net> Date: Tue, 21 Oct 2014 12:42:10 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/5zxAJ8_JOdbT06VialXj0o_bClk Subject: [urn] next steps X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:42:18 -0000 I have a revised I-D almost ready for consideration by the WG, which I plan to submit tonight. Two things to note: 1. Because of his significant contributions to the concepts and text, I have added John Klensin as co-author. 2. To reduce confusion and cross-references (and with approval of the WG chairs), I have combined 2141bis and 3406bis into a single document that covers both URN syntax and URN namespaces. Naturally, there are still some open issues being discussed on the list. I cannot promise that the revised I-D closes them all, but I think it brings us much closer to having a specification we can live with. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Oct 21 12:42:15 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3D51A1BDB for ; Tue, 21 Oct 2014 12:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apfmMOHSRdPn for ; Tue, 21 Oct 2014 12:42:09 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD661A1BD4 for ; Tue, 21 Oct 2014 12:42:08 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so1983725ieb.14 for ; Tue, 21 Oct 2014 12:42:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SQltXp/cC+cJH6sNUVyRldrj3m10v5GLtEVk+TpkfOg=; b=nBSraXsfy8BTEulWDsCeFKjlUn93u0xKbc4LhX/ztBrTuFt2cXOaJ5I+o5OKvHfZ5g qfgLXSd7Bq94zLzH27E5B6QZsYHXBv9HGNzsOUlKAd62nrFA4ipSUjgs5K5ti8LCvD6w q96CiBF+BCHk5LXzsr4PqrNdIz9cQW2PjIZqNyMdOLa0oxsQtuMCEec+b7M02NJSAQHK 8MKQD2Fwy0qUDs3nb/RjDhB4Ir/MBZlqDlGGKrQliPZq2PMFZFiDIzZbPT2O2YPTXvpQ mD8GFXKiYoKcm5DXPWJA+cAqFdsPfvfPuuObQL+IPSZzIIrf9QLiVP+cZ9/kbj3Q68TT 0TLQ== X-Gm-Message-State: ALoCoQm0rspVSvkq2wPvAy+giBWqfdFN9MYjuJlE4xFNpynWL45DMmgT6riU7rkKH5ou4ozcOmTc X-Received: by 10.50.70.40 with SMTP id j8mr365952igu.31.1413920528268; Tue, 21 Oct 2014 12:42:08 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id b184sm6519845ioe.3.2014.10.21.12.42.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 12:42:07 -0700 (PDT) Message-ID: <5446B70D.8040002@andyet.net> Date: Tue, 21 Oct 2014 13:42:05 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julian Reschke , "Dale R. Worley" References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> In-Reply-To: <5446A8AE.9050601@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/4QEMoCnGxme5PO3wNTw5bPe0Qlg Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 19:42:13 -0000 On 10/21/14, 12:40 PM, Julian Reschke wrote: > On 2014-10-21 18:22, Dale R. Worley wrote: >> ... >> Now, given this as background, it's not clear to me what you're >> pushing for. It seems that the current situation is that RFC 3986 >> applies to relative references against a urn: base URI, and there's no >> reason for anyone to ever exploit that. And that the current >> proposals don't seem to change either fact. I suspect that I'm >> overlooking something. >> ... > > What I'm pushing for is a spec that is sufficiently clear that the > relative resolution algorithm defined by RFC 3986 indeed applies to URN > URIs, even though the results it yields for most URN schemes might not > be very useful. I propose the following text: Despite the fact that URNs are not hierarchical and are not appropriate for use as a base URI (see Section 5.1 of [RFC3986]), the relative resolution algorithm specified in Section 5.2 of [RFC3986] still applies to the "urn" URI scheme; implementers need to be aware, however, that running the algorithm against URNs can lead to results that are unexpected or not useful. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Oct 21 13:06:15 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D0F1A6EDE for ; Tue, 21 Oct 2014 13:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V__FkoVDMhn for ; Tue, 21 Oct 2014 13:06:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129851A6EEF for ; Tue, 21 Oct 2014 13:06:11 -0700 (PDT) Received: from [192.168.2.160] ([84.187.52.26]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lp8h6-1YJ0eZ0C9s-00exWN; Tue, 21 Oct 2014 22:06:07 +0200 Message-ID: <5446BCA7.4050504@gmx.de> Date: Tue, 21 Oct 2014 22:05:59 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , "Dale R. Worley" References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <5446B70D.8040002@andyet.net> In-Reply-To: <5446B70D.8040002@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7/+g92RkrWr5eL5YUQFJjbc2JPCjccZD+z6/gPzeRg+jcwndIpo dGEnGryUDsxlynn3mrIWBnCeP+cmBwGXWrU88is9tWklpXw9brlsbl0UNPYa73u8NWg05p3 V4pIjBNDto6mzI9ioWpx0wQVlg3lcdI6eHvVcCL9koSw8RHFJzDi3hYmAY1GMoaxOABTOyO fgY65TOUIwLq1Ds9lDRLg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/nis1o8INuq8oNGilVYGrrzgBspI Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 20:06:13 -0000 On 2014-10-21 21:42, Peter Saint-Andre - &yet wrote: > On 10/21/14, 12:40 PM, Julian Reschke wrote: >> On 2014-10-21 18:22, Dale R. Worley wrote: >>> ... >>> Now, given this as background, it's not clear to me what you're >>> pushing for. It seems that the current situation is that RFC 3986 >>> applies to relative references against a urn: base URI, and there's no >>> reason for anyone to ever exploit that. And that the current >>> proposals don't seem to change either fact. I suspect that I'm >>> overlooking something. >>> ... >> >> What I'm pushing for is a spec that is sufficiently clear that the >> relative resolution algorithm defined by RFC 3986 indeed applies to URN >> URIs, even though the results it yields for most URN schemes might not >> be very useful. > > I propose the following text: > > Despite the fact that URNs are not hierarchical and are not > appropriate for use as a base URI (see Section 5.1 of [RFC3986]), the > relative resolution algorithm specified in Section 5.2 of [RFC3986] > still applies to the "urn" URI scheme; implementers need to be aware, > however, that running the algorithm against URNs can lead to results > that are unexpected or not useful. +1. Thanks! From nobody Tue Oct 21 13:29:54 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00841A6FC3; Tue, 21 Oct 2014 13:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEY0-TUC2ll6; Tue, 21 Oct 2014 13:29:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 290411A01BA; Tue, 21 Oct 2014 13:29:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021202948.24096.30024.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 13:29:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/YCUKWjCUF8oH4ciAXj1dv77l02s Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-08.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 20:29:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-08.txt Pages : 22 Date : 2014-10-21 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, typically with the intent that the URN will be a persistent, location-independent resource identifier or abstract designator. 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 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: http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-08 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 Tue Oct 21 16:19:41 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223941A8821 for ; Tue, 21 Oct 2014 16:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1hGwkFPcnyi for ; Tue, 21 Oct 2014 16:19:37 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56F91A87D9 for ; Tue, 21 Oct 2014 16:19:36 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xgii8-000AiJ-Qr; Tue, 21 Oct 2014 19:19:28 -0400 Date: Tue, 21 Oct 2014 19:19:23 -0400 From: John C Klensin To: Julian Reschke , Peter Saint-Andre - &yet , Sean Leonard , urn@ietf.org Message-ID: <9934B043D5AED1DA49F7A231@JcK-HP8200.jck.com> In-Reply-To: <5445F1C5.7000203@gmx.de> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> <5442E7CA.9050208@gmx.de> <5442EC72.9000605@seantek.com> <5443707F.6000609@gmx.de> <94AADBA3-4677-4B01-A4A1-AF045B1F8C26@seantek.com> <5445BC4D.4060700@andyet.net> <5445F1C5.7000203@gmx.de> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/u4agMj_WxBX7aCecnm-tnqbdTFU Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 23:19:39 -0000 --On Tuesday, October 21, 2014 07:40 +0200 Julian Reschke wrote: >> URN in a URI protocol slot that points to a resource >> (examples include the 'href' and 'src' attributes and the >> element in HTML, as well as the 'xml:base' >> attribute in XML [XML-BASE]). > > I'm ok with "doesn't make sense", but you're still avoiding > the answer to "what if it *is* used that way". Can we just > clarify that this doesn't overrule RFC 3986? Julian, This will be my last note on the subject until after I've absorbed Peter's new version and text (he is holding the pen for this one at least), but... (i) I think draft-ietf-urnbis-semantics-clarif already overrides 3986 in this area. If it is what the WG wants to do, I won't like it but don't have a problem with a document that associates relative reference processing with URNs, describes how to do it (possibly by reference to 3986 and I hope at least consistent with it) and mentions that it may lead to silly states sometimes. But my hope in Toronto and with the semantics-clarif document has been that we could put all arguments based on "we have to do that to conform to 3986" to rest unless the issue is strictly about syntax (and not processing or interpretation of that syntax). (ii) The answer to "what if it is used that way [anyway]" is that weird things will happen, things that both 3986 and, I hope, the URN specs will simply treat as invalid and that things that encounter them will need to deal with. I would have the same answer if someone asked "what if someone writes 'urn::bar' or "urn:/foo-". I don't know whether they are relative references or not (but see Dale's analysis), but I'm pretty confident that, absent some preprocessor that has rules for doing string processing that can make up an NID and maybe an NSS, they are going to trigger an error somewhere. The proposed text that Peter just posted meets the above criteria as far as I'm concerned and so I can live with it, but I'm still very unhappy about it. --On Tuesday, October 21, 2014 11:03 -0700 Sean Leonard wrote: >... > I don't see an operational difference between this and, say, > charset capabilities. If a server has text in some charset > (iso-2022-jp) and knows that the client doesn't support > iso-2022-jp, it can transform the text into a form that the > client can understand. The difference (and the reason I brought HTML and up) is that we have all sorts of mechanisms around the web for specifying charset alternatives and even a new "encoding" spec working its way through the WHATWG and W3C processes that, among other things, specifies what to do in cases where client and server capabilities (or what is specified in HTML and what the client knows how to display) don't match. On the other hand, if one is in an environment in which the originating client and the destination server cannot negotiate in real time (like email) the arrival of a message that uses a charset that the destination system doesn't understand (remembering that knowing enough about a charset to map it to another one is fairly far along the "understanding" curve) will result in some sort of error state (perhaps such as the recipient seeing complete nonsense of having her head explode). There may be less difference between that view and URNs than you expect, but it is a different view from the one you describe above in which, as I understand it, the server knows (or can find out) the capabilities at the client and munge things around until they match. >... > URNs are (or can be) effectively the "environment variable" > $(ENV_VAR) of URIs. The specific location can change based on > context but the name "ENV_VAR" remains the same. I think this gets us to the difference between our points of view. As I understand it, you are seeing (at least some) URNs as placeholders that get bound to other information at the latest possible point and then transformed or, if you will, resolved. I see them (or at least some of them) as very stable and very real identifiers that often won't be either resolved or turned into (or "resolved" into) any thing else. The range of things that people seem to want to do with URNs are such that we are probably both right. I note that pure indicators that are never resolved (and for which "resolved" is clearly not meaningful) fit with my perspective, but not well, and perhaps don't fit yours at all (see below). These combinations make text hard to write even without the complications of being expected to conform ot pieces of 3986 that, IMO, are better matched to locators that are not only expected to be resolved but are self-contained wrt resolution mechanisms. >> More generally, and noting 3986's comments about the loose >> binding between "scheme" and "protocol", the thing that makes >> the "urn" scheme different from most or all other URIs (and >> certainly from the URL ones) is that, for the others, the >> resolution mechanism is bound to the scheme name, often in >> conjunction with the authority. In the URN case, the scheme >> just tells you that everything else is a name, there is no >> authority, and the NID (which a hypothetical generic URI >> processor could not parse out or otherwise recognize as more >> than just part of a no-authority path) cannot be bound to a >> resolution mechanism because > > We are in agreement here. URNs are perhaps most useful when > they are not definitionally bound to any *particular* > resolution mechanism. But they can be resolved. The resolution > is context-dependent. Well, some of them can be resolved. Some can't unless one picks a really creative definition of "resolved" and, in any event, are not intended to be. But, if someone chose to make a relatively straightforward statement like "URNs represent a significantly higher level of abstraction than [most other] URI" I would agree (and be fairly uninterested in debating whether the words in brackets belong there or not). Modulo those words, I think the above indicates that you would agree too. john From nobody Tue Oct 21 23:10:34 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CFA1A8ABB for ; Tue, 21 Oct 2014 23:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G6x19r0AI_w for ; Tue, 21 Oct 2014 23:10:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE481A8A4F for ; Tue, 21 Oct 2014 23:10:27 -0700 (PDT) Received: from [192.168.2.160] ([84.187.40.143]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Mg42v-1XSCeY2fiP-00NUQ8; Wed, 22 Oct 2014 08:10:15 +0200 Message-ID: <54474A3F.5000708@gmx.de> Date: Wed, 22 Oct 2014 08:10:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John C Klensin , Peter Saint-Andre - &yet , Sean Leonard , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <54427288.2000802@seantek.com> <5442DFA0.5080405@gmx.de> <5442E1FA.6060409@seantek.com> <5442E7CA.9050208@gmx.de> <5442EC72.9000605@seantek.com> <5443707F.6000609@gmx.de> <94AADBA3-4677-4B01-A4A1-AF045B1F8C26@seantek.com> <5445BC4D.4060700@andyet.net> <5445F1C5.7000203@gmx.de> <9934B043D5AED1DA49F7A231@JcK-HP8200.jck.com> In-Reply-To: <9934B043D5AED1DA49F7A231@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:tKc3zJNB7ogcKb+Xlm2Cpqf1rgq+mjfPYkaaGbAPeZ3mMzk5XQY ehylCKklXTYa9bTMp1J6V3LktJOupKaZnuUe6K+DOorzkfVP5omzgfji7KfRQkbUl2dMgE6 /0Oe75auT1vNkV4fZmNggeifWqrbJK1YChBwez/w4PRaBJkQeaQkieaGBF3fe80XLrz25tK FdHiYQ4Y02NwZaY53MC2Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/3NFIOqKDrrrkE4-Hq5dR1_nbxyU Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 06:10:32 -0000 On 2014-10-22 01:19, John C Klensin wrote: > Julian, > > This will be my last note on the subject until after I've > absorbed Peter's new version and text (he is holding the pen for > this one at least), but... > > (i) I think draft-ietf-urnbis-semantics-clarif already overrides > 3986 in this area. If it is what the WG wants to do, I won't > like it but don't have a problem with a document that associates > relative reference processing with URNs, describes how to do it > (possibly by reference to 3986 and I hope at least consistent > with it) and mentions that it may lead to silly states > sometimes. But my hope in Toronto and with the > semantics-clarif document has been that we could put all > arguments based on "we have to do that to conform to 3986" to > rest unless the issue is strictly about syntax (and not > processing or interpretation of that syntax). Well, I continue to disagree on that point. > (ii) The answer to "what if it is used that way [anyway]" is > that weird things will happen, things that both 3986 and, I > hope, the URN specs will simply treat as invalid and that things > that encounter them will need to deal with. I would have the I don't think RFC 3986 treats anything as invalid here. > same answer if someone asked "what if someone writes 'urn::bar' > or "urn:/foo-". I don't know whether they are relative > references or not (but see Dale's analysis), but I'm pretty They are not. "If the URI-reference's prefix does not match the syntax of a scheme followed by its colon separator, then the URI-reference is a relative reference." -- > confident that, absent some preprocessor that has rules for > doing string processing that can make up an NID and maybe an > NSS, they are going to trigger an error somewhere. That is possible. > The proposed text that Peter just posted meets the above > criteria as far as I'm concerned and so I can live with it, but > I'm still very unhappy about it. Best regards, Julian From nobody Wed Oct 22 13:46:44 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A920E1A1AA5 for ; Wed, 22 Oct 2014 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSoMlv-okF68 for ; Wed, 22 Oct 2014 13:46:35 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343C41A1AA3 for ; Wed, 22 Oct 2014 13:46:35 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-08v.sys.comcast.net with comcast id 6LmL1p00657bBgG01LmaZZ; Wed, 22 Oct 2014 20:46:34 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-13v.sys.comcast.net with comcast id 6LmZ1p0011KKtkw01LmZk4; Wed, 22 Oct 2014 20:46:34 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9MKkWHN008509; Wed, 22 Oct 2014 16:46:32 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9MKkVgb008508; Wed, 22 Oct 2014 16:46:31 -0400 Date: Wed, 22 Oct 2014 16:46:31 -0400 Message-Id: <201410222046.s9MKkVgb008508@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Julian Reschke In-reply-to: <5446A8AE.9050601@gmx.de> (julian.reschke@gmx.de) References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414010794; bh=mkYPtTUpA2LPc++Wo2QzMeMjeL3JcN/O7g1FBAe0YOU=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=QHQAzOrbmOxiFt3RW6E3MNO46Ua5hEfUKTxWbgJB+J9NKpL1O0GEK8PLix2GvSipJ 63ijhIaIbuey38O37i/kSakpqgyQ98vPDGP77ujCLDUCenlsVMdZOw3sJ7WDcoBGHZ vM79quWz4dxwGNwQFMAcaYi0+lrBwwKgtoBP+eAabqukyKGVNimXxihpxX4teSEGoK giNrUOBPnzcChAob3r7j6sVjg9L1VvOf1aopmhN1dk+TVlshurodnF2DxYoPMuF4c4 lTWZt/+9T3Hn80XkCA1ouGM9AIundnbIDc/vWdl7LBoNooc3FL0v3DbZhXeSGdxR87 B779DiwOjbFPg== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MM3i0zjKXwE4hlSbIqJV7E8E_OI Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 20:46:38 -0000 > From: Julian Reschke > > On 2014-10-21 18:22, Dale R. Worley wrote: > > ... > > Now, given this as background, it's not clear to me what you're > > pushing for. It seems that the current situation is that RFC 3986 > > applies to relative references against a urn: base URI, and there's no > > reason for anyone to ever exploit that. And that the current > > proposals don't seem to change either fact. I suspect that I'm > > overlooking something. > > ... > > What I'm pushing for is a spec that is sufficiently clear that the > relative resolution algorithm defined by RFC 3986 indeed applies to URN > URIs, even though the results it yields for most URN schemes might not > be very useful. OK, I think I understand you there. But why do you care? It would seem to me better that we leave it in the state "Technically, RFC 3986 describes how you resolve a relative URI against a base urn: URI, but it's very unlikely to be useful in practice, and probably nobody has ever done it." If we do that, we reserve the ability to say (if it becomes necessary): [That] may not be backward-compatible with the specification, but it is backward-compatible with reality. -- Francois Audet Enhancing our commitment to a definition that seems completely useless in practice isn't going to gain us anything. *However*, if we introduce "/" in urn: URIs, then all of this changes: Then the 3986 algorithm can do useful things. Dale From nobody Wed Oct 22 22:25:58 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F41C1A88CD for ; Wed, 22 Oct 2014 22:25:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8JohgSgknvA for ; Wed, 22 Oct 2014 22:25:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0096.outbound.protection.outlook.com [65.55.169.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050491A88CC for ; Wed, 22 Oct 2014 22:25:54 -0700 (PDT) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB1021.namprd02.prod.outlook.com (25.160.219.143) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Thu, 23 Oct 2014 05:25:53 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Thu, 23 Oct 2014 05:25:52 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.00.1054.004; Thu, 23 Oct 2014 05:25:52 +0000 From: Larry Masinter To: Andrew Newton , Peter Saint-Andre - &yet Thread-Topic: [urn] syntax and registration: a proposal Thread-Index: AQHP6YXxq/DFKj0YXEWFhMCYbmDkYZw01xy7gACcpICAABVUgIAAAVKAgAASNgCAABFxgIAA/ZMAgABpPICAAfh1AIAAB5kAgAALCICAAAVrAIAALm6AgAAXS4CAAAfCgIAABJsAgAO2txA= Date: Thu, 23 Oct 2014 05:25:50 +0000 Message-ID: <1e463492a84b4b8e9102f58fca6ece63@DM2PR0201MB0960.namprd02.prod.outlook.com> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> <54456777.90202@gmx.de> <54456DF9.5000501@andyet.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2601:9:8380:992:e5e7:6165:5009:d204] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0960;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(92566001)(86362001)(99396003)(105586002)(97736003)(15395725005)(46102003)(19625735002)(74316001)(80022003)(31966008)(64706001)(77096002)(20776003)(95666004)(120916001)(99286002)(106116001)(76576001)(106356001)(76482002)(4396001)(76176999)(33646002)(15975445006)(85852003)(21056001)(19580395003)(2656002)(101416001)(87936001)(54356999)(40100003)(122556002)(50986999)(93886004)(85306004)(108616004)(15202345003)(3826002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0960; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB1021; X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/BPPzBjz9__uFsTXes_Hko3a-AeM Cc: "julian.reschke@gmx.de" , "urn@ietf.org" Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 05:25:57 -0000 SSdtIGhvcGluZyB3ZSBjYW4gY29udmVyZ2UgMzk4NiBhbmQgdXJsLnNwZWMud2hhdHdnLm9yZywg c2VlIA0KDQpodHRwOi8vaW50ZXJ0d2luZ2x5Lm5ldC9zdG9yaWVzLzIwMTQvMTAvMjAvVXJsLnho dG1sDQpodHRwOi8vaW50ZXJ0d2luZ2x5Lm5ldC9ibG9nLzIwMTQvMTAvMjEvcGVndXJsLWpzDQoN CkFsc28sIHBsZWFzZSBzZXBhcmF0ZSAiZnJhZ21lbnQiIGJlY2F1c2UgdG8gYWxsb3cgZGVsZWdh dGlvbiBvZg0KZnJhZ21lbnQgdG8gdGhlIE5JRCByZXF1aXJlcyBhIHN1YnN0YW50aWFsIGNoYW5n ZSB0byAzOTg2LA0KV2hpY2ggY3VycmVudGx5IGFscmVhZHkgZGVsZWdhdGVzIGZyYWdtZW50IGFu b3RoZXIgd2F5Lg0KDQpJIHRoaW5rIGRvaW5nIHNvIGlzIHZhbHVhYmxlLCBidXQgSSBkb24ndCBr bm93IGlmIHRoZXJlIGlzDQpjb25zZW5zdXMgdG8gbWFrZSB0aGUgbmVlZGVkIGNoYW5nZXMgdG8g Mzk4NiAodG8gbGV0DQp0aGUgc2NoZW1lLCBhbmQgJ3VybjonIGluIHBhcnRpY3VsYXIsIHRvIGRl bGVnYXRlIHRoZQ0KZnJhZ21lbnQgdG8gdGhlIHJlcHJlc2VudGF0aW9uIHJldHVybmVkIGJ5IEdF VC4NCg== From nobody Thu Oct 23 00:16:40 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFC31A8919 for ; Thu, 23 Oct 2014 00:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.155 X-Spam-Level: X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncL3ZMm-en5c for ; Thu, 23 Oct 2014 00:16:36 -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 CD2631A890E for ; Thu, 23 Oct 2014 00:16:35 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XhCdA-000In2-MR; Thu, 23 Oct 2014 03:16:20 -0400 Date: Thu, 23 Oct 2014 03:16:15 -0400 From: John C Klensin To: Larry Masinter , Andrew Newton , Peter Saint-Andre - &yet Message-ID: In-Reply-To: <1e463492a84b4b8e9102f58fca6ece63@DM2PR0201MB0960.namprd02.prod.outlook.com> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> <54456777.90202@gmx.de> <54456DF9.5000501@andyet.net> <1e463492a84b4b8e9102f58fca6ece63@DM2PR0201MB0960.namprd02.prod.o utlook.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1kUPCvfhvtn15Yy_SFNe9sDWcg4 Cc: julian.reschke@gmx.de, urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 07:16:38 -0000 --On Thursday, October 23, 2014 05:25 +0000 Larry Masinter wrote: > I'm hoping we can converge 3986 and url.spec.whatwg.org, see > > http://intertwingly.net/stories/2014/10/20/Url.xhtml > http://intertwingly.net/blog/2014/10/21/pegurl-js > > Also, please separate "fragment" because to allow delegation of > fragment to the NID requires a substantial change to 3986, > Which currently already delegates fragment another way. > > I think doing so is valuable, but I don't know if there is > consensus to make the needed changes to 3986 (to let > the scheme, and 'urn:' in particular, to delegate the > fragment to the representation returned by GET. Larry, Just to be sure, I think the above means that you believe that, despite the WG's decision to use 3986 syntax only and bypass the semantics (see Andy's recent postings), you believe that we cannot use fragments (or "f-components") without following the 3986 rules about how fragments are "delegated". Is that correct? If it is, do you believe similar delegation requirements for p-components and/or q-components? FWIW, I just grepped 3986 and variations on the term "delegate" appear to occur only in the following contexts: * A general statement about "Identifier" in Section 1.1 that indicates that identification is delegated to each scheme specification (without any language that I can immediately find that restricts the scheme specification from delegating it further). * Discussion about Authority in Section 3.2 (including Host in 3.2.2). Those discussions would appear to be irrelevant to URNs because they do not use an Authority component, at least as the syntax is defined in 3986. That is all. "Delegation" terminology is not used about fragments (or queries, etc.) at all. Again, FWIW, this sort of thing, including usage in discussions of it by one of it listed authors, is one of the reasons why some (perhaps many) of us find 3986 and its terminology and coverage confusing. john From nobody Thu Oct 23 07:45:42 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D601A9104 for ; Thu, 23 Oct 2014 07:45:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v0SXJg4lUlB for ; Thu, 23 Oct 2014 07:45:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0073.outbound.protection.outlook.com [207.46.100.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8972D1A9144 for ; Thu, 23 Oct 2014 07:45:26 -0700 (PDT) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0751.namprd02.prod.outlook.com (25.160.94.27) with Microsoft SMTP Server (TLS) id 15.1.6.9; Thu, 23 Oct 2014 14:45:25 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Thu, 23 Oct 2014 14:45:24 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.00.1054.004; Thu, 23 Oct 2014 14:45:24 +0000 From: Larry Masinter To: John C Klensin , Andrew Newton , "Peter Saint-Andre - &yet" Thread-Topic: [urn] syntax and registration: a proposal Thread-Index: AQHP6YXxq/DFKj0YXEWFhMCYbmDkYZw01xy7gACcpICAABVUgIAAAVKAgAASNgCAABFxgIAA/ZMAgABpPICAAfh1AIAAB5kAgAALCICAAAVrAIAALm6AgAAXS4CAAAfCgIAABJsAgAO2txCAACFAgIAAdwGw Date: Thu, 23 Oct 2014 14:45:22 +0000 Message-ID: <53a2c921c19a458bbfdb29eda8cf8d62@DM2PR0201MB0960.namprd02.prod.outlook.com> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> <54456777.90202@gmx.de> <54456DF9.5000501@andyet.net> <1e463492a84b4b8e9102f58fca6ece63@DM2PR0201MB0960.namprd02.prod.o utlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2601:9:8380:992:20a7:3de4:2f46:3d42] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0960;UriScan:; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(51704005)(189002)(92566001)(4396001)(86362001)(31966008)(21056001)(20776003)(64706001)(15202345003)(97736003)(19580395003)(40100003)(85852003)(101416001)(87936001)(122556002)(15975445006)(2656002)(107046002)(105586002)(106116001)(54356999)(76176999)(95666004)(99286002)(106356001)(77096002)(46102003)(50986999)(80022003)(74316001)(108616004)(93886004)(85306004)(99396003)(120916001)(76576001)(33646002)(76482002)(24736002)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0960; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0751; X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bpQWRORZs_0DFs1uL5V5rX63-9I Cc: "julian.reschke@gmx.de" , "urn@ietf.org" Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 14:45:34 -0000 > Just to be sure, I think the above means that you believe that, despite t= he WG's > decision to use 3986 syntax only and bypass the semantics (see Andy's rec= ent > postings), you believe that we cannot use fragments (or "f-components") > without following the > 3986 rules about how fragments are "delegated". > Is that correct? If it is, do you believe similar delegation > requirements for p-components and/or q-components? My belief is that currently the scheme's definition has control over the syntax (within 3986 limitations) and complete control over the interpretation of / and ? delimited parts ('p-components' and 'q-components') but that, currently, the scheme's definition cannot define the syntax or interpretation of any # delimited part (the f-component). =20 > FWIW, I just grepped 3986 and variations on the term "delegate" > appear to occur only in the following contexts: >=20 > * A general statement about "Identifier" in Section 1.1 > that indicates that identification is delegated to each > scheme specification (without any language that I can > immediately find that restricts the scheme specification > from delegating it further). >=20 > * Discussion about Authority in Section 3.2 (including > Host in 3.2.2). Those discussions would appear to be > irrelevant to URNs because they do not use an Authority > component, at least as the syntax is defined in 3986. >=20 > That is all. "Delegation" terminology is not used about > fragments (or queries, etc.) at all. >=20 > Again, FWIW, this sort of thing, including usage in discussions of it by = one of it > listed authors, is one of the reasons why some (perhaps many) of us find = 3986 > and its terminology and coverage confusing. I apologize profusely for our failure of clarity for those trying to do a close reading of the exact words of the text. I am not among those who believe 3986 is perfect and should be carved into stone tablets or engraved on nickel disks.=20 In this case, section 3.5 of RFC 3986 uses "defined by X" and "dependent on X" and not "delegated to X", an oversight which I admit might be confusing to some. Humbly, Larry -- http://larry.masinter.net From nobody Thu Oct 23 08:46:18 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08881ACC88 for ; Thu, 23 Oct 2014 08:46:16 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...870uUmBw@mail.gmail.com>\n \n <1e463492a84b[...] X-Spam-Flag: NO X-Spam-Score: -0.155 X-Spam-Level: X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGtmg9aI8Xtv for ; Thu, 23 Oct 2014 08:46:14 -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 66B251ACC91 for ; Thu, 23 Oct 2014 08:46:14 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XhKaR-000JVh-LH; Thu, 23 Oct 2014 11:46:03 -0400 Date: Thu, 23 Oct 2014 11:45:58 -0400 From: John C Klensin To: Larry Masinter , Andrew Newton , Peter Saint-Andre - &yet Message-ID: <00A73818E083D9D9A9956C49@JcK-HP8200.jck.com> In-Reply-To: <53a2c921c19a458bbfdb29eda8cf8d62@DM2PR0201MB0960.namprd02.prod.outlook.com> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <3F81AFE484A9F81881984FC3@JcK-HP8200.jck.com> <54456777.90202@gmx.de> <54456DF9.5000501@andyet.net> <1e463492a84b4b8e9102f58fca6ece63@DM2PR0201MB0960.namprd02.prod.o utlook.com> <53a2c921c19a458bbfdb29eda8cf8d62@DM2PR0201MB0960.namprd02.prod.outlook.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/KTNEL7FsFA6L94nhsSPc4OMPQdg Cc: julian.reschke@gmx.de, urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 15:46:16 -0000 (top post) Larry, Thanks for the clarification. While I believe that the 3986 properties of fragments are semantics and not part of the syntax and that distinction was part of the motivation for Peter's introducing "f-component", just as I believe that questions of the perceived 3986 requirement for evaluating relative references are semantics and not syntax, I think I'm now clear on what you are asking for and why. That is a big help. best, john --On Thursday, October 23, 2014 14:45 +0000 Larry Masinter wrote: >> Just to be sure, I think the above means that you believe >> that, despite the WG's decision to use 3986 syntax only and >> bypass the semantics (see Andy's recent postings), you >> believe that we cannot use fragments (or "f-components") >> without following the >> 3986 rules about how fragments are "delegated". > >> Is that correct? If it is, do you believe similar delegation >> requirements for p-components and/or q-components? > > My belief is that currently the scheme's definition has control > over the syntax (within 3986 limitations) and complete control > over the interpretation of / and ? delimited parts > ('p-components' and 'q-components') but that, currently, > the scheme's definition cannot define the syntax or > interpretation of any # delimited part (the f-component). > > > >> FWIW, I just grepped 3986 and variations on the term >> "delegate" appear to occur only in the following contexts: >> >> * A general statement about "Identifier" in Section 1.1 >> that indicates that identification is delegated to each >> scheme specification (without any language that I can >> immediately find that restricts the scheme specification >> from delegating it further). >> >> * Discussion about Authority in Section 3.2 (including >> Host in 3.2.2). Those discussions would appear to be >> irrelevant to URNs because they do not use an Authority >> component, at least as the syntax is defined in 3986. >> >> That is all. "Delegation" terminology is not used about >> fragments (or queries, etc.) at all. >> >> Again, FWIW, this sort of thing, including usage in >> discussions of it by one of it listed authors, is one of the >> reasons why some (perhaps many) of us find 3986 and its >> terminology and coverage confusing. > > I apologize profusely for our failure of clarity for those > trying to do a close reading of the exact words of the text. I > am not among those who believe 3986 is perfect and should be > carved into stone tablets or engraved on nickel disks. > > In this case, section 3.5 of RFC 3986 uses "defined by X" and > "dependent on X" and not "delegated to X", an oversight > which I admit might be confusing to some. > > Humbly, > > Larry > -- > http://larry.masinter.net > > > From nobody Mon Oct 27 03:58:06 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933FC1A6F8D for ; Mon, 27 Oct 2014 03:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9ESD-6ZZuzV for ; Mon, 27 Oct 2014 03:58:00 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE9C1A899A for ; Mon, 27 Oct 2014 03:57:58 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s9RAw1DD024487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 27 Oct 2014 12:58:02 +0200 Message-ID: <544E2533.7070100@helsinki.fi> Date: Mon, 27 Oct 2014 12:57:55 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: urn@ietf.org References: <5446A902.4030904@andyet.net> In-Reply-To: <5446A902.4030904@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/SoSvw0ZZyNtLgMuWIZRw_L8L3Vk Subject: Re: [urn] next steps X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:58:04 -0000 Hello Peter, The latest I-D is a significant step forward. Combining 2141bis and 3046bis is a good decision, since these documents complement one another well. I approve the changes made to the I-D, but I have one question / suggestion. Semantics of p-, q- and f-components are not specified in the 2141bis, which is OK. But when you then mention additional specifications which might establish these matters, do you mean specifications by IETF or by some other (standardization) organizations which have registered or will register URN namespaces for their identifier systems, or both? As far as I am concerned, the most convenient model would be one where 3rd parties may also provide guidelines on how these components may / should be used for their (standard) identifiers. For instance, ISO TC 46/SC 9 could produce such guidelines for ISO bibliographic identifier systems. This would be easy for p (never allowed) and f components (allowed in some ISO identifiers, forbidden or not applicable in some others), but q component is more complicated, if ISO makes a decision to use it (to start with) for specification of resolution related services and service parameters. Such document could / should be used in other namespaces (like urn:nbn) and perhaps by other persistent identifiers as well, in order to improve interoperability between PID systems. Juha On 21.10.2014 21:42, Peter Saint-Andre - &yet wrote: > I have a revised I-D almost ready for consideration by the WG, which I > plan to submit tonight. > > Two things to note: > > 1. Because of his significant contributions to the concepts and text, > I have added John Klensin as co-author. > > 2. To reduce confusion and cross-references (and with approval of the > WG chairs), I have combined 2141bis and 3406bis into a single document > that covers both URN syntax and URN namespaces. > > Naturally, there are still some open issues being discussed on the > list. I cannot promise that the revised I-D closes them all, but I > think it brings us much closer to having a specification we can live > with. > > Peter > -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Mon Oct 27 09:15:15 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A381A00BB for ; Mon, 27 Oct 2014 09:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTAYGvQfNa4I for ; Mon, 27 Oct 2014 09:15:03 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9313C1A0092 for ; Mon, 27 Oct 2014 09:14:54 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XimwU-000851-3C; Mon, 27 Oct 2014 12:14:50 -0400 Date: Mon, 27 Oct 2014 12:14:48 -0400 From: John C Klensin To: Juha Hakala , urn@ietf.org Message-ID: <8870D448E2AF14A2ACD4C83E@JCK-EEE10> In-Reply-To: <544E2533.7070100@helsinki.fi> References: <5446A902.4030904@andyet.net> <544E2533.7070100@helsinki.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/v-FGMYBlKDSjT8CZE13wNx8kp3Y Subject: Re: [urn] next steps X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:15:06 -0000 --On Monday, 27 October, 2014 12:57 +0200 Juha Hakala wrote: >... > Semantics of p-, q- and f-components are not specified in the > 2141bis, which is OK. But when you then mention additional > specifications which might establish these matters, do you > mean specifications by IETF or by some other (standardization) > organizations which have registered or will register URN > namespaces for their identifier systems, or both? Personal opinion, since I haven't discussed this with Peter or many others yet: "yes. both". This is very much something the WG needs to discuss, but my hope is that recognized SDOs should basically be able to do what they like, as long as (1) It conforms to the basic syntax rules (2) It is described clearly and in a way and place that provides stability. ((3) It is registered to provide contacts and pointers to document in a coordinated way and to avoid conflicting names. > As far as I am concerned, the most convenient model would be > one where 3rd parties may also provide guidelines on how these > components may / should be used for their (standard) > identifiers. For instance, ISO TC 46/SC 9 could produce such > guidelines for ISO bibliographic identifier systems. Yes, exactly. > This would be easy for p (never allowed) and f components > (allowed in some ISO identifiers, forbidden or not applicable > in some others), but q component is more complicated, if ISO > makes a decision to use it (to start with) for specification > of resolution related services and service parameters. Such > document could / should be used in other namespaces (like > urn:nbn) and perhaps by other persistent identifiers as well, > in order to improve interoperability between PID systems. Assuming you are describing a set of rules that TC 46 / SC 9 might adopt for URNs based on its already-standardized identifier types and make available for reference and voluntary adoption by others, that seems completely reasonable to me. best, john From nobody Wed Oct 29 13:07:03 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147D41A88AF for ; Wed, 29 Oct 2014 13:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FRT_ADOBE2=2.455] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QETz1wxVF2FV for ; Wed, 29 Oct 2014 13:06:57 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D2E1A8982 for ; Wed, 29 Oct 2014 13:06:51 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-11v.sys.comcast.net with comcast id 985W1p0045E3ZMc0186qBm; Wed, 29 Oct 2014 20:06:50 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-18v.sys.comcast.net with comcast id 986l1p00G1KKtkw0186pvR; Wed, 29 Oct 2014 20:06:50 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9TK6jBp008538; Wed, 29 Oct 2014 16:06:45 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9TK6iCo008535; Wed, 29 Oct 2014 16:06:44 -0400 Date: Wed, 29 Oct 2014 16:06:44 -0400 Message-Id: <201410292006.s9TK6iCo008535@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Larry Masinter In-reply-to: (masinter@adobe.com) References: <201409060307.s86371n6031692@hobgoblin.ariadne.com> <8CCBED81E6F16B40F76AD624@JcK-HP8200.jck.com> <542BEDFE.8050501@helsinki.fi> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414613210; bh=DL8DYBnzHxY4QhhkuLtffJTM5qZATsPqdF2v2qN/TTI=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=DdyGK7J4NET1UBTrtngFD6EprfzLzxRLt7AJZNjOsSmiBiMT87q0WYASpka1/+kU4 2XLM/P8hpEEKbls7vOruJNSXDKxjpexTR6ouNmuuil9qKvxNFF0jn48wm4JqX0rqNm d9F2pTVmPmhnqfjul566qOA6l721bH/8rI6Sr58rxkRlIFE3qdiUwTdXaEoqhTGfcD 4e5TN1vJoBHIfhxNRC9FACNTwUc+EkvwpezoUuPlAmILvr7G6acOb54IGqamx3KdJD xkS/vY+Vqaqc3t6KTNruYDJ+wOnv/kySbFEetaIuk3sNlMxAkr9GlBbr6vw8APTbST zSTKtx6vuzpDQ== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/7dMQUlp-19BnnnitDmxk9xZlHsY Cc: urn@ietf.org Subject: Re: [urn] Names and derived identifiers X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:06:58 -0000 > From: Larry Masinter > Date: Thu, 2 Oct 2014 01:33:49 +0000 > > There are two ways of addressing the technical specification of > fragment identifiers for URNs, if that is actually desirable and > implementations agree to build and test it. > > The first and simplest is to [...] > > The second and more subtle is to make up a virtual MIME type, say > "application/urn-retrieval-result" and define fragment identifiers > for that MIME type. Make application/urn-retrieval-result contain > 'landing page' information. Then define 'retrieval' for urn: URIs > as accessing using whatever method is appropriate for the URN > namespace, but which returns a virtual > application/urn-retrieval-result. > > That way you get 'official' 3986 interpretations. Fragment > identifiers are defined by the MIME type, but we add one MIME type > to do the work of lifting the fragment. That concept allows a lot of interesting possibilities. The resolution process which is defined to "retrieve" the document with the special MIME type can be defined on a per-NID basis (or even finer). The process doesn't have to fetch a block of octets which previously exists in any server, the process can assemble the document by any algorithm it chooses, using whatever data sources it chooses. And there is no pre-commitment regarding which MIME type(s) the resolution process will generate for any particular URN -- the MIME type(s) of the document(s) are an output of the resolution algorithm. So different NIDs can use different types, and indeed, any one NID can use several different types, with different URNs resolving to sets of documents with different sets of types. (I am assuming here that we follow the rule that I saw in some W3C document: If a URI can resolve into multiple manifestations of the resource, each fragment name that is defined in any manifestation must be defined in all manifestations with meanings that are "the same" from the user's point of view.) This concept allows a remarkable amount of flexibility while staying within the conceptual structure of the existing RFCs. Dale From nobody Thu Oct 30 13:12:35 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8111C1A6F2E for ; Thu, 30 Oct 2014 13:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmqlm-gS8c5j for ; Thu, 30 Oct 2014 13:12:29 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215921A6F30 for ; Thu, 30 Oct 2014 13:12:29 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8DC4B20C98 for ; Thu, 30 Oct 2014 16:12:28 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 30 Oct 2014 16:12:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=O43pASAR216UpTNB+qRbfW pY77g=; b=I07lloZJF9p1eyfqHyap6r02RuIpRMNaojD1XlMIdJrEQQ9BVfSYu4 3+eZa09TIl24INJY6Ztmbz89QujpXNvBDxizCAskRy5BcF0epTN/3IVUfvG26fPm 8wd0PuWR5+IlFhqUhweTr5yJfUMSnfwc8NxuZ+05OzX0le3+MNzRg= X-Sasl-enc: V+0lOIvbddLNeeQsSzIaGuq4m0SpoRp43YM82axC3quH 1414699948 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 3684CC00013; Thu, 30 Oct 2014 16:12:28 -0400 (EDT) Message-ID: <54529BA1.2040801@network-heretics.com> Date: Thu, 30 Oct 2014 16:12:17 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> In-Reply-To: <54403493.5080808@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/4VHVPLAeCmAPadtvPnzCDak5Yys Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 20:12:31 -0000 On 10/16/2014 05:11 PM, Peter Saint-Andre - &yet wrote: > I don't think we will quickly come to agreement on the semantics of > paths, queries, and fragments in the context of the "urn:" scheme. (In > fact, I suggest that we call them "p-components", "q-components", and > "f-components" here so that we don't get bogged down in how their > meaning in URNs might be different from their meaning in URIs.) > > I remain hopeful that we might someday come to such agreement, but as > far as I can see it's not productive for us to wait for such agreement > before making progress on the two primary tasks on the charter of this > WG: updating the URN syntax definitions from RFC 2141 and updating the > URN namespace identifier registration procedures from RFC 3406. > > I think we can complete those tasks in the relatively near future if > we decide to do one thing: let go of semantics. That is, I suggest > that we update the URN syntax to allow p-components, q-components, and > f-components, but leave the semantics of those elements up to > specifications that define specific NIDs. I am emphatically opposed to this proposal. I find it completely unacceptable to allow different NIDs to define different semantics for these things. That would essentially force software to treat every NID differently, to implement special code for each NID, and likely result in very spotty implementation. In other words, it would circumvent the entire point of URNs. Keith From nobody Thu Oct 30 13:19:46 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE181A6F8E for ; Thu, 30 Oct 2014 13:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMUH3ApOpGXX for ; Thu, 30 Oct 2014 13:19:43 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8652D1A6FA3 for ; Thu, 30 Oct 2014 13:19:43 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0389420970 for ; Thu, 30 Oct 2014 16:19:42 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 30 Oct 2014 16:19:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=oNqi9LaaFqLm2bKJoXlfAv 3CSHo=; b=g2d7pBCsFGJpG7NnkKommhxPm4rxYKM/noautvTeJ24wZISX237x7E e9ISIYqrIKYPcPKJ+YCmKWWKo8gZJVNJluFFz4r/yYuxScBipiK9fctH3tu8EpX+ OXnjofxLmIUbvrBn991VEWBDjZeCGJYehfB1CEu12CEdlMao0fL7w= X-Sasl-enc: bJqWA30MlZAhXGsd4/czYFwbsWAu5URktJXkMcRc5b8A 1414700382 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id A25C56800F5; Thu, 30 Oct 2014 16:19:42 -0400 (EDT) Message-ID: <54529D53.2020003@network-heretics.com> Date: Thu, 30 Oct 2014 16:19:31 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> In-Reply-To: <5446A8AE.9050601@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/oPo3nK-e6ZRRzrn0vV-_8k0DN9c Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 20:19:45 -0000 On 10/21/2014 02:40 PM, Julian Reschke wrote: > What I'm pushing for is a spec that is sufficiently clear that the > relative resolution algorithm defined by RFC 3986 indeed applies to > URN URIs, even though the results it yields for most URN schemes might > not be very useful. RFC 3986 is fundamentally broken in numerous ways, especially (but not exclusively) as related to URNs. The URN WG can't fix that, but it should point it out and leave the actual fixing to others. The alternative - to try to reconcile reality to RFC 3986 - is a fool's errand. Keith From nobody Thu Oct 30 13:37:40 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3679E1A86DD for ; Thu, 30 Oct 2014 13:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXfhPYdvnt1j for ; Thu, 30 Oct 2014 13:37:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4BD1A6FA3 for ; Thu, 30 Oct 2014 13:36:59 -0700 (PDT) Received: from [192.168.2.160] ([93.217.108.125]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LwqwS-1Y83zA3ZV2-016MLX; Thu, 30 Oct 2014 21:36:54 +0100 Message-ID: <5452A155.2000302@gmx.de> Date: Thu, 30 Oct 2014 21:36:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> In-Reply-To: <54529D53.2020003@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:eQ3bSVk5JdICsnq+qult0Ucx24UfVtQmYQm6tY8qGDSuGxOaNAN jhpy11ZOzrOkdXHpYM/ymZ5xa1z+Chyxn1raIj6vr71DdeodaDp8ayK+6p+v+F+VquRkyED DyboS2zDAfh4XQR2teLpSHHd/Lmr0KycnBnJEpcvLiJ0bLqdJ2+kCVmorjjWXMgjXQRUcDo Mt6pQiZUKKqRMTIC4fE8A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1EfdFoBl7-Ul2nijPC4PPFewK7I Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 20:37:35 -0000 On 2014-10-30 21:19, Keith Moore wrote: > On 10/21/2014 02:40 PM, Julian Reschke wrote: >> What I'm pushing for is a spec that is sufficiently clear that the >> relative resolution algorithm defined by RFC 3986 indeed applies to >> URN URIs, even though the results it yields for most URN schemes might >> not be very useful. > > RFC 3986 is fundamentally broken in numerous ways, especially (but not > exclusively) as related to URNs. The URN WG can't fix that, but it > should point it out and leave the actual fixing to others. The > alternative - to try to reconcile reality to RFC 3986 - is a fool's errand. > > Keith It would be helpful if there was more than hand-waving; a *concrete* list of things you think are broken, please. Best regards, Julian From nobody Thu Oct 30 16:25:33 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E101A8902 for ; Thu, 30 Oct 2014 16:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdB5YKb1Zy5A for ; Thu, 30 Oct 2014 16:25:27 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D564E1A88E0 for ; Thu, 30 Oct 2014 16:25:27 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xjz5o-0000sC-7s; Thu, 30 Oct 2014 19:25:24 -0400 Date: Thu, 30 Oct 2014 19:25:22 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: In-Reply-To: <54529D53.2020003@network-heretics.com> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/SDOzvzDBR7Zaa0PcqD6ijFgS8Ro Subject: [urn] 3986 conformance (was: Re: syntax and registration: a proposal) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:25:31 -0000 --On Thursday, 30 October, 2014 16:19 -0400 Keith Moore wrote: > RFC 3986 is fundamentally broken in numerous ways, especially > (but not exclusively) as related to URNs. The URN WG can't > fix that, but it should point it out and leave the actual > fixing to others. The alternative - to try to reconcile > reality to RFC 3986 - is a fool's errand. I would not have said "reconcile" but rather to force reality into RFC3986's mold (or straightjacket), but otherwise I agree. "Point it out, bypass it for URNs, and move on" was exactly what the "URNs are not URIs" approach tried to take. The WG didn't like it, so I thought (and still think) that "syntax only" went far enough in that direction and that it was what was agreed to in Toronto. Given that, I continue to be confused by positions that seem to start from "3986 imposed this non-syntax requirement, so URNbis must conform". john From nobody Thu Oct 30 16:37:25 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6501A89FC for ; Thu, 30 Oct 2014 16:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aixXo-y8Mlqx for ; Thu, 30 Oct 2014 16:37: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 69BBD1A89F5 for ; Thu, 30 Oct 2014 16:37:22 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XjzHI-00012j-9r; Thu, 30 Oct 2014 19:37:16 -0400 Date: Thu, 30 Oct 2014 19:37:13 -0400 From: John C Klensin To: Julian Reschke , Keith Moore , urn@ietf.org Message-ID: <78B463281BB2918DD1D3130F@[10.10.9.223]> In-Reply-To: <5452A155.2000302@gmx.de> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> <5452A155.2000302@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/X1p30FNzSVfQrBxv0xVTr2cFnco Subject: [urn] 3986 conformance (was: Re: syntax and registration: a proposal) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:37:24 -0000 --On Thursday, 30 October, 2014 21:36 +0100 Julian Reschke wrote: > It would be helpful if there was more than hand-waving; a > *concrete* list of things you think are broken, please. Julian, I've supplied several entries for that list in separate notes. I think others have too. My impression is that Larry (as a co-author) has even agreed to a few of the issues I and others have raised. From my perspective, the two "separation" drafts were both attempts (agreed to by the WG) to permit URNs to move forward without putting "revise 3986" or even "reach agreement on the details of what is wrong with 3986" into the URN critical path. Once we get URNs under control, I'll be happy to find time to go back through my notes and the archives and produce a draft of a consolidated list. Until then, while I assume it is not what you intend, this whole discussion subtopic increasingly has the appearance of a delaying tactic to keep the WG from accomplishing anything; a "why you can't do that" discussion rather than part of a constructive "what do URNs need and how is that accomplished" one. And, until Andy explicitly suggests otherwise, I'm finished with trying to have it. john From nobody Thu Oct 30 16:51:48 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113EA1A8A12 for ; Thu, 30 Oct 2014 16:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwqJUzLuB_Jl for ; Thu, 30 Oct 2014 16:51: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 4C4CB1A8A0B for ; Thu, 30 Oct 2014 16:51:45 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XjzVH-00014K-Va; Thu, 30 Oct 2014 19:51:44 -0400 Date: Thu, 30 Oct 2014 19:51:41 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: In-Reply-To: <54529BA1.2040801@network-heretics.com> References: <54403493.5080808@andyet.net> <54529BA1.2040801@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/pgxpW933BeXGHV1FKO-Fm6ozp-Y Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:51:47 -0000 --On Thursday, 30 October, 2014 16:12 -0400 Keith Moore wrote: > I am emphatically opposed to this proposal. I find it > completely unacceptable to allow different NIDs to define > different semantics for these things. That would essentially > force software to treat every NID differently, to implement > special code for each NID, and likely result in very spotty > implementation. In other words, it would circumvent the > entire point of URNs. Predictions of spotty implementation aside (and, IMO, it is too late to prevent that) we are there already. For example, we can't talk about resolution because some URNs don't resolve. We can't talk about fragments or queries because we either find ourselves back in discussions about what 3986 requires or hopelessly bogged down about details or what is and is not generic or, alternately, per-NID. We could just say "no syntax beyond 2141" but that takes us straight to loss of all IETF control because some important communities are convinced that they need some of that added syntax, are perfectly capable of adopting their own (if necessary conflicting) standards, and ignoring all IETF philosophy discussions, including those about 3986, while doing so. I've said this before but it seems to me that we have three choices: (1) Adopt a proposal very much like Peter's, ignoring "3986 won't allow that" discussion that move beyond the ability of a basic URI parser to parse, and let others flesh out details on a per-NID basis. That would require several of us to accept a conclusion that is, at best, "least bad". (2) Conclude that we can't reach consensus on anything and shut the WG down. (3) Continue going around these circles forever. The second and third have the same outcome --others adopting their own standards or calling things URNs, probably without even a consolidated registration and description model, and even more probably with complete disregard of what you, me, or the IETF think. And those decisions would likely be made on a per-NID, or per set of NIDs, basis in forums in which neither you nor Julian (as representatives of what seem to be opposite positions today) are likely to have a voice. I'd rather grit my teeth, wish we could have done better, and go with (1) or a close variation on it. YMMD but, again, be careful that you aren't ultimately forcing a position that y9u'd like even less. john From nobody Thu Oct 30 16:55:58 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AA81A8952 for ; Thu, 30 Oct 2014 16:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUG4wAXWer8C for ; Thu, 30 Oct 2014 16:55:54 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 198C11A8823 for ; Thu, 30 Oct 2014 16:55:54 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 28E3D32E4A1; Fri, 31 Oct 2014 08:55:08 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 7986_215d_3d66febe_2ccc_4fdd_a374_e6e7192932f2; Fri, 31 Oct 2014 08:55:07 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id AB4BFBF8FD; Fri, 31 Oct 2014 08:55:07 +0900 (JST) Message-ID: <5452CFDA.9000203@it.aoyama.ac.jp> Date: Fri, 31 Oct 2014 08:55:06 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> In-Reply-To: <54529D53.2020003@network-heretics.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tGY2oCBBzVpe9YvHxnM4UhwrG9k Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:55:56 -0000 > On 10/21/2014 02:40 PM, Julian Reschke wrote: >> What I'm pushing for is a spec that is sufficiently clear that the >> relative resolution algorithm defined by RFC 3986 indeed applies to >> URN URIs, even though the results it yields for most URN schemes might >> not be very useful. The relative resolution algorithm applies to any and all schemes (including URNs) where it is applied. I'm not aware of any URI scheme spec that mentions this explicitly. I'm not sure that needs to be called out in the URN spec, or in other scheme specs or registration templates. It would look very repetitive. If you think it should, it would make sense to add this to the requirements. You should make a comment to that effect on https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04 on the Apps WG list. In practical terms, I think that if an actual document that gets returned when somehow resolving an URN contains relative references, the producers of that document will quickly learn to add a element (or whatever the equivalent in formats other than HTML). On 2014/10/31 05:19, Keith Moore wrote: > RFC 3986 is fundamentally broken in numerous ways, especially (but not > exclusively) as related to URNs. The URN WG can't fix that, but it > should point it out and leave the actual fixing to others. The > alternative - to try to reconcile reality to RFC 3986 - is a fool's errand. Can you please be specific? Otherwise, we end up with the situation that everybody thinks it's broken, but in different ways. Which in other words may mean that it's just a reflection of rough consensus. Regards, Martin. From nobody Thu Oct 30 16:59:09 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE091A88C5 for ; Thu, 30 Oct 2014 16:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMJnAzvZ6WlJ for ; Thu, 30 Oct 2014 16:58:57 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628B11A8823 for ; Thu, 30 Oct 2014 16:58:57 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C1B9A208BD for ; Thu, 30 Oct 2014 19:58:56 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 30 Oct 2014 19:58:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=nQ5e63GE0n5paJ3nBDp5Pl Td1Yo=; b=aRBz17f53Kp72p+qz5I00NpKG9tMaLZDINDZCgHlFAdsrTuRz9YMqu prxnyg5cnhrZb8IPjinDaByUZzKM8ItKs4bRDRm1DNaUjvgF1RlYwYTxWzILn4Hg A5ut6hjWktctyduPmjicCmKnppULboU2ku8Qs89KYsUDx689fo91g= X-Sasl-enc: +ONas+e1FojJnc+xn6wgZAd4iRC+912u8bojCLMlHqjm 1414713536 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 554BA68016C; Thu, 30 Oct 2014 19:58:56 -0400 (EDT) Message-ID: <5452D0B5.8060008@network-heretics.com> Date: Thu, 30 Oct 2014 19:58:45 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> In-Reply-To: <5452CFDA.9000203@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/T0AXzlId9gLRqTYyOCMWjeauQ3s Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:59:00 -0000 On 10/30/2014 07:55 PM, "Martin J. Dürst" wrote: >>> What I'm pushing for is a spec that is sufficiently clear that the >>> relative resolution algorithm defined by RFC 3986 indeed applies to >>> URN URIs, even though the results it yields for most URN schemes might >>> not be very useful. > > The relative resolution algorithm applies to any and all schemes > (including URNs) where it is applied. Sorry, that's just insane. It makes no technical sense whatsoever. 3986 is simply incorrect, and needs to be obsoleted and move to Historic. Keith From nobody Thu Oct 30 17:03:07 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5AD1A8823 for ; Thu, 30 Oct 2014 17:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBBm11N4aCo3 for ; Thu, 30 Oct 2014 17:03:04 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6831A8928 for ; Thu, 30 Oct 2014 17:03:04 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A0CBF206FE for ; Thu, 30 Oct 2014 20:03:03 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 30 Oct 2014 20:03:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=kP2tNgvUA0BZhEQIQZjl9s ZyPe4=; b=RepOIC8k6W3j9HEXJlyHIJTLijmMGPEp9ny6LD6fFfI5AacVoW4Tmx YOpL3YPI+mpoTiz5W6AAXrE4pwNwGeHftFW5v+IvJp1+oVdPymJAfoQmpWocnk4X w1hMoJBIjZmx7t75Sbn/NYH0gGxfPlP8R3ErqCwfbLs5O7CKxTO9Q= X-Sasl-enc: npL6jKQy/4nomezRAJgG5va9vR4XN1Urm3ctPkvBRjuB 1414713783 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 36A58C00013; Thu, 30 Oct 2014 20:03:03 -0400 (EDT) Message-ID: <5452D1AC.4020905@network-heretics.com> Date: Thu, 30 Oct 2014 20:02:52 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <54403493.5080808@andyet.net> <54529BA1.2040801@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UXAAJvKn8lKd6IvzysDYbI2RKQs Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 00:03:06 -0000 On 10/30/2014 07:51 PM, John C Klensin wrote: > I've said this before but it seems to me that we have three > choices: > > (1) Adopt a proposal very much like Peter's, ignoring "3986 > won't allow that" discussion that move beyond the ability of a > basic URI parser to parse, and let others flesh out details on a > per-NID basis. That would require several of us to accept a > conclusion that is, at best, "least bad". > > (2) Conclude that we can't reach consensus on anything and shut > the WG down. > > (3) Continue going around these circles forever. I don't accept that these are the only alternatives, but either (2) or maybe even (3) :-) is better than (1). A bad recommendation is worse than none at all. There's nothing inherently wrong with URNs as they are now; the only problems are that (a) 3986 is misleading in the extreme and (b) URNs as they are now don't do everything people want them to do. I actually think that the WG's biggest problem is insufficient participation, so trying to have the discussion in a way that brings more people to the table seems to me like what needs to happen. If that means ceding change control of URNs to another party, so be it, though I'd like for IETF to still be able to provide some technical guidance as to what makes sense on a protocol level. Keith From nobody Thu Oct 30 17:10:43 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617CF1A897B for ; Thu, 30 Oct 2014 17:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG3iueg5zy6q for ; Thu, 30 Oct 2014 17:10:40 -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 C9CAF1A896B for ; Thu, 30 Oct 2014 17:10:40 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xjznb-00016S-3Y; Thu, 30 Oct 2014 20:10:39 -0400 Date: Thu, 30 Oct 2014 20:10:37 -0400 From: John C Klensin To: Andrew Newton Message-ID: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/vzU2_4vrcL80NoJzSPVuqwXG8R8 Cc: urn@ietf.org Subject: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 00:10:42 -0000 Andy, This is a formal and public request to you as Chair. Would you please rule discussions of what, specifically, is wrong with 3986 or needs to be fixed in it, out of scope and indicate that you will revoke posting rights for anyone who persists in that discussion. The obvious exception would be something that strictly and narrowly affects the relationship between URN syntax and generic URI syntax. The result of those continued discussions is that people are being driven off the mailing list and out of the WG who really need URNs and have positions based on real requirements and experience. Not only is that bad in itself, but we risk being unable to develop real consensus because those who continue in the discussion will have won by exhausting anyone who disagrees with them. I note that neither "revise 3986" nor "produce a consensus list of where 3986 needs attention" have ever been part of this WG's charter. You've already made a consensus call in this, I've seen no objections to the consensus call, and the discussions, challenges to be specific, arguments that some position isn't real, etc., are just adding noise and reducing the chances of focused discussions that would move us forward. If we can't put a stop to this, I suggest it is time to give up and shut down. regards, john From nobody Thu Oct 30 18:20:26 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863A91A8A57 for ; Thu, 30 Oct 2014 18:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.654 X-Spam-Level: ** X-Spam-Status: No, score=2.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfqdiyq7AAlS for ; Thu, 30 Oct 2014 18:20:21 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBE41A8A55 for ; Thu, 30 Oct 2014 18:20:21 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 1F8BB32E54B; Fri, 31 Oct 2014 10:19:36 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 7986_32ef_07425a14_a423_4472_bf84_82df08502701; Fri, 31 Oct 2014 10:19:35 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 9A931BF8FD; Fri, 31 Oct 2014 10:19:35 +0900 (JST) Message-ID: <5452E3A6.9040107@it.aoyama.ac.jp> Date: Fri, 31 Oct 2014 10:19:34 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John C Klensin , Larry Masinter , Andrew Newton , Peter Saint-Andre - &yet References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <60C787C60102868EF9CBBDD1@JcK-HP8200.jck.com> <54452CFA.4080301@gmx.de> <3F81AFE484A9F81881984FC3 @JcK-HP8200.jck.com> <54456777.90202@gmx.de> <54456DF9.5000501@andyet.net> <1e463492a84b4b8e9102f58fca6ece63@DM2PR0201MB0960.namprd02.prod.o utlook.com> <53a2c921c19a458bbfdb29eda8cf8d62@DM2PR0201MB0960.namprd02.prod.outlook.com> <00A73818E083D9D9A9956C49@JcK-HP8200.jck.com> In-Reply-To: <00A73818E083D9D9A9956C49@JcK-HP8200.jck.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/awkCsJpFNbcMhxMQo2zTShuku2k Cc: julian.reschke@gmx.de, urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 01:20:24 -0000 For the record, I agree with Larry re. leaving out fragment identifiers/f-components. Regards, Martin. On 2014/10/24 00:45, John C Klensin wrote: > (top post) > Larry, > > Thanks for the clarification. > > While I believe that the 3986 properties of fragments are > semantics and not part of the syntax and that distinction was > part of the motivation for Peter's introducing "f-component", > just as I believe that questions of the perceived 3986 > requirement for evaluating relative references are semantics and > not syntax, I think I'm now clear on what you are asking for and > why. That is a big help. > > best, > john > > > --On Thursday, October 23, 2014 14:45 +0000 Larry Masinter > wrote: > >>> Just to be sure, I think the above means that you believe >>> that, despite the WG's decision to use 3986 syntax only and >>> bypass the semantics (see Andy's recent postings), you >>> believe that we cannot use fragments (or "f-components") >>> without following the >>> 3986 rules about how fragments are "delegated". >> >>> Is that correct? If it is, do you believe similar delegation >>> requirements for p-components and/or q-components? >> >> My belief is that currently the scheme's definition has control >> over the syntax (within 3986 limitations) and complete control >> over the interpretation of / and ? delimited parts >> ('p-components' and 'q-components') but that, currently, >> the scheme's definition cannot define the syntax or >> interpretation of any # delimited part (the f-component). >> >> >> >>> FWIW, I just grepped 3986 and variations on the term >>> "delegate" appear to occur only in the following contexts: >>> >>> * A general statement about "Identifier" in Section 1.1 >>> that indicates that identification is delegated to each >>> scheme specification (without any language that I can >>> immediately find that restricts the scheme specification >>> from delegating it further). >>> >>> * Discussion about Authority in Section 3.2 (including >>> Host in 3.2.2). Those discussions would appear to be >>> irrelevant to URNs because they do not use an Authority >>> component, at least as the syntax is defined in 3986. >>> >>> That is all. "Delegation" terminology is not used about >>> fragments (or queries, etc.) at all. >>> >>> Again, FWIW, this sort of thing, including usage in >>> discussions of it by one of it listed authors, is one of the >>> reasons why some (perhaps many) of us find 3986 and its >>> terminology and coverage confusing. >> >> I apologize profusely for our failure of clarity for those >> trying to do a close reading of the exact words of the text. I >> am not among those who believe 3986 is perfect and should be >> carved into stone tablets or engraved on nickel disks. >> >> In this case, section 3.5 of RFC 3986 uses "defined by X" and >> "dependent on X" and not "delegated to X", an oversight >> which I admit might be confusing to some. >> >> Humbly, >> >> Larry >> -- >> http://larry.masinter.net >> >> >> > > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Thu Oct 30 18:29:07 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53E41A8A39 for ; Thu, 30 Oct 2014 18:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHlH8rXziJgW for ; Thu, 30 Oct 2014 18:29:04 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 695F41A8A1F for ; Thu, 30 Oct 2014 18:29:04 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id C6D5232E4A1; Fri, 31 Oct 2014 10:28:19 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 7983_1d26_92901012_c27b_4b07_a08f_22f41dbe76fa; Fri, 31 Oct 2014 10:28:18 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 46DB0BF8FD; Fri, 31 Oct 2014 10:28:19 +0900 (JST) Message-ID: <5452E5B2.8040707@it.aoyama.ac.jp> Date: Fri, 31 Oct 2014 10:28:18 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John C Klensin , Andrew Newton References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> In-Reply-To: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/DJUp7dU7tPfqKoKvyzhVnp65BLI Cc: urn@ietf.org Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 01:29:05 -0000 Hello Andy, I agree that discussion of RFC 3986 in general (except where it relates to URNs) should be off topic for this mailing list/group. However, I'd want to make sure that this also includes blanket statements as to "RFC 3986 being (fundamentally or whatever) broken". It wouldn't be appropriate if blanket criticism were okay, but any kind of defense were off-list. Regards, Martin. On 2014/10/31 09:10, John C Klensin wrote: > Andy, > > This is a formal and public request to you as Chair. > > Would you please rule discussions of what, specifically, is > wrong with 3986 or needs to be fixed in it, out of scope and > indicate that you will revoke posting rights for anyone who > persists in that discussion. The obvious exception would be > something that strictly and narrowly affects the relationship > between URN syntax and generic URI syntax. > > The result of those continued discussions is that people are > being driven off the mailing list and out of the WG who really > need URNs and have positions based on real requirements and > experience. Not only is that bad in itself, but we risk being > unable to develop real consensus because those who continue in > the discussion will have won by exhausting anyone who disagrees > with them. > > I note that neither "revise 3986" nor "produce a consensus list > of where 3986 needs attention" have ever been part of this WG's > charter. > > You've already made a consensus call in this, I've seen no > objections to the consensus call, and the discussions, > challenges to be specific, arguments that some position isn't > real, etc., are just adding noise and reducing the chances of > focused discussions that would move us forward. > > If we can't put a stop to this, I suggest it is time to give up > and shut down. > > regards, > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Thu Oct 30 18:40:49 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABA91A8A3E for ; Thu, 30 Oct 2014 18:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy1iwCOSO5vk for ; Thu, 30 Oct 2014 18:40:46 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id BBADF1A8A49 for ; Thu, 30 Oct 2014 18:40:46 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 09BEE32E571; Fri, 31 Oct 2014 10:40:02 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 7986_38ae_32411144_5cb2_4017_aa87_c096a88d288f; Fri, 31 Oct 2014 10:40:01 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 8A6C1BF8FD; Fri, 31 Oct 2014 10:40:01 +0900 (JST) Message-ID: <5452E870.9010303@it.aoyama.ac.jp> Date: Fri, 31 Oct 2014 10:40:00 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> In-Reply-To: <5452D0B5.8060008@network-heretics.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/5gg43oftQqDq2WhnxLXMIunbufI Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 01:40:48 -0000 [discussing this strictly with respect to URNs] On 2014/10/31 08:58, Keith Moore wrote: > On 10/30/2014 07:55 PM, "Martin J. D=C3=BCrst" wrote: >>>> What I'm pushing for is a spec that is sufficiently clear that the >>>> relative resolution algorithm defined by RFC 3986 indeed applies to >>>> URN URIs, even though the results it yields for most URN schemes mig= ht >>>> not be very useful. >> >> The relative resolution algorithm applies to any and all schemes >> (including URNs) where it is applied. > > Sorry, that's just insane. It makes no technical sense whatsoever. 398= 6 > is simply incorrect, and needs to be obsoleted and move to Historic. Please note that I wrote "where it is applied". And indeed, if I create=20 an HTML document with , and in the same=20 document have some relative URIs, then if I activate one of these=20 relative URIs, indeed the relative resolution algorithm (or some browser=20 variation thereof) will be applied. The result of that may be called "useless" or "insane" depending on your=20 choice of vocabulary, but it's what will happen. And it's fair game to=20 blame the document author. Regards, Martin. From nobody Thu Oct 30 18:52:45 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB361A8A27 for ; Thu, 30 Oct 2014 18:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKDTHAuJebxq for ; Thu, 30 Oct 2014 18:52:42 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B376D1A8A1E for ; Thu, 30 Oct 2014 18:52:42 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3060320BCE for ; Thu, 30 Oct 2014 21:52:42 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 30 Oct 2014 21:52:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=+Fz9SCgA5GF2Bn1pJzkDIn 0yahE=; b=U4zEL6eKjI2NirxgWFXkdZa+bi81N9Ani24Kh+Xmf5fWwgAr56Xz97 HT80Zin1M7r3SSvfaP8hBOYaeOsbjU5rN04sNHkFrKxut8pP24mx7a0OKMP3Mqln xdmmxhmjft9BohmzpN+QUnmaguJDbLa9bSb50/tPq7pmE/oyiwhow= X-Sasl-enc: ibhhZE5ae0dj063LpzX93P9C93mJBRtAdkPLIJFCTSnZ 1414720361 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 745C1C0000A; Thu, 30 Oct 2014 21:52:41 -0400 (EDT) Message-ID: <5452EB5E.8000206@network-heretics.com> Date: Thu, 30 Oct 2014 21:52:30 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <5452E870.9010303@it.aoyama.ac.jp> In-Reply-To: <5452E870.9010303@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/jxYGaGxcvzIeVRBHoZ_e4g6sgSg Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 01:52:44 -0000 On 10/30/2014 09:40 PM, "Martin J. Dürst" wrote: > > Please note that I wrote "where it is applied". And indeed, if I > create an HTML document with , and in the > same document have some relative URIs, then if I activate one of these > relative URIs, indeed the relative resolution algorithm (or some > browser variation thereof) will be applied. With a document named exclusively by a URN, there's essentially zero chance that it's applicable. It's difficult enough to make and mantain persistent identifiers for single resources. Trying to make persistent identifiers with persistent relationships between resources embedded in those identifiers is extremely difficult and almost certainly to fail. > The result of that may be called "useless" or "insane" depending on > your choice of vocabulary, but it's what will happen. And it's fair > game to blame the document author. I don't think so. It's not wrong for a document to have multiple names, one being a URN and another being a URL. Nor is it the document author's fault if a document that contains relative URLs is given a URN as one of its names. The safest thing to say about such relative URLs in the context of URNs is that they are extremely unlikely to be resolvable when the document is referenced entirely as a URN, without any intervening URN to URL resolution step. If on the other hand there is a URN to URL resolution step, there's at least one context in which the relative URL potentially makes sense - but the result of applying that relative URL to the base URL is still a URL, not a URN. Keith From nobody Thu Oct 30 19:12:21 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430731A8A6E for ; Thu, 30 Oct 2014 19:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3HdZfoyzzRo for ; Thu, 30 Oct 2014 19:12:16 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776C91A8A59 for ; Thu, 30 Oct 2014 19:12:16 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D60B920A9A for ; Thu, 30 Oct 2014 22:12:15 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 30 Oct 2014 22:12:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=uLVwtD84WGbS/byyqv2Pyc X5tlM=; b=hHdA2GNBsmd9V0IIs2aY7XhqeoHiV+AYz6s3cQntEJBSnw1G3KH1vw COYR0Y23zi7d8MwR16BNVMxuZ+QsnvLMWyBHkBxPmrJqlPJzCDSydFozwuICBZHX e5oC/LmoRD9kPxU++Ua8XJltU+HK0eMPDelzedHY9QVonbvZgCJ6Q= X-Sasl-enc: qtdO3RlZnh3aeHN4yruN3OOs7a13AUlx0NHe3yWu/YE0 1414721535 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 62C896800F5; Thu, 30 Oct 2014 22:12:15 -0400 (EDT) Message-ID: <5452EFF4.9020204@network-heretics.com> Date: Thu, 30 Oct 2014 22:12:04 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> <5452E5B2.8040707@it.aoyama.ac.jp> In-Reply-To: <5452E5B2.8040707@it.aoyama.ac.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Ve8bFglhBliQytUn1J9lIpcQ-Mc Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:12:18 -0000 On 10/30/2014 09:28 PM, "Martin J. Dürst" wrote: > I agree that discussion of RFC 3986 in general (except where it > relates to URNs) should be off topic for this mailing list/group. > > However, I'd want to make sure that this also includes blanket > statements as to "RFC 3986 being (fundamentally or whatever) broken". > > It wouldn't be appropriate if blanket criticism were okay, but any > kind of defense were off-list. Right, so make the biggest problem that this group faces out-of-scope. That's an awesome way to make the group irrelevant. Keith From nobody Thu Oct 30 19:27:53 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF531A8A83 for ; Thu, 30 Oct 2014 19:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEM1qFYeDp3g for ; Thu, 30 Oct 2014 19:27:49 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F181A8A7F for ; Thu, 30 Oct 2014 19:27:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4F99620697 for ; Thu, 30 Oct 2014 22:27:49 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 30 Oct 2014 22:27:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=eLnLC9OB4FEVmF1TTKw60k EtrZA=; b=WCMoROBYGObP9ea0riOEG7bCDS3TQCTWAXP4U+tp75vfrIVyRolt/W KWgg5QdaGieLVPYr6BqjHmz3HjKG6FYiD3PjSrbxgius1ZUSauiE1FKBLMjeAKr1 sgnhgvmHXP74IWoqOC1Rjl6wa/GkDf0ast5BFiT5ezzig91MytDds= X-Sasl-enc: Ny0c5NuizNknyGjOOrNtVl65yq3VknBnHxbMM1K3yovJ 1414722468 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 826A6C0000A; Thu, 30 Oct 2014 22:27:48 -0400 (EDT) Message-ID: <5452F399.9040606@network-heretics.com> Date: Thu, 30 Oct 2014 22:27:37 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> In-Reply-To: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/zdgNpXKj-1klCSZduSPbi1f-H2Y Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:27:52 -0000 Andy, I have an alternate formal and public request to you as Chair. Would you please petition IESG to amend this group's charter to explicitly permit it to take exception to RFC 3986 where URNs are concerned? It should be evident that the group is spinning its wheels largely because it is trying to reconcile the language in RFC 3986 with the actual needs of URNs, and that RFC 3986 has created confusion about the usage of URNs that did not exist (or at least was not nearly as significant) before RFC 3986 was published. Note that my request and John's are not mutually exclusive - the discussion could be ruled out-of-scope prior to a decision from IESG. But it would be nice to get ruling from IESG before Hawaii. And IMO if the IESG doesn't say yes, the group should probably just shut down. Keith On 10/30/2014 08:10 PM, John C Klensin wrote: > Andy, > > This is a formal and public request to you as Chair. > > Would you please rule discussions of what, specifically, is > wrong with 3986 or needs to be fixed in it, out of scope and > indicate that you will revoke posting rights for anyone who > persists in that discussion. The obvious exception would be > something that strictly and narrowly affects the relationship > between URN syntax and generic URI syntax. > > The result of those continued discussions is that people are > being driven off the mailing list and out of the WG who really > need URNs and have positions based on real requirements and > experience. Not only is that bad in itself, but we risk being > unable to develop real consensus because those who continue in > the discussion will have won by exhausting anyone who disagrees > with them. > > I note that neither "revise 3986" nor "produce a consensus list > of where 3986 needs attention" have ever been part of this WG's > charter. > > You've already made a consensus call in this, I've seen no > objections to the consensus call, and the discussions, > challenges to be specific, arguments that some position isn't > real, etc., are just adding noise and reducing the chances of > focused discussions that would move us forward. > > If we can't put a stop to this, I suggest it is time to give up > and shut down. > > regards, > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Thu Oct 30 19:31:01 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BDD1A8A86 for ; Thu, 30 Oct 2014 19:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbHAurSqz2MX for ; Thu, 30 Oct 2014 19:30:57 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB671A8A83 for ; Thu, 30 Oct 2014 19:30:57 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id a13so169660igq.11 for ; Thu, 30 Oct 2014 19:30:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BkgatotnDXGOfFyFXn9mFLrEZi/PodcoMYDltPaRT1o=; b=a8RSI52fVgCvRtzDdc9m6Tyy4pzD2mof81tzNsDwCW1Bm4qO1lz0Rzy+LEGIi+F5lq WnNP2OG7XytwEeCPeEpDHc12mGeH6uPEJoAuhAZ38wS3VqCczWb+6EwJEql1WJJh0+O0 92/AyXmFZomrFuGuom+G/+EtLd0rViMtioVbCEIlpuZkLSuEHNHoABeK7blBtzC2111P dqr2OB3snY/UCMqYoIUNtpp1cORDkheikQaSqi05emyS+3CrtVbkbfwFyEXMihW/YymL DgesHe/qaUCDmjPpAPG1NuTVgFPB0r/XdgWG+eEjBwyilIBug8dLG+rpLg8DZ76UmxhA tVkw== X-Gm-Message-State: ALoCoQnD+zt4vmVqq+5mZTJgQiRErSAuEmp5tx8BNYsOtQLLMAQeHi/yxDLzv1iDUJLc2IKvYero X-Received: by 10.107.135.146 with SMTP id r18mr7689390ioi.62.1414722656609; Thu, 30 Oct 2014 19:30:56 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id x9sm10372017igl.10.2014.10.30.19.30.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 19:30:55 -0700 (PDT) Message-ID: <5452F45C.4020001@andyet.net> Date: Thu, 30 Oct 2014 20:30:52 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> <5452E5B2.8040707@it.aoyama.ac.jp> <5452EFF4.9020204@network-heretics.com> In-Reply-To: <5452EFF4.9020204@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Bnx7RsJC8XKljLH3ujqhFwtgscg Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:30:59 -0000 On 10/30/14, 8:12 PM, Keith Moore wrote: > On 10/30/2014 09:28 PM, "Martin J. Dürst" wrote: >> I agree that discussion of RFC 3986 in general (except where it >> relates to URNs) should be off topic for this mailing list/group. >> >> However, I'd want to make sure that this also includes blanket >> statements as to "RFC 3986 being (fundamentally or whatever) broken". >> >> It wouldn't be appropriate if blanket criticism were okay, but any >> kind of defense were off-list. > > Right, so make the biggest problem that this group faces out-of-scope. > That's an awesome way to make the group irrelevant. Discouraging and sarcastic statements like that don't help, Keith. We've got some folks here trying hard to cut the Gordian Knot and finish the URN (not URI) work in a way that enables us to declare some measure of success, while leaving work on specific NIDs up to groups that include the relevant subject-matter experts (who are clearly *not* involved here and never will be). We're not here to fix RFC 3986, if it needs fixing in the first place. I am completely agnostic on that topic. I just want to finish the URN updates so that we can close this WG and let other folks get on with work in their own domains (information sciences etc.). Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Oct 30 19:34:31 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BCE1A8A83 for ; Thu, 30 Oct 2014 19:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vcr1VxkO0g3H for ; Thu, 30 Oct 2014 19:34:27 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51AF1A8A86 for ; Thu, 30 Oct 2014 19:34:27 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E6E8520996 for ; Thu, 30 Oct 2014 22:34:25 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 30 Oct 2014 22:34:25 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=m1JG8ZR2UJea9b0EZGbwkv rjj48=; b=QtYtHk0lJ1ozs9t4DUrOyWKnUzd0EEioZaa5zxR11WWNSZadZXhftu kE28tpm1SteQJ4Q2pgrzNaOKSztFfOeOyATZTa8HaeWger2F0cQNYJCOGuxJ1RWQ Fb780vIRl5ztDLtDyPZEiR8t6fyuSfFBhteTHEQDAJq5ZeoQ/B0Qw= X-Sasl-enc: XvNkDdFEJTChFTSNZshP1M4NLZ8fKGP6zqMBN2oQUtxm 1414722865 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 63046C00008; Thu, 30 Oct 2014 22:34:25 -0400 (EDT) Message-ID: <5452F526.20804@network-heretics.com> Date: Thu, 30 Oct 2014 22:34:14 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , urn@ietf.org References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> <5452E5B2.8040707@it.aoyama.ac.jp> <5452EFF4.9020204@network-heretics.com> <5452F45C.4020001@andyet.net> In-Reply-To: <5452F45C.4020001@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Yfuora7IsGRrGcFXD-a5uzfjX4k Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:34:30 -0000 On 10/30/2014 10:30 PM, Peter Saint-Andre - &yet wrote: > On 10/30/14, 8:12 PM, Keith Moore wrote: >> On 10/30/2014 09:28 PM, "Martin J. Dürst" wrote: >>> I agree that discussion of RFC 3986 in general (except where it >>> relates to URNs) should be off topic for this mailing list/group. >>> >>> However, I'd want to make sure that this also includes blanket >>> statements as to "RFC 3986 being (fundamentally or whatever) broken". >>> >>> It wouldn't be appropriate if blanket criticism were okay, but any >>> kind of defense were off-list. >> >> Right, so make the biggest problem that this group faces out-of-scope. >> That's an awesome way to make the group irrelevant. > > Discouraging and sarcastic statements like that don't help, Keith. Sorry to be discouraging and sarcastic, but I think it's both succinct and accurate. > We've got some folks here trying hard to cut the Gordian Knot and > finish the URN (not URI) work in a way that enables us to declare some > measure of success, while leaving work on specific NIDs up to groups > that include the relevant subject-matter experts (who are clearly > *not* involved here and never will be). That, to my mind, is not success, it is failure. It is throwing in the towel at trying to facilitate uniform treatment of URNs in software. > We're not here to fix RFC 3986, if it needs fixing in the first place. I would agree with you about that, were it not extremely evident that the belief that we need to adhere to RFC 3986 is blocking progress. Keith From nobody Thu Oct 30 19:35:09 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D841A8A8A for ; Thu, 30 Oct 2014 19:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgvVHGXJJKKa for ; Thu, 30 Oct 2014 19:35:01 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9CE1A8A88 for ; Thu, 30 Oct 2014 19:35:00 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id y20so411556ier.25 for ; Thu, 30 Oct 2014 19:35:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=r+NW8YDB0B18DJwX7Pp3qMeTCNNuEWaHPloIc0hJ4J0=; b=CIKMr6yd8lly++4zqdlTnqKLGqUa90/c9u5G8b6qEU9IJpif3g1KFP0LifpubjrUgv 1wyzrf9O7GJmloQhXjEBPaLAO3OhRc0hmFy5VezGyiddC8QTxSeBv24GNSBJSCyy9Z8E T4SPH2wBWaBMhIWv9R4BiJi5gQXMm0fCGAAjlOlt1q466slYQkM9+YX4mGNyl9WJyIwO i2vQOsgN3MJ9e4Y63hUDkoM2vTcAncKA7gCz+v6l/bM46XK6yWUget4oSmBoiLtkdLrJ IIcjFrFfwXN8X4Tg77p+Pi6dbYn0aK2mJN1SgHpQn6HmoogDv0pLv0dgCMS8MYYmUuhw Mo2g== X-Gm-Message-State: ALoCoQluR8AvRnvMq+qrxfwsJ7sUZEOnIfVyZVGMUDT1hGXNesbYEWpoKJGvmwH9BxEM6pftnnMd X-Received: by 10.43.129.196 with SMTP id hj4mr21614846icc.21.1414722900258; Thu, 30 Oct 2014 19:35:00 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id rp5sm5896029igb.19.2014.10.30.19.34.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 19:34:59 -0700 (PDT) Message-ID: <5452F50E.4000006@andyet.net> Date: Thu, 30 Oct 2014 20:33:50 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> <5452F399.9040606@network-heretics.com> In-Reply-To: <5452F399.9040606@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/LVzPUd0DRWDHLvrGKkW9LKLDZp8 Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:35:03 -0000 On 10/30/14, 8:27 PM, Keith Moore wrote: > Andy, > > I have an alternate formal and public request to you as Chair. > > Would you please petition IESG to amend this group's charter to > explicitly permit it to take exception to RFC 3986 where URNs are > concerned? It should be evident that the group is spinning its wheels > largely because it is trying to reconcile the language in RFC 3986 with > the actual needs of URNs, and that RFC 3986 has created confusion about > the usage of URNs that did not exist (or at least was not nearly as > significant) before RFC 3986 was published. > > Note that my request and John's are not mutually exclusive - the > discussion could be ruled out-of-scope prior to a decision from IESG. > But it would be nice to get ruling from IESG before Hawaii. And IMO if > the IESG doesn't say yes, the group should probably just shut down. Why do we need to expand the scope of work here? If anything I think we need to narrow it, by explicitly leaving 3986 out of scope. If folks want to update 3986, it would be best to charter a WG specifically for that work - not saddle the URNBIS WG with that Herculean task. I'll note that 2141bis does not, and need not, update 3986. All it does is replace 2141. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Oct 30 19:38:13 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAACB1A8A8C for ; Thu, 30 Oct 2014 19:38: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_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl_PfeUl7dT1 for ; Thu, 30 Oct 2014 19:38:09 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B585B1A8A6B for ; Thu, 30 Oct 2014 19:38:09 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id x19so424937ier.33 for ; Thu, 30 Oct 2014 19:38:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0wdVP5re6tyDG1ZV8+2Ree9R2YhQEAilJhs7+CZ9tVc=; b=J4Him4UUZZjrCO4BMs1oMvNvtB6LCAsQzce36m+Ok99HDiNuysQAjlxGLMcp6hdHfw V8jF4CK7E5/4VFtupne3LLKHXLsf4B7WxmwwSBaNQb4ar9G7fLps9CgkDGD8slnByYQm ROuhu3NJtbzy4DvehF0uYGg7KWY5rwXtpS7OBvJxu1eS7t66S58iog/DSVkfSzpvO8Oy itIyEN2RdmC2uNUleMzg9zUOxyz44xipour/XyHOYRQYFBQ426VmmCJ76mPfJRoXGUbl jEf08XeI9eN+pYw2D5ZRjW7jrU4ZHWkBGIWj6fCpNuRib/oFwiSEOBCURh5NBcz/Ef/e 1b8Q== X-Gm-Message-State: ALoCoQmUlfHkwK7LTDPXVwxu8wf2pzmVTh2gsv1vd8SgWMKsUCr22eYZY7f/Lo2yN8IlfJL7XW11 X-Received: by 10.50.79.197 with SMTP id l5mr907401igx.16.1414723089202; Thu, 30 Oct 2014 19:38:09 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id an1sm4888184igc.7.2014.10.30.19.38.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 19:38:08 -0700 (PDT) Message-ID: <5452F60F.90209@andyet.net> Date: Thu, 30 Oct 2014 20:38:07 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> <5452E5B2.8040707@it.aoyama.ac.jp> <5452EFF4.9020204@network-heretics.com> <5452F45C.4020001@andyet.net> <5452F526.20804@network-heretics.com> In-Reply-To: <5452F526.20804@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/0Q1OZ3_YzT3LxyBKXToK9dMjOuQ Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:38:12 -0000 On 10/30/14, 8:34 PM, Keith Moore wrote: > On 10/30/2014 10:30 PM, Peter Saint-Andre - &yet wrote: >> On 10/30/14, 8:12 PM, Keith Moore wrote: >>> On 10/30/2014 09:28 PM, "Martin J. Dürst" wrote: >>>> I agree that discussion of RFC 3986 in general (except where it >>>> relates to URNs) should be off topic for this mailing list/group. >>>> >>>> However, I'd want to make sure that this also includes blanket >>>> statements as to "RFC 3986 being (fundamentally or whatever) broken". >>>> >>>> It wouldn't be appropriate if blanket criticism were okay, but any >>>> kind of defense were off-list. >>> >>> Right, so make the biggest problem that this group faces out-of-scope. >>> That's an awesome way to make the group irrelevant. >> >> Discouraging and sarcastic statements like that don't help, Keith. > > Sorry to be discouraging and sarcastic, but I think it's both succinct > and accurate. > >> We've got some folks here trying hard to cut the Gordian Knot and >> finish the URN (not URI) work in a way that enables us to declare some >> measure of success, while leaving work on specific NIDs up to groups >> that include the relevant subject-matter experts (who are clearly >> *not* involved here and never will be). > > That, to my mind, is not success, it is failure. It is throwing in the > towel at trying to facilitate uniform treatment of URNs in software. I think we have discovered that we simply don't have the right people in the room to achieve that goal. Personally, I would rather reach an achievable goal than to set the bar so high that it cannot be achieved. That, to me, is setting ourselves up for inevitable failure. Now, maybe I have too much time invested here to admit that we need to ignore the sunk costs and declare failure right now. But I think that would be a disservice to the URN community, even if most of the URN users aren't actively engaged here. >> We're not here to fix RFC 3986, if it needs fixing in the first place. > > I would agree with you about that, were it not extremely evident that > the belief that we need to adhere to RFC 3986 is blocking progress. But I think we have given up that belief. Or at least a significant portion of the folks here have done so. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Oct 30 19:41:48 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634F11A8A93 for ; Thu, 30 Oct 2014 19:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzxVECPkp5qu for ; Thu, 30 Oct 2014 19:41:46 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0475D1A8A91 for ; Thu, 30 Oct 2014 19:41:46 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6B3A220D90 for ; Thu, 30 Oct 2014 22:41:45 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 30 Oct 2014 22:41:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=TutDrhB2id7qDw3AqSxntB 7dqAw=; b=LoOAIpke6a4OJR7j6+SBuCuXie35+QKxkgebdJn3PwFL/hhgv4RbXg s/P3jTxYHdisKem5IhbTNwrqoD8w3SkF86dPJrR6Id4UHrsDt27PjiMjcSgnUzKQ k25iju5Pz/GgmcxUj2e+l5KCywhDUg55b0G8ybh2sAm8u73BiyjsM= X-Sasl-enc: rCQtB1GEYH3svLx0nZy8mVyhlsWvUmldzVK8y1G4/CYe 1414723305 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 9FAA26800F0; Thu, 30 Oct 2014 22:41:44 -0400 (EDT) Message-ID: <5452F6DD.2070509@network-heretics.com> Date: Thu, 30 Oct 2014 22:41:33 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , urn@ietf.org References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> <5452F399.9040606@network-heretics.com> <5452F50E.4000006@andyet.net> In-Reply-To: <5452F50E.4000006@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/npdVKnKIuPcszP_9187AnMJ4Nt0 Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:41:47 -0000 On 10/30/2014 10:33 PM, Peter Saint-Andre - &yet wrote: > Why do we need to expand the scope of work here? If anything I think > we need to narrow it, by explicitly leaving 3986 out of scope. To be clear, I don't want the group to undertake the task of revising 3986. I just want IESG to make it clear that the group can explicitly override it where URNs are concerned, and where there are good reasons to do so. I think this will actually help URNBIS to get useful work done. Keith From nobody Thu Oct 30 19:45:10 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E5B1A8A91 for ; Thu, 30 Oct 2014 19:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q_4G4Y4e1C4 for ; Thu, 30 Oct 2014 19:45:06 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D202D1A8A83 for ; Thu, 30 Oct 2014 19:45:05 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id hn18so199351igb.1 for ; Thu, 30 Oct 2014 19:45:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zNNbFNQUXcX138DXQ6T5oaip9dlkHu/QIVtOjs5En7w=; b=BihJd4dqSfuInNanfzHQ0oJtHzy/Hu45xDPUAv5GTvDCi2I72NBQnec54ly4tA7sEO R+9Re2GYph49OpfVNBTj59pMtrSAWB4vqXIplMhw6BACNMIIGfimESfHDmUaBzaBnprM g2TnavMLTjNWOuZVeY+Ae2c8ZXfB5MslQY7dYuCrkkRAZkLYQSChHBJeOQflKnCJivA9 MxeTJKShlX4CJ4fbJ267GddNuffRHKRdEAGdx4Wf6D1P3GnXnlI4JeqLMnIv4ILaFjfs 3cKf76CxzUlGGgb7XbRB4XTqyMgS9SKfk6UES+HSpwrgjmUdG6r0jnx3ELEUH8xRBCTg qodw== X-Gm-Message-State: ALoCoQnsrbHbS+80zOMlI3tSZghyLDypJpp4VDxSiHJHM837MxE2Cgb0Md6dDsRRI1khznL1vu/g X-Received: by 10.50.4.35 with SMTP id h3mr783585igh.37.1414723505281; Thu, 30 Oct 2014 19:45:05 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 42sm4563786iok.29.2014.10.30.19.45.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 19:45:04 -0700 (PDT) Message-ID: <5452F7AF.5040504@andyet.net> Date: Thu, 30 Oct 2014 20:45:03 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> <5452F399.9040606@network-heretics.com> <5452F50E.4000006@andyet.net> <5452F6DD.2070509@network-heretics.com> In-Reply-To: <5452F6DD.2070509@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/5VZJK7F2ayfTjCqhAoyjqEY-Gs0 Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:45:08 -0000 On 10/30/14, 8:41 PM, Keith Moore wrote: > On 10/30/2014 10:33 PM, Peter Saint-Andre - &yet wrote: >> Why do we need to expand the scope of work here? If anything I think >> we need to narrow it, by explicitly leaving 3986 out of scope. > > To be clear, I don't want the group to undertake the task of revising > 3986. I just want IESG to make it clear that the group can explicitly > override it where URNs are concerned, and where there are good reasons > to do so. I think this will actually help URNBIS to get useful work done. Ah, I see. Maybe that would indeed help, although getting the IESG to bless a recharter will itself take time that perhaps could be better spent doing the work. Those efforts could happen in parallel, though. This sounds like something the chair(s) and AD(s) might want to discuss at IETF 91. I won't be there, myself, but perhaps some in-person discussions would be productive... Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Oct 30 19:45:14 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0711A8A9A for ; Thu, 30 Oct 2014 19:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmSNSPesh0V0 for ; Thu, 30 Oct 2014 19:45:11 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D719C1A8A94 for ; Thu, 30 Oct 2014 19:45:10 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 519E62095A for ; Thu, 30 Oct 2014 22:45:10 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 30 Oct 2014 22:45:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=flBYREs/21FoxoSguFkzxu Pw1cY=; b=MGWG6MIDxqCM4o3gkPaTnluxkoYf+gEKnR8VLLYben9kMztPuIbVjO yEHDJfE2PGY2o/R6pyG0wAv+ZZIJSfc1nuqcJ8LW6VEbup7vszQfkN0PUi25zEf3 qNHvA2B8W4/14dhApLfie+f4k4HmR+rYeDePM3O7TRgL6YvVR3Bd0= X-Sasl-enc: q5IeCxneN1S/3f9JJXaerh7UZcEiM9wD1kaogPy+8GWg 1414723510 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id CE8BFC00012; Thu, 30 Oct 2014 22:45:09 -0400 (EDT) Message-ID: <5452F7AB.5@network-heretics.com> Date: Thu, 30 Oct 2014 22:44:59 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , urn@ietf.org References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> <5452E5B2.8040707@it.aoyama.ac.jp> <5452EFF4.9020204@network-heretics.com> <5452F45C.4020001@andyet.net> <5452F526.20804@network-heretics.com> <5452F60F.90209@andyet.net> In-Reply-To: <5452F60F.90209@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/l61-OJBm00M4l8j7H6KyhHfC2fg Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 02:45:12 -0000 On 10/30/2014 10:38 PM, Peter Saint-Andre - &yet wrote: >> >>> We've got some folks here trying hard to cut the Gordian Knot and >>> finish the URN (not URI) work in a way that enables us to declare some >>> measure of success, while leaving work on specific NIDs up to groups >>> that include the relevant subject-matter experts (who are clearly >>> *not* involved here and never will be). >> >> That, to my mind, is not success, it is failure. It is throwing in the >> towel at trying to facilitate uniform treatment of URNs in software. > > I think we have discovered that we simply don't have the right people > in the room to achieve that goal. Personally, I would rather reach an > achievable goal than to set the bar so high that it cannot be > achieved. That, to me, is setting ourselves up for inevitable failure. The problem with your "achievable goal" is that it likely precludes anyone ever facilitating uniform treatment of URNs in software. Just because we might manage to publish some RFCs doesn't necessarily mean we're improving things. >>> We're not here to fix RFC 3986, if it needs fixing in the first place. >> >> I would agree with you about that, were it not extremely evident that >> the belief that we need to adhere to RFC 3986 is blocking progress. > > But I think we have given up that belief. Or at least a significant > portion of the folks here have done so. Well, maybe I've misread the sense of the group, but to me there seem to be several people still holding on to it. Keith From nobody Thu Oct 30 22:26:01 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6FE1A8AB1 for ; Thu, 30 Oct 2014 22:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky60GWP5V38K for ; Thu, 30 Oct 2014 22:25:57 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 170DD1A8AAA for ; Thu, 30 Oct 2014 22:25:54 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id EB7E532E4A1; Fri, 31 Oct 2014 14:25:09 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 7986_64c9_5723ad97_88c2_4aaa_aada_86ee545c2233; Fri, 31 Oct 2014 14:25:09 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 39D95BF8FD; Fri, 31 Oct 2014 14:25:09 +0900 (JST) Message-ID: <54531D34.1010604@it.aoyama.ac.jp> Date: Fri, 31 Oct 2014 14:25:08 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <5452E870.9010303@it.aoyama.ac.jp> <5452EB5E.8000206@network-heretics.com> In-Reply-To: <5452EB5E.8000206@network-heretics.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Lcac_PtjN6FMHn4h2uUgI4GyQLs Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 05:25:59 -0000 Hello Keith, On 2014/10/31 10:52, Keith Moore wrote: > On 10/30/2014 09:40 PM, "Martin J. D=C3=BCrst" wrote: >> >> Please note that I wrote "where it is applied". And indeed, if I >> create an HTML document with , and in the >> same document have some relative URIs, then if I activate one of these >> relative URIs, indeed the relative resolution algorithm (or some >> browser variation thereof) will be applied. > > With a document named exclusively by a URN, there's essentially zero > chance that it's applicable. It's difficult enough to make and mantai= n > persistent identifiers for single resources. Trying to make persistent > identifiers with persistent relationships between resources embedded in > those identifiers is extremely difficult and almost certainly to fail. That may well be the case, and would be good advice to heed by everybody=20 involved. >> The result of that may be called "useless" or "insane" depending on >> your choice of vocabulary, but it's what will happen. And it's fair >> game to blame the document author. > > I don't think so. It's not wrong for a document to have multiple > names, one being a URN and another being a URL. Nor is it the documen= t > author's fault if a document that contains relative URLs is given a URN > as one of its names. I'm not sure you are aware of this, but the element is *inside*=20 the document. Of course there are various ways to get it in there,=20 including complicated CMS stuff, but in the wider sense, it's the=20 author/originator that got it there. My advice would be that if the=20 document has an URN and an URL, then in the element use the URL.=20 In the example I gave, that's not followed. > The safest thing to say about such relative URLs > in the context of URNs is that they are extremely unlikely to be > resolvable when the document is referenced entirely as a URN, without > any intervening URN to URL resolution step. If on the other hand ther= e > is a URN to URL resolution step, there's at least one context in which > the relative URL potentially makes sense - but the result of applying > that relative URL to the base URL is still a URL, not a URN. I agree. I haven't checked URN resolvers, because I don't know any, but=20 I'd expect that it would return the document with something like an http=20 Content-Location: header field, which could contain an URL, and that URL=20 should be taken as the base for the document if there isn't any =20 information inside the document. (Julian should be able to tell us=20 whether Content-Location: indeed works, or is supposed to work, like this= .) Regards, Martin. From nobody Thu Oct 30 22:35:24 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAFC1A8AAA for ; Thu, 30 Oct 2014 22:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l57mD85SCpQi for ; Thu, 30 Oct 2014 22:35:20 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F8B1A8AB2 for ; Thu, 30 Oct 2014 22:35:20 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0DCC8209AD for ; Fri, 31 Oct 2014 01:35:20 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 31 Oct 2014 01:35:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=+jfucwDgjCZmKXFYUFcmAT VYwmg=; b=bJViAnSfpJBmwyZuJDr5+Aq1jGNvODEzG7OAsx7bTNCymXDsFzdgmE brBOXXyzpTUa0wtJFxKXUAoILX78ZIGS7gjiRGdDZ7Wk3cvhg3Gu87Xj8jtGalP4 muF3mfajHaDKcXBSqnki5krErDSI32qfDt9H+C5xRkR1tpftQhGWc= X-Sasl-enc: mNR/8tjzOR6zRWlQ3QzqHdjKwIvvEe8AUttdc1eF28Dl 1414733719 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 932A1C00014; Fri, 31 Oct 2014 01:35:19 -0400 (EDT) Message-ID: <54531F8C.8070204@network-heretics.com> Date: Fri, 31 Oct 2014 01:35:08 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <5452E870.9010303@it.aoyama.ac.jp> <5452EB5E.8000206@network-heretics.com> <54531D34.1010604@it.aoyama.ac.jp> In-Reply-To: <54531D34.1010604@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bCQ6Np07CxTkX0-14waqMfLH7gs Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 05:35:23 -0000 On 10/31/2014 01:25 AM, "Martin J. Dürst" wrote: > Hello Keith, > > On 2014/10/31 10:52, Keith Moore wrote: >> On 10/30/2014 09:40 PM, "Martin J. Dürst" wrote: >>> >>> Please note that I wrote "where it is applied". And indeed, if I >>> create an HTML document with , and in the >>> same document have some relative URIs, then if I activate one of these >>> relative URIs, indeed the relative resolution algorithm (or some >>> browser variation thereof) will be applied. >> >> With a document named exclusively by a URN, there's essentially zero >> chance that it's applicable. It's difficult enough to make and mantain >> persistent identifiers for single resources. Trying to make persistent >> identifiers with persistent relationships between resources embedded in >> those identifiers is extremely difficult and almost certainly to fail. > > That may well be the case, and would be good advice to heed by > everybody involved. > >>> The result of that may be called "useless" or "insane" depending on >>> your choice of vocabulary, but it's what will happen. And it's fair >>> game to blame the document author. >> >> I don't think so. It's not wrong for a document to have multiple >> names, one being a URN and another being a URL. Nor is it the document >> author's fault if a document that contains relative URLs is given a URN >> as one of its names. > > I'm not sure you are aware of this, but the element is *inside* > the document. Of course there are various ways to get it in there, > including complicated CMS stuff, but in the wider sense, it's the > author/originator that got it there. My advice would be that if the > document has an URN and an URL, then in the element use the > URL. In the example I gave, that's not followed. Yes, sorry I was interpreting "base URI" in a more general context, rather than taking your example literally. I'm sure you were being precise, and I was interpreting your example more broadly than you intended. For the specific case of a element containing a URN, and the same document containing references to relative URIs, I would essentially call that a syntax error at least for those references. A validator should mark those references as invalid. (I mean, if you can detect such errors at their source, why wait until document evaluation time?) >> The safest thing to say about such relative URLs >> in the context of URNs is that they are extremely unlikely to be >> resolvable when the document is referenced entirely as a URN, without >> any intervening URN to URL resolution step. If on the other hand there >> is a URN to URL resolution step, there's at least one context in which >> the relative URL potentially makes sense - but the result of applying >> that relative URL to the base URL is still a URL, not a URN. > > I agree. I haven't checked URN resolvers, because I don't know any, > but I'd expect that it would return the document with something like > an http Content-Location: header field, which could contain an URL, > and that URL should be taken as the base for the document if there > isn't any information inside the document. (Julian should be > able to tell us whether Content-Location: indeed works, or is supposed > to work, like this.) Nothing (that I'm aware of) says that a resolver has to use HTTP, or if it uses HTTP, that it has to use its response header fields in this way. I would prefer a richer representation of resource description than is accorded by HTTP response header fields, even if in most situations it's going to be subsetted. But in general, resolving a URN to a URL has always been at least one of the anticipated mechanisms for gaining access to resources named by URNs. Keith From nobody Fri Oct 31 08:03:26 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85351A9079 for ; Fri, 31 Oct 2014 08:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kcnBh1hBWql for ; Fri, 31 Oct 2014 08:03:21 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A5B1A9039 for ; Fri, 31 Oct 2014 08:03:21 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XkDjJ-0002Yh-Ra; Fri, 31 Oct 2014 11:03:11 -0400 Date: Fri, 31 Oct 2014 11:03:04 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Keith Moore , Peter Saint-Andre - &yet , Andrew Newton Message-ID: <4750BE9ADB7A545BCF787F5B@JCK-EEE10> In-Reply-To: <5452E5B2.8040707@it.aoyama.ac.jp> References: <3BDE9AFFBB716371B4F2901C@[10.10.9.223]> <5452E5B2.8040707@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/BhpscCr5UUIrT-7E6DtVuxJs1vI Cc: urn@ietf.org Subject: Re: [urn] Discussions about what is wrong with/ needs to be fixed in 3986 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:03:25 -0000 (Combining responses. Apologies for not responding to the earlier notes -- I'm in a time zone convenient only to Martin among those who have responded and it has been a very long day.) --On Friday, 31 October, 2014 10:28 +0900 "\"Martin J. = D=C3=BCrst\"" wrote: >... > However, I'd want to make sure that this also includes blanket > statements as to "RFC 3986 being (fundamentally or whatever) > broken". That is certainly consistent with my intent. --On Thursday, 30 October, 2014 22:27 -0400 Keith Moore wrote: > Would you please petition IESG to amend this group's charter > to explicitly permit it to take exception to RFC 3986 where > URNs are concerned?=20 Both the now-obsolete "URNs are not URIs" draft and the current (to be updated as soon as I can find cycles, probably the first half of next week) "Semantics clarification" drafts were written with exactly that "take exception" intent. Barry (and sometimes Pete as well) has been in the loop on both. With one qualification, I don't see any reason why "petitioning the IESG" is needed. =20 Those drafts have the general character of "aspects of 3986 that interfere, or are claimed to interfere, with this WG redefining URNs to meet the requirements it sees and the design it concludes it should adopt, just don't count and are irrelevant. Now it seems quite obvious to me that there is another possible approach, which it to make URNBIS the battleground for a full-scale attack on (and defense of) 3986bis, even with a "can't move forward with URNs until the alleged issues are definitively settled". That is a war that I (and Peter, and others) are clearly trying to avoid, even if only because it is clear to me that such a war would either never reach consensus or would take sufficiently long to do so to render any future work on URNs irrelevant. FWIW, changing the URNBIS WG into 3986BIS, whether the name were changed or not, would clearly (at least IMO) require community review and IESG agreement. > It should be evident that the group is > spinning its wheels largely because it is trying to reconcile > the language in RFC 3986 with the actual needs of URNs, and > that RFC 3986 has created confusion about the usage of URNs > that did not exist (or at least was not nearly as significant) > before RFC 3986 was published. While I agree with the "spinning the wheels" part of the above, I don't seem much effort to reconcile anything going on, only often aggressive assertions and counter-assertions about 3986 and the constraints it imposes. But I also belief that the WG has agreed to bypass the issue, that a consensus call has been made and not contested, and that the topic is now irrelevant to the WG's efforts. --On Thursday, 30 October, 2014 22:34 -0400 Keith Moore wrote: > On 10/30/2014 10:30 PM, Peter Saint-Andre - &yet wrote: >> We've got some folks here trying hard to cut the Gordian Knot >> and finish the URN (not URI) work in a way that enables us >> to declare some measure of success, while leaving work on >> specific NIDs up to groups that include the relevant >> subject-matter experts (who are clearly *not* involved here >> and never will be). >=20 > That, to my mind, is not success, it is failure. It is > throwing in the towel at trying to facilitate uniform > treatment of URNs in software. That is _not_ about 3986 and is a discussion I think the WG needs to have an either come to consensus on or give up. From my point of view (and I think Peter's and Juha's), there are three ways to give up on this ("throw in the towel"): (1) We give up, advise Barry and the IESG that there is no hope of the WG reaching consensus on anything that would allow progress, and recommend that the WG be shut down and, by extension, the IETF abandon URNs (or at least URNs beyond 2141 with the potential for continuing questions of whether 2141 conforms sufficiently to 3986 to be anything but Historic whether officially reclassified or not). (2) We adopt a strategy of insisting that all URNs behave the same way wrt p/q/f-components and probably resolution. Attractive as that might seem, there are two problems with it: It clear to me that we will never reach consensus about what that behavior will be, largely because different communities appear to have very different (real or perceived) needs. In either case, the result is that communities who are convinced they need URNs will go their own way. That would permit the IETF to feel righteous about preserving its architectural principles, morals, etc. (although there will still be a debate about 3896 and architectural principles) but at the cost of (i) being able to lay out any sort of common framework for URNs, however general and (ii) begin able to have a well-structured registry that encourages good descriptions and helps avoid name collisions. I think those two considerations are sufficient to justify our staying in the game rather than symbolically falling on our architecturally-pure and aesthetic swords. YMMD. --On Thursday, 30 October, 2014 22:44 -0400 Keith Moore wrote: >> I think we have discovered that we simply don't have the >> right people in the room to achieve that goal. And I would add (again) that our behavior pattern has been quite effective in driving some of the "right people" away. >> Personally, I >> would rather reach an achievable goal than to set the bar so >> high that it cannot be achieved. That, to me, is setting >> ourselves up for inevitable failure. >=20 > The problem with your "achievable goal" is that it likely > precludes anyone ever facilitating uniform treatment of URNs > in software. Yes, it probably does. It does not, however, preclude it nearly as well or efficiently as our giving up (or continuing to debate this forever) and having other groups define URNs (perhaps all URNs, consistently) according to their views about what the needs are and what is important, yielding multiple, contradictory, standards. =20 There is another strategy we could adopt and it reflects some remarks made in Toronto: (1) We abandon URNs and the concept of a single, persistent-name identifier. Maybe we deprecate 2141 and maybe we don't. (2) We tell every community that wants something URN-ish that they need to define a new URI type with a scheme that is tied to either the particular type of identifier and namespace (effectively promoting NIDs to schemes) or to the community.=20 Of course, (2) would require every new scheme to fight the 3986 battles, to the degree to which they were relevant, on their own. That would require a true commitment to the IETF as the preferred standards body, a commitment that dominated any desire to get work done. And it is likely that many of those outside bodies, especially those who have already deployed identifiers using URN syntax, would simply ignore us and go do their thing. That just makes the above strategy another way to fail completely. > Just because we might manage to publish some RFCs doesn't > necessarily mean we're improving things. Just because we have the ability to stand on some soapbox and say "it isn't a URN unless we say it is a URN", "you are forbidden to call something a URN or use the 'urn:' scheme unless we say it is ok", and/or "you cannot use a URN that way" doesn't mean anyone will pay attention to us. It is pretty clear to me that, if they don't, we are adding to the confusion rather than improving things. > Well, maybe I've misread the sense of the group, but to me > there seem to be several people still holding on to it. I saw a consensus call/statement from the Chair a while back, one that no one has contested. It was on that basis that I asked him to shut down the 3986 discussions that you seem to want to see continue. john From nobody Fri Oct 31 12:59:44 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F341A0016 for ; Fri, 31 Oct 2014 12:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff1femCi7yX4 for ; Fri, 31 Oct 2014 12:59:41 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9CD81A0242 for ; Fri, 31 Oct 2014 12:59:40 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so8301025pab.24 for ; Fri, 31 Oct 2014 12:59:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=pJpZV2owNm2TCHY676ez6fhKBjPMDFREoCVA7C/kLdQ=; b=eIDfjWyoH0IJ2HnbO343UaAwNo2oEH0pWZcvBbieLJidSJ25ua1h/4ovE4kxU7r3mR PpLiRtInehssCGoxZImMrHOYc/RZ11m7rGsfTvsLkKIiWPcCYUJY4Q2s0L4Mxc5rVSAA icGTWcpzOqfCgRSY/HvmCcnkCG9QDOM0HZjSe+f01UCFVBCPJhpukGo9YlkLCDRrAw0k 1TrQZ+69kQYlcyu9YfW3n9u+RH/t9voA0VOfiu4VEPlrA74zZ3NkSWm4ZfPjtGkcjSdu BaQq5Dc7Uc9TjnaBk457M0XF1i/q6ibRJ9BKQ8Zb72KKqXr9eK0rGWKPswcrfd8U/7v5 cPNA== X-Gm-Message-State: ALoCoQlDlCNtKr/EVwfl72M0jpsvEltiJQJaCKNHrA0YzUWzpNxnYppmUiapK/Z37dZMaUqKo0bI MIME-Version: 1.0 X-Received: by 10.70.45.72 with SMTP id k8mr20335973pdm.146.1414785580487; Fri, 31 Oct 2014 12:59:40 -0700 (PDT) Received: by 10.66.194.13 with HTTP; Fri, 31 Oct 2014 12:59:40 -0700 (PDT) X-Originating-IP: [2001:500:4:15:f81a:75df:619:d692] Date: Fri, 31 Oct 2014 15:59:40 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/inhkFPklYGXi7vGCZz7s9ufan5U Subject: [urn] 3986, scope issues, list behavior, etc... X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 19:59:42 -0000 All, I am sorry for not being able to address this sooner as it appears discussions on this list have gone a little sideways. I do ask that everybody take a mental and/or emotional step back for a minute. While I do appreciate your passion for this topic, let us all remember that we must be collaborative in our efforts. A few requests have been asked to me as chair. Let me address them. With regards to revoking posting rights, in my view that action should only be taken for abusive situations as it denies a person their ability to participate in the IETF process. Taking IETF discussions off course is a common occurrence but is seldom malicious. Discussions regarding the revision of RFC 3986 are out of scope for this working group. As I have stated in the past, this working group's relationship with 3986 is to update the semantics, but not the syntax, as it relates to URNs only. All other digressions with regards to 3986 are off course. So I ask that you please attempt to remain on-course. And it is appropriate that others may ask that of you in a polite way. It is also important to realize that in the rough and tumble of IETF discussions, the words you may use might not have the same meaning to others and the words you hear or read may not have been intended as you have perceived. Descriptions of things being "broken" can be taken the wrong way but at the same time most of us can think of far more colorful words meant to agitate others. With regards to petitioning the IESG for a charter change, I'll discuss that with our AD. However, that does not preclude us from following the direction I have given above. And specifically to Keith's point about the uniform treatment of URNs in software, I hope we can have that discussion without worrying about our group's relevance or the fate of RFC 3986. In other words, we can decide as a group how important that is to our efforts. But that decision doesn't have to be a gating factor for the rest of our work. -andy your friendly neighborhood URNBIS co-chair