From L.Svensson@dnb.de Mon Jun 3 01:55:55 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE9021F8532 for ; Mon, 3 Jun 2013 01:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.76 X-Spam-Level: X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMe+jj6YTKZb for ; Mon, 3 Jun 2013 01:55:45 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7293421F86BB for ; Mon, 3 Jun 2013 01:55:38 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 0A4DA928AC; Mon, 3 Jun 2013 10:53:01 +0200 (CEST) From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: [urn] Queries in URNs (was: AW: URN fragments) Thread-Index: AQHOXjRgQzBWDNi+kU65Sr3EL9dcPZkjqurQ Date: Mon, 3 Jun 2013 08:55:36 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.46] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Barry Leiba , Keith Moore Subject: Re: [urn] Queries in URNs (was: AW: URN fragments) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 08:55:55 -0000 So, to sum up my understanding of the discussion so far (I write this as st= atements, please indicate if you agree or disagree with what I write): 1) Regardless if they make sense or not, there is agreement that queries in= URNs are different from queries sent to URN resolution services (or in oth= er words: Queries in RFC 2141 bis -- should we allow them -- are something = completely different than queries in RFC 2483 bis. 2) We seem to disagree if queries related to URNs should be considered part= of the URN or not: Michael writes [1]: [[ That language needs to be much clearer when it uses "part of" and "append t= o". What is being suggested is that you can include a query string along wi= th a URN that you can then send to the resource but that DOES NOT make that= query string part of the URN itself. It is a separate thing. There is no '= query part' to a URN. You can carry around a bag of characters with the URN= that you send to the resource, and you can even specify a syntax for how y= ou carry them around together, but the query string is still something that= is evaluated by the Resource. ]] Peter writes [2]: [[ As stated, personally I would prefer not to make query components part of U= RNs, or to append query components to URNs themselves. If you want to pass = a query component to a resolution service (e.g., via an HTTP URI for the re= solution service), that's something quite different and it seems fine to me= . ]] Barry writes [3]: [[ (1) Queries and fragments are valid URI syntax, and URNs are URIs. It seem= s reasonable to syntactically allow them in URNs, if we can agree on what t= hey semantically mean. ]] The way I read RFC 3986 puts me more on Barry's side: Every URN is a URI an= d thus the URN syntax adheres to the generic URI syntax. Sec 3 of RFC 3986 = says=20 URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] In my reading that makes query (and fragment) part of the URI and thus they= must be part of the URN as well if we decide to allow queries in URNs. If = we explicitly want to make queries something you add to a URN we must defin= e it as URN =3D "urn:" hier-part leaving the query out. Please apologise if I miss something obvious. 3) *If* we decide to allow queries in URNs the exact semantics of the query= MUST be stated during the NID registration process and specified in the re= gistration document; default is that queries are not allowed for a specific= namespace. That way we don't break anything since all existing namespaces = would need to re-register in order to use queries. Is there agreement on this? 4) @Juha: you say that queries only make sense in the context of URN resolv= ing. Does that mean that even if we allow queries in RFC 2141 bis, you woul= d disallow them in RFC 3187 bis (urn:isbn) since they have no meaning for r= esources identified by ISBNs? /Lars ***Lesen. H=F6ren. Wissen. Deutsche Nationalbibliothek*** ***Reading. Listening. Understanding. German National Library*** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de From stpeter@stpeter.im Mon Jun 3 21:27:06 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7909611E8169 for ; Mon, 3 Jun 2013 21:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgp-ZtwltNKK for ; Mon, 3 Jun 2013 21:26:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 057C321E80FE for ; Mon, 3 Jun 2013 20:28:15 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5F4E741234; Mon, 3 Jun 2013 21:41:21 -0600 (MDT) Message-ID: <51AD5ECC.2090607@stpeter.im> Date: Mon, 03 Jun 2013 21:28:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Svensson, Lars" References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Keith Moore , Barry Leiba Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 04:27:06 -0000 On 6/3/13 2:55 AM, Svensson, Lars wrote: > So, to sum up my understanding of the discussion so far (I write this as statements, please indicate if you agree or disagree with what I write): > > 1) Regardless if they make sense or not, there is agreement that queries in URNs are different from queries sent to URN resolution services (or in other words: Queries in RFC 2141 bis -- should we allow them -- are something completely different than queries in RFC 2483 bis. > > 2) We seem to disagree if queries related to URNs should be considered part of the URN or not: > Michael writes [1]: > [[ > That language needs to be much clearer when it uses "part of" and "append to". What is being suggested is that you can include a query string along with a URN that you can then send to the resource but that DOES NOT make that query string part of the URN itself. It is a separate thing. There is no 'query part' to a URN. You can carry around a bag of characters with the URN that you send to the resource, and you can even specify a syntax for how you carry them around together, but the query string is still something that is evaluated by the Resource. > ]] > > Peter writes [2]: > [[ > As stated, personally I would prefer not to make query components part of URNs, or to append query components to URNs themselves. If you want to pass a query component to a resolution service (e.g., via an HTTP URI for the resolution service), that's something quite different and it seems fine to me. > ]] > > Barry writes [3]: > [[ > (1) Queries and fragments are valid URI syntax, and URNs are URIs. It seems reasonable to syntactically allow them in URNs, if we can agree on what they semantically mean. > ]] > > The way I read RFC 3986 puts me more on Barry's side: Every URN is a URI and thus the URN syntax adheres to the generic URI syntax. But that doesn't follow. A URN is a URI with a scheme of 'urn'. Each URI scheme can define its own syntax, as long as that syntax is consistent with the generic URI syntax. > Sec 3 of RFC 3986 says > > URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] Section 3 of RFC 3986 also has this interesting summary: The following are two example URIs and their component parts: foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose So, according to RFC 3986, a URN is a URI with only a scheme component and a path component. And that is consistent with the syntax defined in RFC 2141: ::= "urn:" ":" > In my reading that makes query (and fragment) part of the URI and thus they must be part of the URN as well if we decide to allow queries in URNs. The operative word there is "if". :-) > If we explicitly want to make queries something you add to a URN we must define it as > > URN = "urn:" hier-part That's wrong, because RFC 3986 says: hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty and: path = path-abempty ; begins with "/" or is empty / path-absolute ; begins with "/" but not "//" / path-noscheme ; begins with a non-colon segment / path-rootless ; begins with a segment / path-empty ; zero characters path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0 segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; non-zero-length segment without any colon ":" pchar = unreserved / pct-encoded / sub-delims / ":" / "@" Thus, as far as I can see, the closest thing to the URN syntax definition in RFC 3986 is: URN = "urn:" path-noscheme However, the syntax of the 'urn' URI scheme is even more restrictive than that: ::= "urn:" ":" ::= [ 1,31 ] ::= | | | "-" ::= | | ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ::= 1* ::= | "%" ::= | | | | ::= | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" ::= "(" | ")" | "+" | "," | "-" | "." | ":" | "=" | "@" | ";" | "$" | "_" | "!" | "*" | "'" > leaving the query out. > Please apologise if I miss something obvious. See above. > 3) *If* we decide to allow queries in URNs the exact semantics of the query MUST be stated during the NID registration process and specified in the registration document; default is that queries are not allowed for a specific namespace. That way we don't break anything since all existing namespaces would need to re-register in order to use queries. > > Is there agreement on this? What code exists to parse URIs with the 'urn' scheme according to the syntax defined in RFC 2141? Would that code break if the syntax definition is liberalized? Peter -- Peter Saint-Andre https://stpeter.im/ From moore@network-heretics.com Mon Jun 3 21:48:02 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A9221F9953 for ; Mon, 3 Jun 2013 21:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhaTcP-rzgcX for ; Mon, 3 Jun 2013 21:47:47 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 975B521E8181 for ; Mon, 3 Jun 2013 20:51:57 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 332BC2032B; Mon, 3 Jun 2013 23:51:56 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 03 Jun 2013 23:51:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=7EGBoixtaybU5lvn1rimhO HALD4=; b=fyb0kUK4GDF4XT2h6F7KFbRyWhKmJIloQoRsnhcDJj0J4U5z/Ni3iW Rjgo0SBTM4UttmzcqZPzfMIe+kqOuhVEc8bR6BP/q9FKwviMXEvZQpjk20+LtUkk K8nnPypcq7cOBhsx7+jK+Gds1GfPAe9f78GHbiJz09YtvQcf3Nu8Y= X-Sasl-enc: wBz8CjuchU4ACHuNZJG+C1Fi1D1vF2xfRMeAvKJeG5lp 1370317915 Received: from [172.20.10.6] (unknown [173.102.104.235]) by mail.messagingengine.com (Postfix) with ESMTPA id 838022000F0; Mon, 3 Jun 2013 23:51:52 -0400 (EDT) Message-ID: <51AD6454.1080709@network-heretics.com> Date: Mon, 03 Jun 2013 23:51:48 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> In-Reply-To: <51AD5ECC.2090607@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 04:48:02 -0000 I find this whole discussion somewhat pedantic, because it's much more important to describe the behavior when a system encounters a string like urn:foo:bar?zot or urn:foo:bar#zot than it is to decide whether the query string or the fragment are (or are not) part of the URN itself. Having said that, I think it will only make things more confusing to change the URN syntax in RFC 2141. And RFC 2141 doesn't allow either # or ? in the NSS. Trying to "liberalize" the syntax will only break things in subtle ways. So don't try to change the definition to make "urn:foo:bar?zot" a URN. Instead, call it something that's consistent with RFC 2141, like "URN with a query string appended", and describe how resolution works on such a contraption. Keith p.s. Also, if 2141's description of URNs is inconsistent with 3986's description, 2141's is almost certainly more correct, and should take precedence. From stpeter@stpeter.im Tue Jun 4 10:00:27 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2A821F9C77 for ; Tue, 4 Jun 2013 10:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1XR7-rC15QC for ; Tue, 4 Jun 2013 10:00:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AA65521F9DC3 for ; Tue, 4 Jun 2013 07:48:49 -0700 (PDT) Received: from sjc-vpn3-831.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5B1F441240; Tue, 4 Jun 2013 09:01:56 -0600 (MDT) Message-ID: <51ADFE4E.4040105@stpeter.im> Date: Tue, 04 Jun 2013 08:48:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51AD6454.1080709@network-heretics.com> In-Reply-To: <51AD6454.1080709@network-heretics.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:00:27 -0000 On 6/3/13 9:51 PM, Keith Moore wrote: > I find this whole discussion somewhat pedantic, One person's pedantry is another person's insistence upon good argumentation. :-) > because it's much more > important to describe the behavior when a system encounters a string like > > urn:foo:bar?zot > > or > > urn:foo:bar#zot > > than it is to decide whether the query string or the fragment are (or > are not) part of the URN itself. I agree that the proponents of changing the URN syntax need to describe how a URN or URI processor (or pre-processor?) would behave when encountering what looks like a URN with a query component or a fragment identifier component. However, there are implications here for registration procedures, as well (3406bis). Currently, someone who registers a namespace identifier (NID) doesn't need to say anything about query components or fragment identifier components within that namesapce. Would that need to change, or would the meaning and handling of those components be covered only by the syntax spec? Or would they be application specific? Could an organization that manages a NID include those components in minted URNs? > Having said that, I think it will only make things more confusing to > change the URN syntax in RFC 2141. And RFC 2141 doesn't allow either # > or ? in the NSS. Trying to "liberalize" the syntax will only break > things in subtle ways. Agreed. > So don't try to change the definition to make "urn:foo:bar?zot" a URN. > Instead, call it something that's consistent with RFC 2141, like "URN > with a query string appended", and describe how resolution works on such > a contraption. That's what I'm recommending, as well. > p.s. Also, if 2141's description of URNs is inconsistent with 3986's > description, 2141's is almost certainly more correct, and should take > precedence. I don't think it is inconsistent with RFC 3986, but I do think it is more tightly scoped (i.e., more strictly limiting the allowable characters in the path component). A more general observation: it is very difficult to call consensus in small, less active working groups. In my opinion, that would lead us to be cautious about making changes to the syntax, semantics, and NID registration procedures without strong evidence of the need for those changes and a clear description of migration issues and the possibility of breakage. So far I have not seen that strong evidence with regard to the query component. The argument for the fragment identifier component might be a bit stronger, but let's have a separate thread about that. Peter -- Peter Saint-Andre https://stpeter.im/ From moore@network-heretics.com Tue Jun 4 10:25:30 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F49821F8551 for ; Tue, 4 Jun 2013 10:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfAI8ayNASGw for ; Tue, 4 Jun 2013 10:25:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id CDB2121F9AE3 for ; Tue, 4 Jun 2013 08:45:19 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 56B0D20FF7; Tue, 4 Jun 2013 11:45:09 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 04 Jun 2013 11:45:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=bbjGMt55H1K6TJumw3MlSj glXIM=; b=kQmE3hAftP0pOIAfOFATc+k7EWzXtxg+Ey3KHOC0082mbysh6hKIoA juB50wlh24/LrFGzLUzNRtVxLoMYtcFaJW+gLs7liG/WHltCU3DFCNSuQqSaG2xF aeEOaMKD4780medgmwKtfnTOzBZjnq+JZ2WaysrH3DZYx6W7cxkro= X-Sasl-enc: 4/Jmp3sfbjuhfEnjIB0EK7P/CUiPbcdvE+/ashEh+np5 1370360709 Received: from [172.20.10.6] (unknown [70.11.183.242]) by mail.messagingengine.com (Postfix) with ESMTPA id 42B5C20005B; Tue, 4 Jun 2013 11:45:06 -0400 (EDT) Message-ID: <51AE0B7E.2020101@network-heretics.com> Date: Tue, 04 Jun 2013 11:45:02 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51AD6454.1080709@network-heretics.com> <51ADFE4E.4040105@stpeter.im> In-Reply-To: <51ADFE4E.4040105@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:25:30 -0000 On 06/04/2013 10:48 AM, Peter Saint-Andre wrote: > On 6/3/13 9:51 PM, Keith Moore wrote: >> I find this whole discussion somewhat pedantic, > One person's pedantry is another person's insistence upon good > argumentation. :-) Of course. But I get the impression that people keep trying to specify resolution behavior in the presence of # or ? by nailing down exactly what is or isn't part of the URN. I think it works better to specify resolution behavior by describing resolution behavior. >> because it's much more >> important to describe the behavior when a system encounters a string like >> >> urn:foo:bar?zot >> >> or >> >> urn:foo:bar#zot >> >> than it is to decide whether the query string or the fragment are (or >> are not) part of the URN itself. > I agree that the proponents of changing the URN syntax need to describe > how a URN or URI processor (or pre-processor?) would behave when > encountering what looks like a URN with a query component or a fragment > identifier component. > > However, there are implications here for registration procedures, as > well (3406bis). Currently, someone who registers a namespace identifier > (NID) doesn't need to say anything about query components or fragment > identifier components within that namesapce. That's ok, because the NSS prohibited by RFC 2141 syntax rules from containing either '#' or '?' without their being percent-encoded. And if they're percent-encoded, the meaning of them is opaque to the client. Also, query strings and fragment IDs are about resource content and presentation of that content, and it doesn't seem generally appropriate for a a URN namespace to constrain the content of resources. That is, URNs and URN resolution are much more broadly applicable if URNs are independent of resource content. > Would that need to change, > or would the meaning and handling of those components be covered only by > the syntax spec? Or would they be application specific? Could an > organization that manages a NID include those components in minted URNs? No, they're prohibited from doing so (and creating the confusion that would inevitably result) by the URN syntax. If we need to make that clearer, by all means let's do so. Keith From stpeter@stpeter.im Tue Jun 4 10:58:26 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6B021F962A for ; Tue, 4 Jun 2013 10:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mfRtMnU3w8G for ; Tue, 4 Jun 2013 10:58:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C753321F91CA for ; Tue, 4 Jun 2013 10:14:33 -0700 (PDT) Received: from sjc-vpn2-502.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 961B341240; Tue, 4 Jun 2013 11:27:41 -0600 (MDT) Message-ID: <51AE2076.6050505@stpeter.im> Date: Tue, 04 Jun 2013 11:14:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51AD6454.1080709@network-heretics.com> <51ADFE4E.4040105@stpeter.im> <51AE0B7E.2020101@network-heretics.com> In-Reply-To: <51AE0B7E.2020101@network-heretics.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:58:26 -0000 On 6/4/13 9:45 AM, Keith Moore wrote: > On 06/04/2013 10:48 AM, Peter Saint-Andre wrote: >> On 6/3/13 9:51 PM, Keith Moore wrote: >>> I find this whole discussion somewhat pedantic, >> One person's pedantry is another person's insistence upon good >> argumentation. :-) > > Of course. But I get the impression that people keep trying to specify > resolution behavior in the presence of # or ? by nailing down exactly > what is or isn't part of the URN. I think it works better to specify > resolution behavior by describing resolution behavior. >>> because it's much more >>> important to describe the behavior when a system encounters a string >>> like >>> >>> urn:foo:bar?zot >>> >>> or >>> >>> urn:foo:bar#zot >>> >>> than it is to decide whether the query string or the fragment are (or >>> are not) part of the URN itself. >> I agree that the proponents of changing the URN syntax need to describe >> how a URN or URI processor (or pre-processor?) would behave when >> encountering what looks like a URN with a query component or a fragment >> identifier component. >> >> However, there are implications here for registration procedures, as >> well (3406bis). Currently, someone who registers a namespace identifier >> (NID) doesn't need to say anything about query components or fragment >> identifier components within that namesapce. > That's ok, because the NSS prohibited by RFC 2141 syntax rules from > containing either '#' or '?' without their being percent-encoded. And > if they're percent-encoded, the meaning of them is opaque to the client. Are you suggesting that the maintainers of a namespace could include the query string or fragment ID in the NSS for URNs in that namespace, with "?" or "#" percent encoded? I'd be curious to hear what the proponents of query strings and fragment identifiers would say about. Given that it doesn't change the syntax from RFC 2141, I'd find that more palatable. > Also, query strings and fragment IDs are about resource content and > presentation of that content, and it doesn't seem generally appropriate > for a a URN namespace to constrain the content of resources. That is, > URNs and URN resolution are much more broadly applicable if URNs are > independent of resource content. Good point. >> Would that need to change, >> or would the meaning and handling of those components be covered only by >> the syntax spec? Or would they be application specific? Could an >> organization that manages a NID include those components in minted URNs? > No, they're prohibited from doing so (and creating the confusion that > would inevitably result) by the URN syntax. If we need to make that > clearer, by all means let's do so. Well, there's the rub: as I understand it, the argument is that we need to change the syntax of URNs to allow query strings and fragment IDs. So "they're prohibited from doing so by the URN syntax" is true in the RFC 2141 world, but folks want to change the syntax in the 2141bis world... Peter -- Peter Saint-Andre https://stpeter.im/ From moore@network-heretics.com Tue Jun 4 11:15:39 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5727021F9B55 for ; Tue, 4 Jun 2013 11:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIrdZvgAnoLW for ; Tue, 4 Jun 2013 11:15:34 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 56CC921F9D2E for ; Tue, 4 Jun 2013 10:30:37 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A5DE9215B9; Tue, 4 Jun 2013 13:30:31 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 04 Jun 2013 13:30:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from :subject:date:to; s=smtpout; bh=UUvYI/arkyn38yUXxszQPaka9ms=; b= h+mSTVPRBNmfiH9z97pqHVe6ZtCP4o2PojCP8l0QJ2Spse2LwadvXw8rn4AM3Z2+ CzwGHkaoshzX5A4FudS1g7w8nQYE6MPWWiTkhRqM2A/IY2lFFnUf2hnCqLTiWwFG VvK0EEApxGT/jCWu9S+YrT+DmHF2EsxjUg6ZoDOUJ0Y= X-Sasl-enc: ABHeAt9bL2ahNEubcqjoRsIxW3YiOdNeoXXa2LR6dzaF 1370367030 Received: from [21.146.65.100] (unknown [66.87.153.100]) by mail.messagingengine.com (Postfix) with ESMTPA id 9921CC80150; Tue, 4 Jun 2013 13:30:30 -0400 (EDT) References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51AD6454.1080709@network-heretics.com> <51ADFE4E.4040105@stpeter.im> <51AE0B7E.2020101@network-heretics.com> <51AE2076.6050505@stpeter.im> In-Reply-To: <51AE2076.6050505@stpeter.im> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B329) From: Keith Moore Date: Tue, 4 Jun 2013 13:30:27 -0400 To: Peter Saint-Andre Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:15:39 -0000 On Jun 4, 2013, at 1:14 PM, Peter Saint-Andre wrote: > On 6/4/13 9:45 AM, Keith Moore wrote: >> On 06/04/2013 10:48 AM, Peter Saint-Andre wrote: >>> On 6/3/13 9:51 PM, Keith Moore wrote: >>>> I find this whole discussion somewhat pedantic, >>> One person's pedantry is another person's insistence upon good >>> argumentation. :-) >>=20 >> Of course. But I get the impression that people keep trying to specify >> resolution behavior in the presence of # or ? by nailing down exactly >> what is or isn't part of the URN. I think it works better to specify >> resolution behavior by describing resolution behavior. >>>> because it's much more >>>> important to describe the behavior when a system encounters a string >>>> like >>>>=20 >>>> urn:foo:bar?zot >>>>=20 >>>> or >>>>=20 >>>> urn:foo:bar#zot >>>>=20 >>>> than it is to decide whether the query string or the fragment are (or >>>> are not) part of the URN itself. >>> I agree that the proponents of changing the URN syntax need to describe >>> how a URN or URI processor (or pre-processor?) would behave when >>> encountering what looks like a URN with a query component or a fragment >>> identifier component. >>>=20 >>> However, there are implications here for registration procedures, as >>> well (3406bis). Currently, someone who registers a namespace identifier >>> (NID) doesn't need to say anything about query components or fragment >>> identifier components within that namesapce. >> That's ok, because the NSS prohibited by RFC 2141 syntax rules from >> containing either '#' or '?' without their being percent-encoded. And >> if they're percent-encoded, the meaning of them is opaque to the client. >=20 > Are you suggesting that the maintainers of a namespace could include the > query string or fragment ID in the NSS for URNs in that namespace, with > "?" or "#" percent encoded? I'd be curious to hear what the proponents > of query strings and fragment identifiers would say about. Given that it > doesn't change the syntax from RFC 2141, I'd find that more palatable. If you percent-encode # or ? in a URN NSS, it loses its special meaning. It= doesn't denote a fragment id or query string. Really you shouldn't use percent encoding in URNs except when you're mapping= some other kind of persistent identifier into URN space. >=20 >> Also, query strings and fragment IDs are about resource content and >> presentation of that content, and it doesn't seem generally appropriate >> for a a URN namespace to constrain the content of resources. That is, >> URNs and URN resolution are much more broadly applicable if URNs are >> independent of resource content. >=20 > Good point. >=20 >>> Would that need to change, >>> or would the meaning and handling of those components be covered only by= >>> the syntax spec? Or would they be application specific? Could an >>> organization that manages a NID include those components in minted URNs?= >> No, they're prohibited from doing so (and creating the confusion that >> would inevitably result) by the URN syntax. If we need to make that >> clearer, by all means let's do so. >=20 > Well, there's the rub: as I understand it, the argument is that we need > to change the syntax of URNs to allow query strings and fragment IDs. If what people want is to be able to refer to fragments of resources identif= ied with URNs or to submit queries to resources named with URNs, then I thin= k the answer is to define what it means to append a fragment I'd or query st= ring to a URN - it means the fragment id or query string are ignored for res= olution purposes, but interpret the fragment I'd or query string with respec= t to the resource after resolution. Also, the URN is a persistent identifie= r but there is no assurance of persistence for the combination of a URN with= a fragment ID or query string. > So > "they're prohibited from doing so by the URN syntax" is true in the RFC > 2141 world, but folks want to change the syntax in the 2141bis world. Those who don't understand URNs are doomed to reimplement them, badly. Keith >=20 From stpeter@stpeter.im Tue Jun 4 11:32:11 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0981121F9B62 for ; Tue, 4 Jun 2013 11:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9tJe9S-8aEy for ; Tue, 4 Jun 2013 11:32:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D9E7821F9B6B for ; Tue, 4 Jun 2013 11:05:49 -0700 (PDT) Received: from sjc-vpn2-502.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2AB344124A; Tue, 4 Jun 2013 12:18:50 -0600 (MDT) Message-ID: <51AE2C74.5040608@stpeter.im> Date: Tue, 04 Jun 2013 12:05:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51AD6454.1080709@network-heretics.com> <51ADFE4E.4040105@stpeter.im> <51AE0B7E.2020101@network-heretics.com> <51AE2076.6050505@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:32:11 -0000 On 6/4/13 11:30 AM, Keith Moore wrote: > On Jun 4, 2013, at 1:14 PM, Peter Saint-Andre > wrote: > >> On 6/4/13 9:45 AM, Keith Moore wrote: >>> On 06/04/2013 10:48 AM, Peter Saint-Andre wrote: >>>> On 6/3/13 9:51 PM, Keith Moore wrote: >>>>> I find this whole discussion somewhat pedantic, >>>> One person's pedantry is another person's insistence upon good >>>> argumentation. :-) >>> >>> Of course. But I get the impression that people keep trying to >>> specify resolution behavior in the presence of # or ? by nailing >>> down exactly what is or isn't part of the URN. I think it works >>> better to specify resolution behavior by describing resolution >>> behavior. >>>>> because it's much more important to describe the behavior >>>>> when a system encounters a string like >>>>> >>>>> urn:foo:bar?zot >>>>> >>>>> or >>>>> >>>>> urn:foo:bar#zot >>>>> >>>>> than it is to decide whether the query string or the fragment >>>>> are (or are not) part of the URN itself. >>>> I agree that the proponents of changing the URN syntax need to >>>> describe how a URN or URI processor (or pre-processor?) would >>>> behave when encountering what looks like a URN with a query >>>> component or a fragment identifier component. >>>> >>>> However, there are implications here for registration >>>> procedures, as well (3406bis). Currently, someone who registers >>>> a namespace identifier (NID) doesn't need to say anything about >>>> query components or fragment identifier components within that >>>> namesapce. >>> That's ok, because the NSS prohibited by RFC 2141 syntax rules >>> from containing either '#' or '?' without their being >>> percent-encoded. And if they're percent-encoded, the meaning of >>> them is opaque to the client. >> >> Are you suggesting that the maintainers of a namespace could >> include the query string or fragment ID in the NSS for URNs in that >> namespace, with "?" or "#" percent encoded? I'd be curious to hear >> what the proponents of query strings and fragment identifiers would >> say about. Given that it doesn't change the syntax from RFC 2141, >> I'd find that more palatable. > > If you percent-encode # or ? in a URN NSS, it loses its special > meaning. It doesn't denote a fragment id or query string. Indeed, which is why I was confused by your suggestion. > Really you shouldn't use percent encoding in URNs except when you're > mapping some other kind of persistent identifier into URN space. That seems reasonable. >>> Also, query strings and fragment IDs are about resource content >>> and presentation of that content, and it doesn't seem generally >>> appropriate for a a URN namespace to constrain the content of >>> resources. That is, URNs and URN resolution are much more >>> broadly applicable if URNs are independent of resource content. >> >> Good point. >> >>>> Would that need to change, or would the meaning and handling of >>>> those components be covered only by the syntax spec? Or would >>>> they be application specific? Could an organization that >>>> manages a NID include those components in minted URNs? >>> No, they're prohibited from doing so (and creating the confusion >>> that would inevitably result) by the URN syntax. If we need to >>> make that clearer, by all means let's do so. >> >> Well, there's the rub: as I understand it, the argument is that we >> need to change the syntax of URNs to allow query strings and >> fragment IDs. > > If what people want is to be able to refer to fragments of resources > identified with URNs or to submit queries to resources named with > URNs, then I think the answer is to define what it means to append a > fragment I'd or query string to a URN - it means the fragment id or > query string are ignored for resolution purposes, but interpret the > fragment I'd or query string with respect to the resource after > resolution. Also, the URN is a persistent identifier but there is no > assurance of persistence for the combination of a URN with a fragment > ID or query string. I fear that the distinction between "a URN" and "a URN with a fragment ID or query string tacked on" will be lost on most people, and that folks will refer to all of the following as URNs: urn:foo:bar urn:foo:bar?zot urn:foo:bar#zot >> So "they're prohibited from doing so by the URN syntax" is true in >> the RFC 2141 world, but folks want to change the syntax in the >> 2141bis world. > > Those who don't understand URNs are doomed to reimplement them, > badly. True of so many things. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Jun 10 21:16:26 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1F321E80B5 for ; Mon, 10 Jun 2013 21:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCwxHiKFBCnm for ; Mon, 10 Jun 2013 21:16:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A422821E80B3 for ; Mon, 10 Jun 2013 21:16:21 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0B1CD4115C; Mon, 10 Jun 2013 22:29:50 -0600 (MDT) Message-ID: <51B6A493.3090801@stpeter.im> Date: Mon, 10 Jun 2013 22:16:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "urn@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 04:16:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While reading RFC 3986 and RFC 3305 recently, I noticed that RFC 2141 contains some archaic language, which 2141bis inherits. Therefore I propose the following changes... OLD A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. The general class of URNs is differentiated from all other URIs through the use of the 'urn' URI scheme. This document defines the canonical syntax for URNs, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. This document obsoletes RFC 2141. NEW A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. Historically, the term "URN" has referred to both URIs under the "urn" scheme and to any other URIs with the properties of a name. This document defines the canonical syntax for URIs under the "urn" scheme, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. This document obsoletes RFC 2141. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRtqSTAAoJEOoGpJErxa2pL5MQALKxkzQPZfPFJxlUDBZSxwX8 ZQOFNUD9J6C2oRYhgxaRfazi8MTMUiZDzRRSAwF2c3kg5VuODUv4hfGNbg+Hi0mJ 0TtORli2UAh7CxtgfOX2QKjxKF10iN6n4OldHy+jnIrPqCJwRl5feVNyi4RQbICK rMWiVIEEnqsXs1rs9x6jndn/Dh7hXOqlXI2V2c/d4gOqTqnOkvlGmk+XH3gv10+T gKdojYeWTAk8C4BqHT8djJX70I9uYEERDocnYt/jWDAIRso6awA+IIfx+1S80IyN lPPZWlbrIhyx9rhG6ukCspKWvKNLs+fZ36HQ56bUVJtquAqbSa7GZx1kNnsh+tKa bvDnwG+rc123f4+wc4ZcYDgCaJXpZqG9BMUmkW8XUHnZ4hZRo9qY8E6AtBx9kGtI TD45L4LJ6dR4MJyDRCzobdBy/nEG0NYPXpRZm/cwldfqPDLL7E9gQokaMn0Wv5qt tME4a3Lck1ClgosT6F/3fiMWj+5GdzlaHngnSFV97aLfwZYAR+SaOm5XUnYm1AQG CLNErfmZg4m1vOTXob8Z7KgfZvV3mVso88RqdC2MCuZMGFdFZ/GXCdLQk5Km/yYM rIBHBbR5u6UoxmnKqiMz8pQxcbRsmViL/dkJS9Gjuj+88Uir0R+wxjsXraaEnMgv KJqyQWb/YL0RSBwJBer3 =sQ4n -----END PGP SIGNATURE----- From paf@frobbit.se Tue Jun 11 02:56:25 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933C221F9433 for ; Tue, 11 Jun 2013 02:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsKmDIX17uEV for ; Tue, 11 Jun 2013 02:56:25 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4D521F938E for ; Tue, 11 Jun 2013 02:56:24 -0700 (PDT) Received: from [192.168.6.80] (unknown [64.132.41.194]) by mail.frobbit.se (Postfix) with ESMTPSA id 51A9A22015; Tue, 11 Jun 2013 11:56:23 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_F03F6621-7C2D-4C7A-9EA8-1643868399FB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <51B6A493.3090801@stpeter.im> Date: Tue, 11 Jun 2013 05:56:22 -0400 Message-Id: References: <51B6A493.3090801@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 09:56:25 -0000 --Apple-Mail=_F03F6621-7C2D-4C7A-9EA8-1643868399FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 jun 2013, at 00:16, Peter Saint-Andre wrote: > NEW > A Uniform Resource Name (URN) is a Uniform Resource Identifier = (URI) > that is intended to serve as a persistent, location-independent > resource identifier. Historically, the term "URN" has referred to > both URIs under the "urn" scheme and to any other URIs with the > properties of a name. Hmm...is "name" specific enough here? Should it not be "...and other = URIs with the properties of such a URI." > This document defines the canonical syntax for > URIs under the "urn" scheme, guidelines for URN namespaces, > requirements for URN presentation and transmission, and methods for > determining URN equivalence. This document obsoletes RFC 2141. Otherwise fine with me. Patrik --Apple-Mail=_F03F6621-7C2D-4C7A-9EA8-1643868399FB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iD8DBQFRtvRGrMabGguI180RAmA3AJ9pmtAA9k+4pZSPJBOs88e43u7nzwCfdWMk hHsjIcQ65OpiuUb4SK40b5o= =8a3B -----END PGP SIGNATURE----- --Apple-Mail=_F03F6621-7C2D-4C7A-9EA8-1643868399FB-- From stpeter@stpeter.im Tue Jun 11 09:29:02 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBA821F89EB for ; Tue, 11 Jun 2013 09:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCTS1PCGgjN3 for ; Tue, 11 Jun 2013 09:28:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E88EC21F8793 for ; Tue, 11 Jun 2013 09:28:57 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 860AB40393; Tue, 11 Jun 2013 10:42:28 -0600 (MDT) Message-ID: <51B75046.2080708@stpeter.im> Date: Tue, 11 Jun 2013 10:28:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <51B6A493.3090801@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 16:29:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/11/13 3:56 AM, Patrik Fältström wrote: > > On 11 jun 2013, at 00:16, Peter Saint-Andre > wrote: > >> NEW A Uniform Resource Name (URN) is a Uniform Resource >> Identifier (URI) that is intended to serve as a persistent, >> location-independent resource identifier. Historically, the >> term "URN" has referred to both URIs under the "urn" scheme and >> to any other URIs with the properties of a name. > > Hmm...is "name" specific enough here? Should it not be "...and > other URIs with the properties of such a URI." I was trying to capture in a few words the following concept from RFC 3986 (Section 1.1.3): The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name. But I didn't succeed. :-) How about this? Historically, the term "URN" has referred to URIs that "remain globally unique and persistent even when the resource ceases to exist or becomes unavailable" [RFC3986], including but not limited to URIs under the "urn" scheme. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRt1BGAAoJEOoGpJErxa2pCC8P/iEy/ZrN65faUCvrXCXhD3jb ITblxovm1+FEc5G4FE60zoB7OYkgOiLD99mtQVOrQP1EyPcUDyyLTJGbxm/XAxgD sYy2yQ4S7SqEBjIrNEFelyFZ6ijToR3OO4wnA+HCjZfk/RH+PXdzFgYA09uRRp92 TN/5dXTwrlDhfepwmLCQR3m7LyZEOISaFp/qWkD41H0UxOvrEL836hyqgCPtfPtw Xr/OKGLQFDR1bz2Tlci9zOJW/qQ9ZbwC+YF4iiKM97SDqxFkaYD++L3c/xegmodB BYEC3d6MCkjZWn+okuOaVkqFuspOPVG+fNAU4lLI9HuYAGPlA7z8vmdpQnd4dtCY T3ZIflxlnqQHCD+4EJlWGU/bUqUnhFaBwLMU7hmnauZt5zTfdRbKpK3pppGQt+yj 5NLhcm+IXA1rn0zeAGrdqwuCDUMmJMNKk3zqv/91ohiL/UsmwHf13sXP0HHaEL+O qCho9dk7p3vz/D4X3LVzEaTdfw3oOGy63Cm84T7lrHRVHU3U/gg/M98PkSDiZrs+ ZdZglKF1s7f9wUKSr5iD+kLVki1+Qpf1GK/YO4+gzqnzjljC5zkQHiY7hkM/8Df5 Yw8tCIIWBb46lAZYuFvLyVBex03uGq/m44Grd/fbGwEVIKE9XKZGrrqttdwnuYls fvxjTx+DKVaSkGUPqt++ =kq4p -----END PGP SIGNATURE----- From paf@frobbit.se Tue Jun 11 11:17:25 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF7021F98C3 for ; Tue, 11 Jun 2013 11:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QABAsV7LHuT5 for ; Tue, 11 Jun 2013 11:17:25 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9DC21F991F for ; Tue, 11 Jun 2013 11:17:25 -0700 (PDT) Received: from [10.96.9.51] (unknown [162.17.222.129]) by mail.frobbit.se (Postfix) with ESMTPSA id 2C0AC2203F; Tue, 11 Jun 2013 20:17:23 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_4339A236-5257-411E-8C01-866CD2FEC9C4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <51B75046.2080708@stpeter.im> Date: Tue, 11 Jun 2013 14:17:20 -0400 Message-Id: References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:17:25 -0000 --Apple-Mail=_4339A236-5257-411E-8C01-866CD2FEC9C4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On 11 jun 2013, at 12:28, Peter Saint-Andre wrote: > But I didn't succeed. :-) How about this? > > Historically, the term "URN" has referred to URIs that "remain > globally unique and persistent even when the resource ceases to > exist or becomes unavailable" [RFC3986], including but not limited > to URIs under the "urn" scheme. I like this better! :-) Patrik --Apple-Mail=_4339A236-5257-411E-8C01-866CD2FEC9C4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iD8DBQFRt2mxrMabGguI180RAh9pAJ9Mbx1kx9NmtzY4lna4PKytRc1RPQCcD96Q fo3yvyoIBKP5idjfbPGI7V0= =1mAW -----END PGP SIGNATURE----- --Apple-Mail=_4339A236-5257-411E-8C01-866CD2FEC9C4-- From L.Svensson@dnb.de Wed Jun 12 09:03:52 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DE411E80E1 for ; Wed, 12 Jun 2013 09:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQINAjNYxoLM for ; Wed, 12 Jun 2013 09:03:45 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 85FFA11E80D9 for ; Wed, 12 Jun 2013 09:03:45 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id D714B92888; Wed, 12 Jun 2013 18:01:00 +0200 (CEST) From: "Svensson, Lars" To: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= , Peter Saint-Andre Thread-Topic: [urn] 2141bis: abstract and intro Thread-Index: AQHOZsDDEvTekjCAOkO4pPTTx927FZkwsMoAgAGOToA= Date: Wed, 12 Jun 2013 16:03:43 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4359143@dnbf-ex1.AD.DDB.DE> References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.69] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 16:03:52 -0000 > On 11 jun 2013, at 12:28, Peter Saint-Andre wrote: >=20 > > But I didn't succeed. :-) How about this? > > > > Historically, the term "URN" has referred to URIs that "remain > > globally unique and persistent even when the resource ceases to > > exist or becomes unavailable" [RFC3986], including but not limited > > to URIs under the "urn" scheme. >=20 > I like this better! :-) >=20 > Patrik Fine with me, too. Lars From L.Svensson@dnb.de Wed Jun 12 11:52:37 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8711E80F7 for ; Wed, 12 Jun 2013 11:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBSWutBFd2IX for ; Wed, 12 Jun 2013 11:52:31 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3378311E80EF for ; Wed, 12 Jun 2013 11:52:30 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 6F3BF92874; Wed, 12 Jun 2013 20:49:46 +0200 (CEST) From: "Svensson, Lars" To: Peter Saint-Andre , Keith Moore Thread-Topic: AW: [urn] Queries in URNs Thread-Index: AQHOYNbk9V535OtrekmreigPc1JatJklggYAgAAPuACAABj/AIAABHWAgAAJ1wCADL1QMA== Date: Wed, 12 Jun 2013 18:52:28 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA4359296@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51AD6454.1080709@network-heretics.com> <51ADFE4E.4040105@stpeter.im> <51AE0B7E.2020101@network-heretics.com> <51AE2076.6050505@stpeter.im> <51AE2C74.5040608@stpeter.im> In-Reply-To: <51AE2C74.5040608@stpeter.im> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.69] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:52:37 -0000 Von: Peter Saint-Andre [mailto:stpeter@stpeter.im] > On 6/4/13 11:30 AM, Keith Moore wrote: > > On Jun 4, 2013, at 1:14 PM, Peter Saint-Andre > > wrote: > > > >> On 6/4/13 9:45 AM, Keith Moore wrote: > >>> On 06/04/2013 10:48 AM, Peter Saint-Andre wrote: > >>>> On 6/3/13 9:51 PM, Keith Moore wrote: [...] > > If you percent-encode # or ? in a URN NSS, it loses its special > > meaning. It doesn't denote a fragment id or query string. >=20 > Indeed, which is why I was confused by your suggestion. >=20 > > Really you shouldn't use percent encoding in URNs except when you're > > mapping some other kind of persistent identifier into URN space. >=20 > That seems reasonable. +1 > >>> Also, query strings and fragment IDs are about resource content and > >>> presentation of that content, and it doesn't seem generally > >>> appropriate for a a URN namespace to constrain the content of > >>> resources. That is, URNs and URN resolution are much more > >>> broadly applicable if URNs are independent of resource content. > >> > >> Good point. +1 > >>>> Would that need to change, or would the meaning and handling of > >>>> those components be covered only by the syntax spec? Or would they > >>>> be application specific? Could an organization that manages a NID > >>>> include those components in minted URNs? > >>> No, they're prohibited from doing so (and creating the confusion > >>> that would inevitably result) by the URN syntax. If we need to > >>> make that clearer, by all means let's do so. > >> > >> Well, there's the rub: as I understand it, the argument is that we > >> need to change the syntax of URNs to allow query strings and fragment > >> IDs. > > > > If what people want is to be able to refer to fragments of resources > > identified with URNs or to submit queries to resources named with > > URNs, then I think the answer is to define what it means to append a > > fragment I'd or query string to a URN - it means the fragment id or > > query string are ignored for resolution purposes, but interpret the > > fragment I'd or query string with respect to the resource after > > resolution. Also, the URN is a persistent identifier but there is no > > assurance of persistence for the combination of a URN with a fragment > > ID or query string. >=20 > I fear that the distinction between "a URN" and "a URN with a fragment ID= or > query string tacked on" will be lost on most people, and that folks will = refer > to all of the following as URNs: >=20 > urn:foo:bar > urn:foo:bar?zot > urn:foo:bar#zot Yes, since this is what people are used to. I would refer to all of the fol= lowing as URLs (or http-URIs): http://example.com/foo http://example.com/foo?bar http://example.com/foo#bar Why can't we specify in 3406bis that query and fragment are ignored for res= olution purposes and that handling of those two are delegated to the resour= ce identified by "that part of the URN that comes before '?' or '#'" (whate= ver you prefer to call it, could "path component" be a name for it?). >=20 > >> So "they're prohibited from doing so by the URN syntax" is true in > >> the RFC 2141 world, but folks want to change the syntax in the > >> 2141bis world. > > > > Those who don't understand URNs are doomed to reimplement them, > badly. >=20 > True of so many things. Yes, but what is it that people don't understand about URNs and where can t= hey learn those things? Lars ***Lesen. H=F6ren. Wissen. Deutsche Nationalbibliothek*** ***Reading. Listening. Understanding. German National Library*** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de From moore@network-heretics.com Wed Jun 12 11:56:56 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAA021F96EF for ; Wed, 12 Jun 2013 11:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN0KDD1FepP3 for ; Wed, 12 Jun 2013 11:56:49 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3851521E808A for ; Wed, 12 Jun 2013 11:56:42 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2F25820A85 for ; Wed, 12 Jun 2013 14:56:41 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 12 Jun 2013 14:56:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=jDR2jKjfrCDx9Paneq/GqA qW2vw=; b=f92VhNZ06x/vr81asvk+aNfClb+P3PH3paoL9zlDsFhnzaf9lX5kJh 5X3hNLDpus3FBTWw5HRGOalCw5orxzz/TeJKbOzTIB4v0HhhQTUzELsI/bwH94/+ I4JsISKgJFwOKyAlWMYv/KBWLM9DVaCm6lL/PCXnrYW0TAQRTFMrA= X-Sasl-enc: qA+T7IsxV7zviq7oMCuNdqSxP36s1r23XUOZassDMNiC 1371063400 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 8946FC00E89; Wed, 12 Jun 2013 14:56:40 -0400 (EDT) Message-ID: <51B8C44F.7010204@network-heretics.com> Date: Wed, 12 Jun 2013 14:56:15 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> In-Reply-To: <51AD5ECC.2090607@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:56:56 -0000 On 06/03/2013 11:28 PM, Peter Saint-Andre wrote: > On 6/3/13 2:55 AM, Svensson, Lars wrote: >> The way I read RFC 3986 puts me more on Barry's side: Every URN is a URI and thus the URN syntax adheres to the generic URI syntax. > But that doesn't follow. > > A URN is a URI with a scheme of 'urn'. Each URI scheme can define its > own syntax, as long as that syntax is consistent with the generic URI > syntax. > >> Sec 3 of RFC 3986 says >> >> URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] > Section 3 of RFC 3986 also has this interesting summary: > > The following are two example URIs and their component parts: > > foo://example.com:8042/over/there?name=ferret#nose > \_/ \______________/\_________/ \_________/ \__/ > | | | | | > scheme authority path query fragment > | _____________________|__ > / \ / \ > urn:example:animal:ferret:nose > > So, according to RFC 3986, a URN is a URI with only a scheme component > and a path component. And that is consistent with the syntax defined in > RFC 2141: RFC 3986 is incorrect in several ways as far as URNs are concerned. It's a mistake to try to reconcile the differences between RFC 3986 and RFC 2141. The URN namespace identifier and namespace specific string are not a "path". Keith From moore@network-heretics.com Wed Jun 12 12:01:48 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2152C21E80D3 for ; Wed, 12 Jun 2013 12:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64IIbQ8V2wA2 for ; Wed, 12 Jun 2013 12:01:27 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34511E80F5 for ; Wed, 12 Jun 2013 12:01:11 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1612220DE0 for ; Wed, 12 Jun 2013 15:01:06 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 12 Jun 2013 15:01:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=zqGgEl70VtNMQMXOxW91KS 36WpI=; b=QRAU3JOgK8jKN288ElNLoefzKD8fwagIlH0bSBMw6c5Dycozkb3GHq /GaiG5A4QHSQSHG62oho1jpRYpsH4Fe/osowsDlLUwpshLqsiLVyyg6IEtEccZ9R A81FpruRNiee4a8/g1ZjjbnNXYOuR9G2OAU7Zaad/4kibSDhcA1C0= X-Sasl-enc: 6FkwYqEa3KIFLs+uzQNdCLNMuGb/4uKE/VatOUgF8Cef 1371063666 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E41A9680265; Wed, 12 Jun 2013 15:01:05 -0400 (EDT) Message-ID: <51B8C558.3040101@network-heretics.com> Date: Wed, 12 Jun 2013 15:00:40 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51AD6454.1080709@network-heretics.com> <51ADFE4E.4040105@stpeter.im> <51AE0B7E.2020101@network-heretics.com> <51AE2076.6050505@stpeter.im> <51AE2C74.5040608@stpeter.im> In-Reply-To: <51AE2C74.5040608@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 19:01:49 -0000 On 06/04/2013 02:05 PM, Peter Saint-Andre wrote: > I fear that the distinction between "a URN" and "a URN with a fragment > ID or query string tacked on" will be lost on most people, and that > folks will refer to all of the following as URNs: > > urn:foo:bar > urn:foo:bar?zot > urn:foo:bar#zot > You're probably right. But there's always a gap in understanding between people who read the specifications and people who don't read the specifications. It's silly to try to write specifications so that people who don't read them will understand them. Though maybe it makes sense to say that any of the following qualify as a URI: URN URN + a fragment id URN + a query string Keith From moore@network-heretics.com Wed Jun 12 12:03:11 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE31C21E80AB for ; Wed, 12 Jun 2013 12:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj3jt2ZkhSe8 for ; Wed, 12 Jun 2013 12:03:06 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7A51121E80DF for ; Wed, 12 Jun 2013 12:02:49 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5734120E5D; Wed, 12 Jun 2013 15:02:47 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 12 Jun 2013 15:02:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=0dXX3fOfUxYbSNRLSSN9km vn97w=; b=DckECHG763HLfBNrlfDb2Dqe+Pijpo0BWnQas4IDtsOGx/lLmTWo32 xKIIGNtNcF5Xath1foZ/AQAlpz4so+LRp3EU3Jiwdz6LqO2WmyD5qthb2ShVEgKn 4sIY8sd3+uYQYJid5KYqKpWxVv066cf8Sz81M7h6ImgQcCpwMBOMg= X-Sasl-enc: rGiSynTzFAyXsnA92lGICYxW5Q3EJnzihfhO42gYRrVk 1371063767 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D06B2680265; Wed, 12 Jun 2013 15:02:46 -0400 (EDT) Message-ID: <51B8C5BD.1000206@network-heretics.com> Date: Wed, 12 Jun 2013 15:02:21 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51B6A493.3090801@stpeter.im> In-Reply-To: <51B6A493.3090801@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 19:03:12 -0000 On 06/11/2013 12:16 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > While reading RFC 3986 and RFC 3305 recently, I noticed that RFC 2141 > contains some archaic language, which 2141bis inherits. Therefore I > propose the following changes... > > OLD > A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) > that is intended to serve as a persistent, location-independent > resource identifier. The general class of URNs is differentiated > from all other URIs through the use of the 'urn' URI scheme. This > document defines the canonical syntax for URNs, guidelines for URN > namespaces, requirements for URN presentation and transmission, and > methods for determining URN equivalence. This document obsoletes RFC > 2141. > > NEW > A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) > that is intended to serve as a persistent, location-independent > resource identifier. Historically, the term "URN" has referred to > both URIs under the "urn" scheme and to any other URIs with the > properties of a name. This document defines the canonical syntax for > URIs under the "urn" scheme, guidelines for URN namespaces, > requirements for URN presentation and transmission, and methods for > determining URN equivalence. This document obsoletes RFC 2141. The proposed new text is incorrect. It is not the case that Historically, the term "URN" has referred to both URIs under the "urn" scheme and to any other URIs with the properties of a name. Keith From moore@network-heretics.com Wed Jun 12 12:04:03 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6B621E80B8 for ; Wed, 12 Jun 2013 12:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ4xSLarWP+K for ; Wed, 12 Jun 2013 12:03:47 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id D54DA21E809D for ; Wed, 12 Jun 2013 12:03:46 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5A48F20B5B; Wed, 12 Jun 2013 15:03:44 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 12 Jun 2013 15:03:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=BaB7AAUiD/tKq1s7z4R8Le HJ93U=; b=Oh+MScEfGLX4sHQyUHb9qiTYBNVmg9llKSE5Ky/qHB/IUfYceQ6yMK Oe0iNbjkUpoJoeHcxsTHnCRK2tffSoHdB6tIjeBDpLENNheNS7QfM56TqRx4oUsZ MsFhxQlOdbAieKFYUKADUiUPAiKtz6MsLa7D3sjwCZQFlJ7LrCCHQ= X-Sasl-enc: JcP/ERlcptLkxdje+wpucy+CQ9BlKGV+VjJo/5bmLOYc 1371063824 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E82DE680273; Wed, 12 Jun 2013 15:03:43 -0400 (EDT) Message-ID: <51B8C5F6.4030909@network-heretics.com> Date: Wed, 12 Jun 2013 15:03:18 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> In-Reply-To: <51B75046.2080708@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 19:04:03 -0000 Stop trying to reconcile the errors in 3986. 3986 contains several lies and misrepresentations. Keith On 06/11/2013 12:28 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 6/11/13 3:56 AM, Patrik Fältström wrote: >> On 11 jun 2013, at 00:16, Peter Saint-Andre >> wrote: >> >>> NEW A Uniform Resource Name (URN) is a Uniform Resource >>> Identifier (URI) that is intended to serve as a persistent, >>> location-independent resource identifier. Historically, the >>> term "URN" has referred to both URIs under the "urn" scheme and >>> to any other URIs with the properties of a name. >> Hmm...is "name" specific enough here? Should it not be "...and >> other URIs with the properties of such a URI." > I was trying to capture in a few words the following concept from RFC > 3986 (Section 1.1.3): > > The term "Uniform Resource Name" > (URN) has been used historically to refer to both URIs under the > "urn" scheme [RFC2141], which are required to remain globally unique > and persistent even when the resource ceases to exist or becomes > unavailable, and to any other URI with the properties of a name. > > But I didn't succeed. :-) How about this? > > Historically, the term "URN" has referred to URIs that "remain > globally unique and persistent even when the resource ceases to > exist or becomes unavailable" [RFC3986], including but not limited > to URIs under the "urn" scheme. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRt1BGAAoJEOoGpJErxa2pCC8P/iEy/ZrN65faUCvrXCXhD3jb > ITblxovm1+FEc5G4FE60zoB7OYkgOiLD99mtQVOrQP1EyPcUDyyLTJGbxm/XAxgD > sYy2yQ4S7SqEBjIrNEFelyFZ6ijToR3OO4wnA+HCjZfk/RH+PXdzFgYA09uRRp92 > TN/5dXTwrlDhfepwmLCQR3m7LyZEOISaFp/qWkD41H0UxOvrEL836hyqgCPtfPtw > Xr/OKGLQFDR1bz2Tlci9zOJW/qQ9ZbwC+YF4iiKM97SDqxFkaYD++L3c/xegmodB > BYEC3d6MCkjZWn+okuOaVkqFuspOPVG+fNAU4lLI9HuYAGPlA7z8vmdpQnd4dtCY > T3ZIflxlnqQHCD+4EJlWGU/bUqUnhFaBwLMU7hmnauZt5zTfdRbKpK3pppGQt+yj > 5NLhcm+IXA1rn0zeAGrdqwuCDUMmJMNKk3zqv/91ohiL/UsmwHf13sXP0HHaEL+O > qCho9dk7p3vz/D4X3LVzEaTdfw3oOGy63Cm84T7lrHRVHU3U/gg/M98PkSDiZrs+ > ZdZglKF1s7f9wUKSr5iD+kLVki1+Qpf1GK/YO4+gzqnzjljC5zkQHiY7hkM/8Df5 > Yw8tCIIWBb46lAZYuFvLyVBex03uGq/m44Grd/fbGwEVIKE9XKZGrrqttdwnuYls > fvxjTx+DKVaSkGUPqt++ > =kq4p > -----END PGP SIGNATURE----- > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From moore@network-heretics.com Wed Jun 12 12:05:33 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E2711E80F9 for ; Wed, 12 Jun 2013 12:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wuh0LCpliF7L for ; Wed, 12 Jun 2013 12:05:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4F33B11E80F7 for ; Wed, 12 Jun 2013 12:05:28 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7730E20CE1; Wed, 12 Jun 2013 15:05:24 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 12 Jun 2013 15:05:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Hov6kzpuYMyhYiPK94nE1U 9V6iA=; b=idiZQEN2slehjvevVO7xNqp15SC3j/ZXhQ4auO0hxQWYv163uxQZIJ iDSPB5nQk+PinKVK4zyIasGImER5VFqi/mzea0NKLNV5pVVbtXIJaULj1HhvriUF 2KC2Hl4/i9Xg9FaoRiv5Konx8RGgsq90/HO2BUk1cjSaADTHaYRig= X-Sasl-enc: wnQMTx2j6OYZpYcDfgmtI6Z1M5MpWva0wkjXg3ScAyS5 1371063924 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 9A9D8C00E94; Wed, 12 Jun 2013 15:05:23 -0400 (EDT) Message-ID: <51B8C65A.7080909@network-heretics.com> Date: Wed, 12 Jun 2013 15:04:58 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 19:05:33 -0000 On 06/11/2013 02:17 PM, Patrik Fältström wrote: > On 11 jun 2013, at 12:28, Peter Saint-Andre wrote: > >> But I didn't succeed. :-) How about this? >> >> Historically, the term "URN" has referred to URIs that "remain >> globally unique and persistent even when the resource ceases to >> exist or becomes unavailable" [RFC3986], including but not limited >> to URIs under the "urn" scheme. > I like this better! :-) > > Patrik I don't like it at all. I don't recall a single instance of the term "URN" being used in this way. It's simply false to say that any URI can be a URN as long as the binding between the name and the resource is persistent. An essential property of URNs is that the persistence is advertised as part of the name. Keith From stpeter@stpeter.im Wed Jun 12 16:03:08 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D3511E8116 for ; Wed, 12 Jun 2013 16:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3tO6ikvKq3F for ; Wed, 12 Jun 2013 16:02:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3C38C11E8112 for ; Wed, 12 Jun 2013 16:02:57 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 961D741101; Wed, 12 Jun 2013 17:16:32 -0600 (MDT) Message-ID: <51B8FE20.7080901@stpeter.im> Date: Wed, 12 Jun 2013 17:02:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C5F6.4030909@network-heretics.com> In-Reply-To: <51B8C5F6.4030909@network-heretics.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 23:03:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/12/13 1:03 PM, Keith Moore wrote: > Stop trying to reconcile the errors in 3986. 3986 contains > several lies and misrepresentations. That is a very strong statement. Unfortunately I don't see the errata posted at http://www.rfc-editor.org/errata_search.php?rfc=3986 to back up your claims. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRuP4fAAoJEOoGpJErxa2pco4QAJ+VMNs5lD+V1pMjUbgD/XL6 By6v24rZDE0SraaoYSSilsUJEqSSZumzKKqnIfBAb9+2Wwp3J1NJ4exQhU6BaMaa rubx97uYQGeY74alQxFfJ/GCU35LWGF2tk/fOot8PClI3cwWSyhvStwHUwo+lnJ2 1AjeGQ/OtlnYiK5IBBrVhh4SZYC2rals6Sgdnh9QlzBvuaVcT6jonr9nDhivJsAi 1WDO6Yv6EtlhXQjcY5zlc9oISBiGGw3WsN6LcyuZy6zBMmORZ1Fw4aKlSAs96wKG NWl2n/er+Lrw+OPJ7HcF+D593MjZGg/UKB+kNGfO+zyjmLWC4oG5Nye4v8MfkOLz vjlcM7IrVILMugd9CM+kva4qMk/2+vN19shkvexg3U+BFg50ArH/q1urFWpegs1I vNHUD21TH6/pRwfbcyHCxDPKVcwNRuKoQK1gKsdCmE6XsxZdHhZ96i6jYiohGwUx E7pVFLdtOzYS9Od13Wspj62W1rlAvTExd9rD81HW8HAaKKOscImVQOIaivv+uxcb rlVIYA1+JssWAruTA8mXPVS52u0LnOy31KGfKY9gTrVDF61Iq+1PEMpYnwIcKCxb kcbE6DsyWjI6Em2HW145+KR3lnDhSs92e2jL4n8GmjaJ295c0zKg5/o2cVrAJxhD ESuWNK/z8t4f9WOLOGwe =1Is+ -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Jun 12 16:04:10 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793D911E811A for ; Wed, 12 Jun 2013 16:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALLP0EN1etJM for ; Wed, 12 Jun 2013 16:04:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDF411E8112 for ; Wed, 12 Jun 2013 16:04:04 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 69C9441101; Wed, 12 Jun 2013 17:17:39 -0600 (MDT) Message-ID: <51B8FE63.3050803@stpeter.im> Date: Wed, 12 Jun 2013 17:04:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C65A.7080909@network-heretics.com> In-Reply-To: <51B8C65A.7080909@network-heretics.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 23:04:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/12/13 1:04 PM, Keith Moore wrote: > On 06/11/2013 02:17 PM, Patrik Fältström wrote: >> On 11 jun 2013, at 12:28, Peter Saint-Andre >> wrote: >> >>> But I didn't succeed. :-) How about this? >>> >>> Historically, the term "URN" has referred to URIs that "remain >>> globally unique and persistent even when the resource ceases >>> to exist or becomes unavailable" [RFC3986], including but not >>> limited to URIs under the "urn" scheme. >> I like this better! :-) >> >> Patrik > > I don't like it at all. I don't recall a single instance of the > term "URN" being used in this way. > > It's simply false to say that any URI can be a URN as long as the > binding between the name and the resource is persistent. An > essential property of URNs is that the persistence is advertised as > part of the name. Clarifying question: do you mean that a URN needs to start with the "urn" scheme? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRuP5iAAoJEOoGpJErxa2p2woQALG2ocxWjXdk2sa3jT61sWBi RVZlefx4v86DKP+DbClXZXe21n4h1uHLs63h8VK+BcV+7bkTB0UuL07Lb8gQaJRO 71EiYwktchNjnbpLecshCvOSO3/qS4byJW++2rO2rxzA+pnr3NVqGfiBPdQDRhms xCOa+axJy3OsZqAdM4lwxW8k/80jgEA0eSFW7UfRNPSNPqbt1QNwyWf2rpwQHn2r R/Pv0PW+q+1GF3JT1ZiQwkrVpu5642B7+AoZketouKhLQaUO/mN0HQpPFZAanqkH bax/h9yP5FEHOGLEUivWCh8hjcmDc6DkwPBtnrhpgWdTfOc7moSRLkq433QoWg/O c+/+f7kNyEGI5k593F2UL8+/124gNQXRynalJdJOPnTL6ALjCedEHtF4GLgMDwVe qeggfhm6I99WrudT240axezE3PFwCjk4zSoezhcEe+Y5HiOCLyCWeB6svwR2zLld 3T91gFFAEIcj4phczudstyMHw39GlIH9WVeBhdFNLdDQNvEuNtqKytAGYXWxsiZr jlXwWNYluQzrXbjC4+2NDy5OfEPXqQUVxirZkYQO9OLJXzm604CidExhJINYzQif 0W3EUMSYlenIBJme3FeAaJ5ndjAaDG0mGFg/px8Wknh1WmP3oPaT76ZsC8Iq/CKz sdA4+icdSigCar9vk94L =pOZc -----END PGP SIGNATURE----- From moore@network-heretics.com Wed Jun 12 19:46:21 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6630511E8108 for ; Wed, 12 Jun 2013 19:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn1OQdCob9tW for ; Wed, 12 Jun 2013 19:46:17 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 17BA211E8106 for ; Wed, 12 Jun 2013 19:46:14 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0084820761; Wed, 12 Jun 2013 22:46:13 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 12 Jun 2013 22:46:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from :subject:date:to; s=smtpout; bh=Xdruf+E+ylsA0J9rQ5zymk9qyzE=; b= YhGWxvZFhvuO8xbFqUmGzYGhWrgaNF1kkPCwCwV6dvKxgPGqVR+ml96jDE0LaVmj quPMsk0ORdgQjlS+oQsud1DfciljSYYRSDkE7MkLfoFek62nsFklLRt0siDTcChN 4/mtOs2wtSmLDNy08RNCzs5DIvX3eXTMZUI3TK0wt34= X-Sasl-enc: 5ePiQTsIqBfU55b5B6sTTqFce8hyqV+Fd2apiXtYzIrc 1371091573 Received: from [21.148.145.34] (unknown [66.87.153.34]) by mail.messagingengine.com (Postfix) with ESMTPA id 86742680206; Wed, 12 Jun 2013 22:46:13 -0400 (EDT) References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C5F6.4030909@network-heretics.com> <51B8FE20.7080901@stpeter.im> In-Reply-To: <51B8FE20.7080901@stpeter.im> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B329) From: Keith Moore Date: Wed, 12 Jun 2013 22:46:11 -0400 To: Peter Saint-Andre Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 02:46:21 -0000 I'm not sure that the errata system even existed until several years after 3= 986 came out. But basically there were a set of people who weren't well pl= ugged into IETF who didn't think that URNs should exist, and the text about U= RNs in 3986 was written to promote that view. So if you wonder why 3986 is i= nconsistent with 2141, that's why. 3986 was written in part to try to under= mine 2141. Keith Sent from my iPhone On Jun 12, 2013, at 7:02 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 6/12/13 1:03 PM, Keith Moore wrote: >> Stop trying to reconcile the errors in 3986. 3986 contains >> several lies and misrepresentations. >=20 > That is a very strong statement. Unfortunately I don't see the errata > posted at http://www.rfc-editor.org/errata_search.php?rfc=3D3986 to back > up your claims. >=20 > Peter >=20 > - --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJRuP4fAAoJEOoGpJErxa2pco4QAJ+VMNs5lD+V1pMjUbgD/XL6 > By6v24rZDE0SraaoYSSilsUJEqSSZumzKKqnIfBAb9+2Wwp3J1NJ4exQhU6BaMaa > rubx97uYQGeY74alQxFfJ/GCU35LWGF2tk/fOot8PClI3cwWSyhvStwHUwo+lnJ2 > 1AjeGQ/OtlnYiK5IBBrVhh4SZYC2rals6Sgdnh9QlzBvuaVcT6jonr9nDhivJsAi > 1WDO6Yv6EtlhXQjcY5zlc9oISBiGGw3WsN6LcyuZy6zBMmORZ1Fw4aKlSAs96wKG > NWl2n/er+Lrw+OPJ7HcF+D593MjZGg/UKB+kNGfO+zyjmLWC4oG5Nye4v8MfkOLz > vjlcM7IrVILMugd9CM+kva4qMk/2+vN19shkvexg3U+BFg50ArH/q1urFWpegs1I > vNHUD21TH6/pRwfbcyHCxDPKVcwNRuKoQK1gKsdCmE6XsxZdHhZ96i6jYiohGwUx > E7pVFLdtOzYS9Od13Wspj62W1rlAvTExd9rD81HW8HAaKKOscImVQOIaivv+uxcb > rlVIYA1+JssWAruTA8mXPVS52u0LnOy31KGfKY9gTrVDF61Iq+1PEMpYnwIcKCxb > kcbE6DsyWjI6Em2HW145+KR3lnDhSs92e2jL4n8GmjaJ295c0zKg5/o2cVrAJxhD > ESuWNK/z8t4f9WOLOGwe > =3D1Is+ > -----END PGP SIGNATURE----- From julian.reschke@gmx.de Thu Jun 13 00:15:46 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C5121F99B6 for ; Thu, 13 Jun 2013 00:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jQdXnb++-t7 for ; Thu, 13 Jun 2013 00:15:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B702221F99D2 for ; Thu, 13 Jun 2013 00:15:39 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Le7py-1Tzd380OxI-00pqa7 for ; Thu, 13 Jun 2013 09:15:38 +0200 Received: (qmail invoked by alias); 13 Jun 2013 07:15:37 -0000 Received: from p54BB3D45.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [84.187.61.69] by mail.gmx.net (mp002) with SMTP; 13 Jun 2013 09:15:37 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19CToAeDNVClu2MdwQAHJMojKd71eqsgQRIhggxjk AB/vGUXEdey4Ij Message-ID: <51B97196.5050709@gmx.de> Date: Thu, 13 Jun 2013 09:15:34 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51B8C44F.7010204@network-heretics.com> In-Reply-To: <51B8C44F.7010204@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 07:15:46 -0000 On 2013-06-12 20:56, Keith Moore wrote: > On 06/03/2013 11:28 PM, Peter Saint-Andre wrote: >> On 6/3/13 2:55 AM, Svensson, Lars wrote: >>> The way I read RFC 3986 puts me more on Barry's side: Every URN is a >>> URI and thus the URN syntax adheres to the generic URI syntax. >> But that doesn't follow. >> >> A URN is a URI with a scheme of 'urn'. Each URI scheme can define its >> own syntax, as long as that syntax is consistent with the generic URI >> syntax. >> >>> Sec 3 of RFC 3986 says >>> >>> URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] >> Section 3 of RFC 3986 also has this interesting summary: >> >> The following are two example URIs and their component parts: >> >> foo://example.com:8042/over/there?name=ferret#nose >> \_/ \______________/\_________/ \_________/ \__/ >> | | | | | >> scheme authority path query fragment >> | _____________________|__ >> / \ / \ >> urn:example:animal:ferret:nose >> >> So, according to RFC 3986, a URN is a URI with only a scheme component >> and a path component. And that is consistent with the syntax defined in >> RFC 2141: > > RFC 3986 is incorrect in several ways as far as URNs are concerned. It's > a mistake to try to reconcile the differences between RFC 3986 and RFC > 2141. > > The URN namespace identifier and namespace specific string are not a > "path". It is, per RFC 3986. If you think this is wrong, go ahead and get the base spec changed. In the meantime I would recommend to *be* consistent, even if the term is confusing. Best regards, Julian From julian.reschke@gmx.de Thu Jun 13 00:18:25 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A8021F99F7 for ; Thu, 13 Jun 2013 00:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNNS86NxRd0f for ; Thu, 13 Jun 2013 00:18:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8C721F99D6 for ; Thu, 13 Jun 2013 00:18:18 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M5Jbd-1UQGiN3Ttn-00zZwS for ; Thu, 13 Jun 2013 09:18:08 +0200 Received: (qmail invoked by alias); 13 Jun 2013 07:18:08 -0000 Received: from p54BB3D45.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [84.187.61.69] by mail.gmx.net (mp020) with SMTP; 13 Jun 2013 09:18:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19t8AdezyNtYICB5WNu8ndm0gnbpIs1zmKdo5VXpZ GLbRE2gJVKd/ZC Message-ID: <51B9722D.3080904@gmx.de> Date: Thu, 13 Jun 2013 09:18:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <51B6A493.3090801@stpeter.im> <51B8C5BD.1000206@network-heretics.com> In-Reply-To: <51B8C5BD.1000206@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 07:18:25 -0000 On 2013-06-12 21:02, Keith Moore wrote: > ... > Historically, the term "URN" has referred to > both URIs under the "urn" scheme and to any other URIs with the > properties of a name. > ... That has been my understanding of "URN" in the past. I understand you disagree, but *my* understanding is based on the specs I read, and that's what they've been saying for a long time. YMMV. Best regards, Julian From john-ietf@jck.com Thu Jun 13 03:00:24 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E98B21F9A25 for ; Thu, 13 Jun 2013 03:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.371 X-Spam-Level: X-Spam-Status: No, score=-101.371 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dstQW6D771L2 for ; Thu, 13 Jun 2013 03:00:18 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2BECF21F9A23 for ; Thu, 13 Jun 2013 03:00:18 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Un4KH-000Bbo-M7 for urn@ietf.org; Thu, 13 Jun 2013 06:00:17 -0400 Date: Thu, 13 Jun 2013 06:00:12 -0400 From: John C Klensin To: urn@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 10:00:24 -0000 --Keith Moore wrote: > I'm not sure that the errata system even existed until several > years after 3986 came out. But basically there were a set of > people who weren't well plugged into IETF who didn't think > that URNs should exist, and the text about URNs in 3986 was > written to promote that view. So if you wonder why 3986 is > inconsistent with 2141, that's why. 3986 was written in part > to try to undermine 2141. Keith, I'm no fan of 3986 (and far less a fan of 3987). I loathe fragment identifiers in particular. But 3986 managed to get approved as a full Internet Standard. There are, as Peter points out, no errata that support your point of view -- even if the errata system didn't exist in its present form then, it does now. More important, there are no published RFCs, or, as far as I can tell, even expired I-Ds, that summarize the history and counterarguments or even provide a "use of URIs as specified in 3986 that were not permitted in 2141 considered harmful" argument. That combination creates an extremely strong presumption that 3987 describes a community consensus, regardless of you taste (or mine) and of our concerns about how that consensus was arrived at. If you don't like it, you know better than most what to do about it: (1) If you believe that there are specific errors, misrepresentations, and/or lies, submit those errata. I'd assume that they would be rejected, but you would at least have a stake in the ground. (2) Write the I-Ds that describe the issues and see if you can get enough traction to either reopen 3986 or at least update it with cautionary notes about conditions under which the controversial features should be used (or not). I suggest the second is more likely to be productive than the first, but YMMD. However, an a priori belief that neither is likely enough to get traction to be worth the writing time would be nearly tantamount to an admission that 3986 really does represent community consensus, however wrong-headed you might consider that consensus. I have similar feelings about hair-splitting about the definition of things that look like URNs (e.g., start in "URN:") but that need to be called something else. The issue there isn't, IMO, about writing specs for those who won't read them. It suggest that the difference between those who will read specs that try to create and enforce precise and subtle terminology and those who won't is that the first group will know that they are confused and the second won't have that knowledge. Let's concentrate on getting a spec that works and that recognizes the reality of the situation we find ourselves in, no matter how uncomfortable we are about that reality, unless it can be shown that the reality is actually harmful to interoperability or the Internet more generally. john From moore@network-heretics.com Thu Jun 13 06:18:40 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8D821F9AB9 for ; Thu, 13 Jun 2013 06:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03oDwseU5oau for ; Thu, 13 Jun 2013 06:18:34 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id D08F321F9ABA for ; Thu, 13 Jun 2013 06:18:34 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DC64C20F88; Thu, 13 Jun 2013 09:18:33 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 13 Jun 2013 09:18:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=6GnAATJKGfKMamGe73mJWx SXH/U=; b=SGzF1ZK8ZzSHITGKIPvpG9a+cI2egTpk6JS1lZd8ngtqJR6iKXMw/u tqGkZGq3PuoSjllUO2JmWXPb4sYXGeJRy+GeHa0BFQRFQLIR2+Fq44gL5RPPe2mY Jm+oOJ6gfTb5+r3eb+MBMoxHSawAWr+2iURSQTmC3ZYhfB3LmCEu4= X-Sasl-enc: jDGhuv+WejU4kAvCAjAq7W/+3+EvxU6MWQaGdSAZOmx/ 1371129513 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F35E680210; Thu, 13 Jun 2013 09:18:33 -0400 (EDT) Message-ID: <51B9C68D.4070206@network-heretics.com> Date: Thu, 13 Jun 2013 09:18:05 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Julian Reschke References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51B8C44F.7010204@network-heretics.com> <51B97196.5050709@gmx.de> In-Reply-To: <51B97196.5050709@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 13:18:40 -0000 On 06/13/2013 03:15 AM, Julian Reschke wrote: > On 2013-06-12 20:56, Keith Moore wrote: >> >> RFC 3986 is incorrect in several ways as far as URNs are concerned. It's >> a mistake to try to reconcile the differences between RFC 3986 and RFC >> 2141. >> >> The URN namespace identifier and namespace specific string are not a >> "path". > > It is, per RFC 3986. If you think this is wrong, go ahead and get the > base spec changed. 2141 is the base spec. We're discussing its possible revision. > > In the meantime I would recommend to *be* consistent, even if the term > is confusing. I'm pointing out that 3986 is inconsistent and confusing. Indeed, several people here are falling victim to that confusion, which is why we need to fix this in 2141bis. Keith From moore@network-heretics.com Thu Jun 13 06:23:58 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A86321F9ABD for ; Thu, 13 Jun 2013 06:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6EQVnLDD8FS for ; Thu, 13 Jun 2013 06:23:52 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id E933721F9A90 for ; Thu, 13 Jun 2013 06:23:43 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2697820F2A; Thu, 13 Jun 2013 09:23:38 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 13 Jun 2013 09:23:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=OEbH8wPsqVEL2jm6LWlEKk 1+nHc=; b=dBN8LjtrO5ypkcJstHFuGm1LJDLppkNFebsuQlpmML/qaBXBxAq6f6 bVHWJeQ4geM6JbVamo/hK9PeB3h+rYt8PM8umX2u0LWo+0Fy254WlvEozk24MceN XASLeasxc2JSMgfqxrGApSlNSc5GQEkLfy2kjvBY060vm72UtwcTc= X-Sasl-enc: WqmHAtXL5JSUCw6y+trT2h9WWrIUUQHwJZdZ6GVpQWIC 1371129817 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 55E69680213; Thu, 13 Jun 2013 09:23:37 -0400 (EDT) Message-ID: <51B9C7BD.8010807@network-heretics.com> Date: Thu, 13 Jun 2013 09:23:09 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C65A.7080909@network-heretics.com> <51B8FE63.3050803@stpeter.im> In-Reply-To: <51B8FE63.3050803@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 13:23:58 -0000 On 06/12/2013 07:04 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 6/12/13 1:04 PM, Keith Moore wrote: >> It's simply false to say that any URI can be a URN as long as the >> binding between the name and the resource is persistent. An >> essential property of URNs is that the persistence is advertised as >> part of the name. > Clarifying question: do you mean that a URN needs to start with the > "urn" scheme? Ok, I have heard name spaces like ISBN or OID that are defined in such a way as to have the persistent binding property, described as URNs. I always took that as a shorthand for "X is an example of something that can be a URN" However, it's misleading in the extreme to say that a random URL that isn't known to be part of such a namespace is, or can be, a URN. Sure, it might happen that that particular URL has a persistent binding to its resource, but you have no way of knowing that. Keith From julian.reschke@gmx.de Thu Jun 13 06:26:43 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608E821F8F33 for ; Thu, 13 Jun 2013 06:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqtWSXViCcMm for ; Thu, 13 Jun 2013 06:26:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2FA21F8F3A for ; Thu, 13 Jun 2013 06:26:11 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MeNJB-1UzRSZ3faR-00QFTO for ; Thu, 13 Jun 2013 15:26:08 +0200 Received: (qmail invoked by alias); 13 Jun 2013 13:26:08 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 13 Jun 2013 15:26:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19BCcpcDx9BvbU6oNznroYPFIsvMCLKok5w3swIKs vH2qjsfa6W5IbR Message-ID: <51B9C86D.8000401@gmx.de> Date: Thu, 13 Jun 2013 15:26:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51B8C44F.7010204@network-heretics.com> <51B97196.5050709@gmx.de> <51B9C68D.4070206@network-heretics.com> In-Reply-To: <51B9C68D.4070206@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 13:26:44 -0000 On 2013-06-13 15:18, Keith Moore wrote: > On 06/13/2013 03:15 AM, Julian Reschke wrote: >> On 2013-06-12 20:56, Keith Moore wrote: >>> >>> RFC 3986 is incorrect in several ways as far as URNs are concerned. It's >>> a mistake to try to reconcile the differences between RFC 3986 and RFC >>> 2141. >>> >>> The URN namespace identifier and namespace specific string are not a >>> "path". >> >> It is, per RFC 3986. If you think this is wrong, go ahead and get the >> base spec changed. > > 2141 is the base spec. We're discussing its possible revision. RFC 3986 is the base spec for URIs. URNs are URIs. As such, RFC 3986 is a base spec we need to be consistent with. >> In the meantime I would recommend to *be* consistent, even if the term >> is confusing. > > I'm pointing out that 3986 is inconsistent and confusing. Indeed, > several people here are falling victim to that confusion, which is why > we need to fix this in 2141bis. If you think RFC 3986 is inconsistent and confusing then, by all means, write a summary and post it to a URI-related mailing list, and/or raise an erratum. Best regards, Julian From moore@network-heretics.com Thu Jun 13 06:33:56 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E48221F9A99 for ; Thu, 13 Jun 2013 06:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPBvayflt-sk for ; Thu, 13 Jun 2013 06:33:51 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7288221F9AB7 for ; Thu, 13 Jun 2013 06:33:39 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9782220AC3; Thu, 13 Jun 2013 09:33:38 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 13 Jun 2013 09:33:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=bhPWC6Th8ltml5JRFgHguT /tmUU=; b=G7A9bFcxPYsng98lsYbzhvRq0KVnexqUvy5oAD61LY+uBJh8vue92a DHEXAdCQl7PUajJ6cRCIJagY4H0cm5mRjHg0xRkD0XZ87t8acbnky6GzLstNC7UO CqoqCnA2kXwlaI+GBDYwErpSjbSQZKfKneofgdlqR5VJm0PvQ8d2s= X-Sasl-enc: /mEokR6RFIUUsG7vhj3FU43IKmRux+ZJ9e4ZowpDnor0 1371130418 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id C7C04C00E83; Thu, 13 Jun 2013 09:33:37 -0400 (EDT) Message-ID: <51B9CA16.5040207@network-heretics.com> Date: Thu, 13 Jun 2013 09:33:10 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Julian Reschke References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51B8C44F.7010204@network-heretics.com> <51B97196.5050709@gmx.de> <51B9C68D.4070206@network-heretics.com> <51B9C86D.8000401@gmx.de> In-Reply-To: <51B9C86D.8000401@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 13:33:56 -0000 On 06/13/2013 09:26 AM, Julian Reschke wrote: > On 2013-06-13 15:18, Keith Moore wrote: >> On 06/13/2013 03:15 AM, Julian Reschke wrote: >>> On 2013-06-12 20:56, Keith Moore wrote: >>>> >>>> RFC 3986 is incorrect in several ways as far as URNs are concerned. >>>> It's >>>> a mistake to try to reconcile the differences between RFC 3986 and RFC >>>> 2141. >>>> >>>> The URN namespace identifier and namespace specific string are not a >>>> "path". >>> >>> It is, per RFC 3986. If you think this is wrong, go ahead and get the >>> base spec changed. >> >> 2141 is the base spec. We're discussing its possible revision. > > RFC 3986 is the base spec for URIs. URNs are URIs. As such, RFC 3986 > is a base spec we need to be consistent with. 3986 is not, and cannot be, a base specification for URIs that existed before it existed. 3986 was written after the vast majority of URIs were defined, and was an attempt to gloss over their differences and make future URIs more consistent with one another. There was nothing wrong with trying to make new URIs more consistent, but 3986's trying to kill the unique properties of URNs was inappropriate and extremely harmful. >>> In the meantime I would recommend to *be* consistent, even if the term >>> is confusing. >> >> I'm pointing out that 3986 is inconsistent and confusing. Indeed, >> several people here are falling victim to that confusion, which is why >> we need to fix this in 2141bis. > > If you think RFC 3986 is inconsistent and confusing then, by all > means, write a summary and post it to a URI-related mailing list, > and/or raise an erratum. Here's the summary: 3986 is simply incorrect as far as URNs are concerned, and should not be believed. Refer instead to 2141. Producing a 2141bis RFC that set the story straight is a better way to fix things than posting an erratum. Keith From julian.reschke@gmx.de Thu Jun 13 06:40:47 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0E821F9A94 for ; Thu, 13 Jun 2013 06:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSZp0vd8ZjTr for ; Thu, 13 Jun 2013 06:40:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8654421F9A77 for ; Thu, 13 Jun 2013 06:40:38 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LxrcA-1UJH731WZ2-015IzT for ; Thu, 13 Jun 2013 15:40:37 +0200 Received: (qmail invoked by alias); 13 Jun 2013 13:40:37 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 13 Jun 2013 15:40:37 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18S4EE/eLES6CX75+d/NjExDZyNTic0NCxEVi45Dt kzm/Lr779QolFc Message-ID: <51B9CBD0.8020700@gmx.de> Date: Thu, 13 Jun 2013 15:40:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51B8C44F.7010204@network-heretics.com> <51B97196.5050709@gmx.de> <51B9C68D.4070206@network-heretics.com> <51B9C86D.8000401@gmx.de> <51B9CA16.5040207@network-heretics.com> In-Reply-To: <51B9CA16.5040207@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 13:40:49 -0000 On 2013-06-13 15:33, Keith Moore wrote: > On 06/13/2013 09:26 AM, Julian Reschke wrote: >> On 2013-06-13 15:18, Keith Moore wrote: >>> On 06/13/2013 03:15 AM, Julian Reschke wrote: >>>> On 2013-06-12 20:56, Keith Moore wrote: >>>>> >>>>> RFC 3986 is incorrect in several ways as far as URNs are concerned. >>>>> It's >>>>> a mistake to try to reconcile the differences between RFC 3986 and RFC >>>>> 2141. >>>>> >>>>> The URN namespace identifier and namespace specific string are not a >>>>> "path". >>>> >>>> It is, per RFC 3986. If you think this is wrong, go ahead and get the >>>> base spec changed. >>> >>> 2141 is the base spec. We're discussing its possible revision. >> >> RFC 3986 is the base spec for URIs. URNs are URIs. As such, RFC 3986 >> is a base spec we need to be consistent with. > > 3986 is not, and cannot be, a base specification for URIs that existed > before it existed. 3986 was written after the vast majority of URIs It is in my understanding of the term "base specification". It's a full internet standard, and obsoletes previous documents on that topic. > were defined, and was an attempt to gloss over their differences and > make future URIs more consistent with one another. There was nothing > wrong with trying to make new URIs more consistent, but 3986's trying to > kill the unique properties of URNs was inappropriate and extremely harmful. Please elaborate on how exactly it is "trying to kill unique properties". >>>> In the meantime I would recommend to *be* consistent, even if the term >>>> is confusing. >>> >>> I'm pointing out that 3986 is inconsistent and confusing. Indeed, >>> several people here are falling victim to that confusion, which is why >>> we need to fix this in 2141bis. >> >> If you think RFC 3986 is inconsistent and confusing then, by all >> means, write a summary and post it to a URI-related mailing list, >> and/or raise an erratum. > > Here's the summary: 3986 is simply incorrect as far as URNs are > concerned, and should not be believed. Refer instead to 2141. That summary is too terse to be of any use; sorry. > Producing a 2141bis RFC that set the story straight is a better way to > fix things than posting an erratum. If a URN is supposed to be a URI, we need to deal with whatever discrepancies there are. If it's not, we need to clarify *that* (but I have to say that would kill all of my interest in this subject). Best regards, Julian From moore@network-heretics.com Thu Jun 13 07:33:42 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F5921F99B9 for ; Thu, 13 Jun 2013 07:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYoNFQWgmPCN for ; Thu, 13 Jun 2013 07:33:25 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 63A4721F9A7A for ; Thu, 13 Jun 2013 07:33:20 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7BACC2111D; Thu, 13 Jun 2013 10:33:11 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 13 Jun 2013 10:33:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=20W7GccbEPGgY/lt+Ct30D A7Uo4=; b=TtafU5qd6H7E9f+jJK509ebIp1Lt/+QdyCboUAr3PS+CsaksJclhyY L0WUdkj38BEVtguqH6BdI4GmHGE+0iPlUiQ8Fu7e9ZgzZpokurg3Z1flvUU4TmFJ 2IpMEA3Zpa1ztSBE2ANyEMStyH3j3RnCjZ6VUDTyHcZRbtjKz2hw8= X-Sasl-enc: TLhfqtimTRYY00oBon66ULsx8EOWcswNPZ+eoiZH5Swj 1371133990 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A6E0680269; Thu, 13 Jun 2013 10:33:10 -0400 (EDT) Message-ID: <51B9D808.5010301@network-heretics.com> Date: Thu, 13 Jun 2013 10:32:40 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Julian Reschke References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51B8C44F.7010204@network-heretics.com> <51B97196.5050709@gmx.de> <51B9C68D.4070206@network-heretics.com> <51B9C86D.8000401@gmx.de> <51B9CA16.5040207@network-heretics.com> <51B9CBD0.8020700@gmx.de> In-Reply-To: <51B9CBD0.8020700@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 14:33:42 -0000 On 06/13/2013 09:40 AM, Julian Reschke wrote: > On 2013-06-13 15:33, Keith Moore wrote: >> On 06/13/2013 09:26 AM, Julian Reschke wrote: >>> On 2013-06-13 15:18, Keith Moore wrote: >>>> On 06/13/2013 03:15 AM, Julian Reschke wrote: >>>>> On 2013-06-12 20:56, Keith Moore wrote: >>>>>> >>>>>> RFC 3986 is incorrect in several ways as far as URNs are concerned. >>>>>> It's >>>>>> a mistake to try to reconcile the differences between RFC 3986 >>>>>> and RFC >>>>>> 2141. >>>>>> >>>>>> The URN namespace identifier and namespace specific string are not a >>>>>> "path". >>>>> >>>>> It is, per RFC 3986. If you think this is wrong, go ahead and get the >>>>> base spec changed. >>>> >>>> 2141 is the base spec. We're discussing its possible revision. >>> >>> RFC 3986 is the base spec for URIs. URNs are URIs. As such, RFC 3986 >>> is a base spec we need to be consistent with. >> >> 3986 is not, and cannot be, a base specification for URIs that existed >> before it existed. 3986 was written after the vast majority of URIs > > It is in my understanding of the term "base specification". It's a > full internet standard, and obsoletes previous documents on that topic. But 2141 was and still is the specific definition of URNs. The specific definition is more likely to be correct than a document that was written later, which was more broadly scoped, and which tries to gloss over differences between several existing types of URI. Aside: I've said for about 15 years now that it's a mistake to try to document existing practice and document recommended practice in the same RFC. 3986 is a very good example of that kind of mistake. The reason it's a mistake is twofold: First, unless they're narrowly focused on describing existing practice, RFC authors (being engineers) can't resist the temptation to try to fix things, and when they do so they're no longer describing existing practice. Second, mixing existing practice and recommended practice in the same document is often confusing to readers, especially when the document has a label (like Informational or Standard) that is taken to apply to the whole document. > >> were defined, and was an attempt to gloss over their differences and >> make future URIs more consistent with one another. There was nothing >> wrong with trying to make new URIs more consistent, but 3986's trying to >> kill the unique properties of URNs was inappropriate and extremely >> harmful. > > Please elaborate on how exactly it is "trying to kill unique properties". The fundamental idea of a URN: label is that it's useful to advertise in the name, that the name has a persistent binding with the resource that it names. For example, it makes it possible for a browser or other client to attempt to resolve the name in a manner that is suitable for names with such persistence, (i.e. URN resolution), and perhaps without having specific knowledge of the particular namespace. The presence of the URN: label also advertises that property to document authors needing to refer to another document, who can choose (or not) to prefer a URN over another kind of URI when a stable reference is desired. 3986 is essentially saying that there's nothing unique about a URN; any URI can have that property. That's really not true, or it's true only in such narrow and unusual cases as to be meaningless. Any URL that contains a DNS name can't guarantee persistence because there's nothing to keep that DNS name from being reassigned - and we've seen this happen numerous times in the history of the web. In practice, this doesn't just make the original URLs defined inaccessible, it actually has the effect of changing the meanings of some of those URLs. Now if you try really hard you approximate persistent URLs. You can, for instance, pick DNS names that nobody else is likely to want, so that there will be no disputes over them. You can create a new DNS name every day that reflects the date that URLs based on that DNS name were minted. You can set up an endowment for your DNS zone that will provide money to renew its registration in perpetuity, and provide a war chest for the legal defense of that name should someone challenge it on trademark or other grounds. You can build HTTP servers that always return redirects (and are designed to be efficient at doing so), and build interfaces for resource owners to allow them to change those redirects as the resources are updated or move to other locations. There's nothing wrong with trying to do these things, and they have the advantage of working with existing clients. But for better or worse, the URN approach was, and is, a different approach. 3986's efforts to confuse the two was a disservice to everybody. >>> >>> If you think RFC 3986 is inconsistent and confusing then, by all >>> means, write a summary and post it to a URI-related mailing list, >>> and/or raise an erratum. >> >> Here's the summary: 3986 is simply incorrect as far as URNs are >> concerned, and should not be believed. Refer instead to 2141. > > That summary is too terse to be of any use; sorry. The whole point of a summary is to be terse. Now I recognize that there's a tendency for people to disbelieve something that is stated so succinctly. I could, I suppose, write up an Internet-Draft with the title "RFC 3986 is incorrect about URNs" (or maybe something less provocative, but you get the idea), include all of the required boilerplate and document sections (Security Considerations would be interesting), and ask for it to be published as an RFC. Either or both of two results seem likely. One result is that the IESG would refer discussion of this I-D right back to this working group. The other likely result is that said I-D would generate a firestorm of controversy that would move discussion of URNs outside of this working group, attracting input from a large number of parties with no investment into and little understanding of the issues, and making it even harder for this working group to conduct its business. > >> Producing a 2141bis RFC that set the story straight is a better way to >> fix things than posting an erratum. > > If a URN is supposed to be a URI, we need to deal with whatever > discrepancies there are. If it's not, we need to clarify *that* (but I > have to say that would kill all of my interest in this subject). I think it's more useful to say that a URN is a kind of URI than to say that it isn't a kind of URI. Clearly we intended for URNs to be usable in some of the contexts in which URLs were usable, we need a name for those contexts, and URI is as good a name as any. And we do of course need to deal with the discrepancies in 2141bis. I'm just describing the nature of those discrepancies. Keith From stpeter@stpeter.im Thu Jun 13 08:08:44 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9A121F99C3 for ; Thu, 13 Jun 2013 08:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwe3urHRKnBd for ; Thu, 13 Jun 2013 08:08:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2A721F91B7 for ; Thu, 13 Jun 2013 08:08:37 -0700 (PDT) Received: from sjc-vpn2-607.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6322C4127A; Thu, 13 Jun 2013 09:22:13 -0600 (MDT) Message-ID: <51B9E070.2030105@stpeter.im> Date: Thu, 13 Jun 2013 09:08:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C65A.7080909@network-heretics.com> <51B8FE63.3050803@stpeter.im> <51B9C7BD.8010807@network-heretics.com> In-Reply-To: <51B9C7BD.8010807@network-heretics.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:08:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/13/13 7:23 AM, Keith Moore wrote: > On 06/12/2013 07:04 PM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 6/12/13 1:04 PM, Keith Moore wrote: >>> It's simply false to say that any URI can be a URN as long as >>> the binding between the name and the resource is persistent. >>> An essential property of URNs is that the persistence is >>> advertised as part of the name. >> Clarifying question: do you mean that a URN needs to start with >> the "urn" scheme? > > Ok, I have heard name spaces like ISBN or OID that are defined in > such a way as to have the persistent binding property, described as > URNs. I always took that as a shorthand for "X is an example of > something that can be a URN" > > However, it's misleading in the extreme to say that a random URL > that isn't known to be part of such a namespace is, or can be, a > URN. Sure, it might happen that that particular URL has a > persistent binding to its resource, but you have no way of knowing > that. This is not the URIbis WG, it's the URNbis WG. And I note that RFC 3986 is a full standard. What is the proposed text change for 2141bis? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRueBwAAoJEOoGpJErxa2pvRgP/j+Yb4byP3Y0kWNL4mLzfejZ Hogl8PDJdqqDB+6SWihynuqjtevn7/Tp/GQcc1OAALO/NFRmIZO/AuIgDwmF1na7 I7AoNjx/T1Xm6F7PTB1WmaLGh7ve5DOdZTjO15RDlK+tcbDCXO5oTTGozsqw+zXT eEkJRFtlM87lBbkrTyO7jb3ZvW628UhhKrJ7xfv/REnc6IzjVy0pui7MOqQKxe9J HP3zWaWc6a2pgk7P0z8jviMScWNC6pv097W+LNvNB7y7mM/ETUafFtNjYj4LCdcu C6XW4IfaIMa4YlY36dLr3Muq6utwQo+vXQRTSdUKibwLAeE7JgN70NGy3ClD7u75 /tzLraaag5jlJsCUaR/1BCXdQp2nOkTxedp/Z6G1mVIYE/VzgWEiTL1NNye0mI8z HhTrcSrDSclEN0gJszaMu5/wMsFgjLJiUqvxv++qa053jfRnmvENr7s//c+RnooM 5z2ECI24coue4kDZ0avpW6lqcWwpKJ6Qrt6WbwB2KwbTLWVGF4ZEriJdi5JVfMXT IxJivSA2GADHQy5J7H+D0s3WR57RhZ2uge+AcpwBj4lL9qTWA31Q6pPBLAGdzAmb e3kTy05R8nuj5oHQbRP7c74kKqk+QL0nLs1et2NEueB6iMWL+uVFWiNRDKqUP473 AfgTGLlsCSLGK37UkpiC =PTKe -----END PGP SIGNATURE----- From moore@network-heretics.com Thu Jun 13 08:17:25 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B151721F9997 for ; Thu, 13 Jun 2013 08:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9HdHjb0lasr for ; Thu, 13 Jun 2013 08:17:20 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9987F21F9992 for ; Thu, 13 Jun 2013 08:17:20 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A1034205A7; Thu, 13 Jun 2013 11:17:19 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 13 Jun 2013 11:17:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Uq3OEq3hzqt6v6YFQ+SSKb JEm7c=; b=qVETVGcho7JT2BhxOdLuxGHFNsDUA/RLfu+vSfU2qpPVG1DrKcAaIC B0IQaoBDGB5lv46ok8g6KJj6yDObyYY0q/GzGpHMddTitLr/z+5iTQGwO57IRjVG 46gLMVxhq9FHs1oNR3C4v7AVz0V73XzKkAJqBkNzXMSRiIWpqE37M= X-Sasl-enc: +zgc0mmeBj+dIKO5L7WSyKcrAZsB+sjXKW1o+SUNBfbm 1371136639 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id C9952C00E80; Thu, 13 Jun 2013 11:17:18 -0400 (EDT) Message-ID: <51B9E262.7050905@network-heretics.com> Date: Thu, 13 Jun 2013 11:16:50 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C65A.7080909@network-heretics.com> <51B8FE63.3050803@stpeter.im> <51B9C7BD.8010807@network-heretics.com> <51B9E070.2030105@stpeter.im> In-Reply-To: <51B9E070.2030105@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:17:25 -0000 On 06/13/2013 11:08 AM, Peter Saint-Andre wrote: > - > This is not the URIbis WG, it's the URNbis WG. And I note that RFC > 3986 is a full standard. Full standards can be updated by publication of new standards-track RFCs. > What is the proposed text change for 2141bis? > The following text is correct as written and needs no changes: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. The general class of URNs is differentiated from all other URIs through the use of the 'urn' URI scheme. This document defines the canonical syntax for URNs, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. This document obsoletes RFC 2141. From moore@network-heretics.com Thu Jun 13 08:28:49 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A2B21F99CD for ; Thu, 13 Jun 2013 08:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHzZoljPE+Sj for ; Thu, 13 Jun 2013 08:28:41 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2380621F9974 for ; Thu, 13 Jun 2013 08:28:40 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 328CD20887; Thu, 13 Jun 2013 11:28:32 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 13 Jun 2013 11:28:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=wNs9ERQ6c4LLQ7/kC3gB8E il7cc=; b=WT1Pu/PJ8ilVLkz/7qhgh2QV58hgI/gWPq0SpCls1AA8FTNW16kv8b Mbk4bdB0eZctVkUMnzA2rXkUjNvKUbDX8zk7D6rCYx/ZlOC/6OQ5I5mYLwmsaKsy 5sfU4/SGDMPfEsJa1KDHhvCYZd37J4TWLHfFP7wi1jRUn4Ny6WXMY= X-Sasl-enc: TimuS34+X6Xe1gpGv1tYhovUYshetTZgH3AqlR0RYttd 1371137311 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 510DDC00E7F; Thu, 13 Jun 2013 11:28:31 -0400 (EDT) Message-ID: <51B9E502.6090503@network-heretics.com> Date: Thu, 13 Jun 2013 11:28:02 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C65A.7080909@network-heretics.com> <51B8FE63.3050803@stpeter.im> <51B9C7BD.8010807@network-heretics.com> <51B9E070.2030105@stpeter.im> <51B9E262.7050905@network-heretics.com> In-Reply-To: <51B9E262.7050905@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:28:49 -0000 On 06/13/2013 11:16 AM, Keith Moore wrote: > On 06/13/2013 11:08 AM, Peter Saint-Andre wrote: >> - >> This is not the URIbis WG, it's the URNbis WG. And I note that RFC >> 3986 is a full standard. > > Full standards can be updated by publication of new standards-track RFCs. > >> What is the proposed text change for 2141bis? >> > The following text is correct as written and needs no changes: > > A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) > that is intended to serve as a persistent, location-independent > resource identifier. The general class of URNs is differentiated > from all other URIs through the use of the 'urn' URI scheme. This > document defines the canonical syntax for URNs, guidelines for URN > namespaces, requirements for URN presentation and transmission, and > methods for determining URN equivalence. This document obsoletes RFC > 2141. > If I were trying to be diplomatic, I might add something like: Historically, the term "URN" has sometimes also been used to describe URIs that were intended to be persistently associated with the resources with which they were initially associated, and this has unfortunately caused some confusion. This document describes specifically URIs that begin with the prefix "urn:" and which have the characteristics described in this document. Also, the use of the term URN within this document refers specifically to the specific kind of persistent identifiers described herein. Other kinds of persistent identifiers are out of scope for this document. Keith From stpeter@stpeter.im Thu Jun 13 08:38:09 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E043621F9A27 for ; Thu, 13 Jun 2013 08:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaZ-XZV6ekBs for ; Thu, 13 Jun 2013 08:38:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7249221F9A2B for ; Thu, 13 Jun 2013 08:38:05 -0700 (PDT) Received: from sjc-vpn2-607.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C44294127A; Thu, 13 Jun 2013 09:51:39 -0600 (MDT) Message-ID: <51B9E757.5080900@stpeter.im> Date: Thu, 13 Jun 2013 09:37:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C65A.7080909@network-heretics.com> <51B8FE63.3050803@stpeter.im> <51B9C7BD.8010807@network-heretics.com> <51B9E070.2030105@stpeter.im> <51B9E262.7050905@network-heretics.com> <51B9E502.6090503@network-heretics.com> In-Reply-To: <51B9E502.6090503@network-heretics.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:38:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/13/13 9:28 AM, Keith Moore wrote: > On 06/13/2013 11:16 AM, Keith Moore wrote: >> On 06/13/2013 11:08 AM, Peter Saint-Andre wrote: >>> - This is not the URIbis WG, it's the URNbis WG. And I note >>> that RFC 3986 is a full standard. >> >> Full standards can be updated by publication of new >> standards-track RFCs. >> >>> What is the proposed text change for 2141bis? >>> >> The following text is correct as written and needs no changes: >> >> A Uniform Resource Name (URN) is a Uniform Resource Identifier >> (URI) that is intended to serve as a persistent, >> location-independent resource identifier. The general class of >> URNs is differentiated from all other URIs through the use of the >> 'urn' URI scheme. This document defines the canonical syntax for >> URNs, guidelines for URN namespaces, requirements for URN >> presentation and transmission, and methods for determining URN >> equivalence. This document obsoletes RFC 2141. >> > > If I were trying to be diplomatic, I might add something like: > > Historically, the term "URN" has sometimes also been used to > describe URIs that were intended to be persistently associated with > the resources with which they were initially associated, and this > has unfortunately caused some confusion. This document describes > specifically URIs that begin with the prefix "urn:" and which have > the characteristics described in this document. Also, the use of > the term URN within this document refers specifically to the > specific kind of persistent identifiers described herein. Other > kinds of persistent identifiers are out of scope for this > document. I certainly agree with that last sentence! So it might be safer to remove generalizations about what is and is not a URN, and claim only that we are defining the syntax for the "urn" scheme. I propose the following text (one could quibble over the word "typically" in the second sentence, but it probably provides some wiggle room). 1. Introduction A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) [RFC3986] that is intended to serve as a persistent, location- independent resource identifier. Typically, such URIs are minted under the "urn" scheme. This document defines the canonical syntax for URIs under the "urn" scheme, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. URNs were originally defined in [RFC2141]. The goal of this document is to specify URNs with the smallest reasonable set of changes from the original definition while ensuring consistency with the updated specification of URIs in [RFC3986]. If approved, this document will obsolete RFC 2141. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJRuedXAAoJEOoGpJErxa2pOkYP8wYuYK/injcR+69+uobEVOTB 7sBwtF3MdfB7Wh/FV8FKli8R2nhvG/qgjjRaV2BH5tkuMKLrK79CbntKwECbtIZ4 f9J4hOhbugUKrkW6dg9ZKF+Gp9tuGuGBt5H0935TlCAh9HMSWRmuXu16MgxCjW58 +Ktl/SpPBzYUVhyp9PJTaiW1HhWxHM4DehUn7jRGkJ+nETOpO9QgQOlfxYTvjk7v SAQnT++kHRBkXRU9ZPTYtpA3zp5belmOJxUas3VFqEl7jVeiAg+O7wFUVYkYjzpo Zsh1jD+mBvSCY9fF1weCNSG/VQfEboOCW4MIls1al+x9c+6cZFaBk8w5duwaal6c +eCxjVm3bNhD6aGT83CsQYUbDX8ksS/hlf2244PUHpEcz+uZOdZ+i4dE7tooxJ/U w0dBQE+s/GC3H//ET4CJ4pcbwxcbPXm5Amd6+c+j0Pw27nR/4qWP8XVxhlhtvZIL nP5VqXumVGBC6J66NUPVL/yNXd8A2pBRWkuYvPkJwygAzBPFvG9dROUJUebBbjEC 3ZSVD/c1wowL4snDBkQz6xRA3if52REBS1y9+ImFysQRBqp6ptPivNWHrVR+WquO YDpAnQccEHsIy5pBQvA1/Q0A9b/GMIuvYXnuqYA/kAS94zIw/3hW+OXdFc78wqHs OXnPMfPSXazp3vTW4fI= =y7o3 -----END PGP SIGNATURE----- From moore@network-heretics.com Thu Jun 13 08:46:42 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C281721F97E6 for ; Thu, 13 Jun 2013 08:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAQERzyhiUaN for ; Thu, 13 Jun 2013 08:46:37 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9377721F8C4B for ; Thu, 13 Jun 2013 08:46:37 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 38D0820B19; Thu, 13 Jun 2013 11:46:37 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 13 Jun 2013 11:46:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=AbWP4BgfPE1WsrZySr10pg bfbro=; b=f3BMnLxYiYEvfykth/bo5RjEjvpcZzt+Hp4FQ54yfC5I/e52TXOyEg iCuT/pm8Z4M/peZ59MPBAmJHCcjDoTAMQFXu5L5WJRn8pGrd9VcRIDbvNLetldE9 0BeNKrL/E4ER9cC9vmJ12P79PdVem1QjkyuRbDCNVSgsDUMT8uUc4= X-Sasl-enc: hsEF19hezOk8wVndUi7dFGkVQ0k79k/czVYfxJ2IWr0I 1371138396 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 31227680230; Thu, 13 Jun 2013 11:46:36 -0400 (EDT) Message-ID: <51B9E93F.6070204@network-heretics.com> Date: Thu, 13 Jun 2013 11:46:07 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C65A.7080909@network-heretics.com> <51B8FE63.3050803@stpeter.im> <51B9C7BD.8010807@network-heretics.com> <51B9E070.2030105@stpeter.im> <51B9E262.7050905@network-heretics.com> <51B9E502.6090503@network-heretics.com> <51B9E757.5080900@stpeter.im> In-Reply-To: <51B9E757.5080900@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:46:42 -0000 On 06/13/2013 11:37 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 6/13/13 9:28 AM, Keith Moore wrote: >> On 06/13/2013 11:16 AM, Keith Moore wrote: >>> On 06/13/2013 11:08 AM, Peter Saint-Andre wrote: >>>> - This is not the URIbis WG, it's the URNbis WG. And I note >>>> that RFC 3986 is a full standard. >>> Full standards can be updated by publication of new >>> standards-track RFCs. >>> >>>> What is the proposed text change for 2141bis? >>>> >>> The following text is correct as written and needs no changes: >>> >>> A Uniform Resource Name (URN) is a Uniform Resource Identifier >>> (URI) that is intended to serve as a persistent, >>> location-independent resource identifier. The general class of >>> URNs is differentiated from all other URIs through the use of the >>> 'urn' URI scheme. This document defines the canonical syntax for >>> URNs, guidelines for URN namespaces, requirements for URN >>> presentation and transmission, and methods for determining URN >>> equivalence. This document obsoletes RFC 2141. >>> >> If I were trying to be diplomatic, I might add something like: >> >> Historically, the term "URN" has sometimes also been used to >> describe URIs that were intended to be persistently associated with >> the resources with which they were initially associated, and this >> has unfortunately caused some confusion. This document describes >> specifically URIs that begin with the prefix "urn:" and which have >> the characteristics described in this document. Also, the use of >> the term URN within this document refers specifically to the >> specific kind of persistent identifiers described herein. Other >> kinds of persistent identifiers are out of scope for this >> document. > I certainly agree with that last sentence! > > So it might be safer to remove generalizations about what is and is > not a URN, and claim only that we are defining the syntax for the > "urn" scheme. I propose the following text (one could quibble over the > word "typically" in the second sentence, but it probably provides some > wiggle room). > > 1. Introduction > > A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) > [RFC3986] that is intended to serve as a persistent, location- > independent resource identifier. Typically, such URIs are minted > under the "urn" scheme. This document defines the canonical syntax > for URIs under the "urn" scheme, guidelines for URN namespaces, > requirements for URN presentation and transmission, and methods for > determining URN equivalence. > > URNs were originally defined in [RFC2141]. The goal of this document > is to specify URNs with the smallest reasonable set of changes from > the original definition while ensuring consistency with the updated > specification of URIs in [RFC3986]. If approved, this document will > obsolete RFC 2141. > > I really don't like the wiggle room implied by the word "typically". I want to try to reduce the confusion resulting from the variant uses of the term URN and in particular the way 3986 uses the term. Keith From stpeter@stpeter.im Thu Jun 13 08:49:30 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B351421F9A2B for ; Thu, 13 Jun 2013 08:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-mBB6x7MtZ8 for ; Thu, 13 Jun 2013 08:49:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 39E9121F994C for ; Thu, 13 Jun 2013 08:49:26 -0700 (PDT) Received: from sjc-vpn2-607.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BC6294127A; Thu, 13 Jun 2013 10:03:03 -0600 (MDT) Message-ID: <51B9EA03.30103@stpeter.im> Date: Thu, 13 Jun 2013 09:49:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C65A.7080909@network-heretics.com> <51B8FE63.3050803@stpeter.im> <51B9C7BD.8010807@network-heretics.com> <51B9E070.2030105@stpeter.im> <51B9E262.7050905@network-heretics.com> <51B9E502.6090503@network-heretics.com> <51B9E757.5080900@stpeter.im> <51B9E93F.6070204@network-heretics.com> In-Reply-To: <51B9E93F.6070204@network-heretics.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:49:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/13/13 9:46 AM, Keith Moore wrote: > On 06/13/2013 11:37 AM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 6/13/13 9:28 AM, Keith Moore wrote: >>> On 06/13/2013 11:16 AM, Keith Moore wrote: >>>> On 06/13/2013 11:08 AM, Peter Saint-Andre wrote: >>>>> - This is not the URIbis WG, it's the URNbis WG. And I >>>>> note that RFC 3986 is a full standard. >>>> Full standards can be updated by publication of new >>>> standards-track RFCs. >>>> >>>>> What is the proposed text change for 2141bis? >>>>> >>>> The following text is correct as written and needs no >>>> changes: >>>> >>>> A Uniform Resource Name (URN) is a Uniform Resource >>>> Identifier (URI) that is intended to serve as a persistent, >>>> location-independent resource identifier. The general class >>>> of URNs is differentiated from all other URIs through the use >>>> of the 'urn' URI scheme. This document defines the canonical >>>> syntax for URNs, guidelines for URN namespaces, requirements >>>> for URN presentation and transmission, and methods for >>>> determining URN equivalence. This document obsoletes RFC >>>> 2141. >>>> >>> If I were trying to be diplomatic, I might add something like: >>> >>> Historically, the term "URN" has sometimes also been used to >>> describe URIs that were intended to be persistently associated >>> with the resources with which they were initially associated, >>> and this has unfortunately caused some confusion. This >>> document describes specifically URIs that begin with the prefix >>> "urn:" and which have the characteristics described in this >>> document. Also, the use of the term URN within this document >>> refers specifically to the specific kind of persistent >>> identifiers described herein. Other kinds of persistent >>> identifiers are out of scope for this document. >> I certainly agree with that last sentence! >> >> So it might be safer to remove generalizations about what is and >> is not a URN, and claim only that we are defining the syntax for >> the "urn" scheme. I propose the following text (one could quibble >> over the word "typically" in the second sentence, but it probably >> provides some wiggle room). >> >> 1. Introduction >> >> A Uniform Resource Name (URN) is a Uniform Resource Identifier >> (URI) [RFC3986] that is intended to serve as a persistent, >> location- independent resource identifier. Typically, such URIs >> are minted under the "urn" scheme. This document defines the >> canonical syntax for URIs under the "urn" scheme, guidelines for >> URN namespaces, requirements for URN presentation and >> transmission, and methods for determining URN equivalence. >> >> URNs were originally defined in [RFC2141]. The goal of this >> document is to specify URNs with the smallest reasonable set of >> changes from the original definition while ensuring consistency >> with the updated specification of URIs in [RFC3986]. If >> approved, this document will obsolete RFC 2141. >> >> > > I really don't like the wiggle room implied by the word > "typically". I want to try to reduce the confusion resulting from > the variant uses of the term URN and in particular the way 3986 > uses the term. So you want 2141bis to state that URNs are all and only URIs under the "urn" scheme. Correct? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRueoDAAoJEOoGpJErxa2pacIP/3s7Gkieg8m88AGT0cCsTnj6 X6BYxHiRwz/2JGwU5/2gzqaAvnGrrtavLEGqHXeaZfOG+3DdJfSidhd5pJ1n8uPI eKDZRbkqBl/rrE34xK7WwEYLhP3njSY0aPS6OogD9Lvg0orJn/mzGrxdGjGfmvj1 PEfV55iReAgTbiemHfCB+ccYizepbICsQT2iH45HehZu0pZGjfsNszAzp6kbKS+Z c1avk2lKvy9ZJGEzHZtCcXRkxEbbV+E2HexTkc5pTYQ+lkgdem9IZdBgvgIOJ/DD 1ZZIXfejvK/c+5cY0ByPSth6I8l5j++y/JW4LgOqq2IyFLeHU0QRap2akxnAiJ1M wiUtWQzRti5veJIMhIa8bQrr9X56TwNixeMb4t+vIqc4ZRDwHTkHUUWpHDqKjQEa jmrSyD5ePFVY6KbUPjbtyLXbohMRbnd+LCnTYMjGGbEt6fu2UxCICv/Y9CO5Mb71 2gPxy8E3wPzqtzEX9ySdAdIa1TgWiHOFcvWZnpVJI1B2AnV/LHdRDd+J8ezR3NdJ AkGr3dIcuwMMFzQuRc2ScR3YPuwfbZBIgX6kh34RGhamzbrp0wKOxEVAXORTaDtK NWOosozDaULo/azEOQHvlaGyJJqQaduTcv5bwDb3oGJjukP1hGUWqvB5UliquBRi K9+VvQufuBDemRd1xBOl =qT3f -----END PGP SIGNATURE----- From moore@network-heretics.com Thu Jun 13 09:30:03 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17F421F90EF for ; Thu, 13 Jun 2013 09:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXXOGH2mQSBx for ; Thu, 13 Jun 2013 09:29:51 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE1421F9957 for ; Thu, 13 Jun 2013 09:29:31 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 59202210E2; Thu, 13 Jun 2013 12:29:26 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 13 Jun 2013 12:29:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from :subject:date:to; s=smtpout; bh=kpnvBOAM4XEnx/XL7j2ZEV8SCEI=; b= cyY8WLAGl/qtROluaVu1+Dh520MvsOewS1H17VKuRULZMKPQpTIGEwwWMlneZwMv s356KlajLvYCcKmXyTpXQNwPMbdEOPtsawNviVkoUbR94POOcqOZOiZkbTSi9r5A lfE7xH+yspqnoF3WkM7GkMf/GEMpTnHtoWoy5r4G5oI= X-Sasl-enc: Ih7XSCRl57PQv7IuvKrxk1BKniNbwMrXuH56BUgj9EXF 1371140955 Received: from [21.148.145.34] (unknown [66.87.153.34]) by mail.messagingengine.com (Postfix) with ESMTPA id 42D6868028E; Thu, 13 Jun 2013 12:29:15 -0400 (EDT) References: <51B6A493.3090801@stpeter.im> <51B75046.2080708@stpeter.im> <51B8C65A.7080909@network-heretics.com> <51B8FE63.3050803@stpeter.im> <51B9C7BD.8010807@network-heretics.com> <51B9E070.2030105@stpeter.im> <51B9E262.7050905@network-heretics.com> <51B9E502.6090503@network-heretics.com> <51B9E757.5080900@stpeter.im> <51B9E93F.6070204@network-heretics.com> <51B9EA03.30103@stpeter.im> In-Reply-To: <51B9EA03.30103@stpeter.im> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B329) From: Keith Moore Date: Thu, 13 Jun 2013 12:29:11 -0400 To: Peter Saint-Andre Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 16:30:04 -0000 Sent from my iPhone On Jun 13, 2013, at 11:49 AM, Peter Saint-Andre wrote: >=20 > So you want 2141bis to state that URNs are all and only URIs under the > "urn" scheme. Correct? I want 2141bis to encourage use of the term URN to mean only URIs that begin= with "urn:" and follow the rules in 2141 / 2141bis. Confusion over the us= e of the term URN has degraded the utility of URNs, and to the extent possib= le, I'd like for 2141bis to reverse that tendency. Now, having said that, I do recognize that for 2141bis to flat out state tha= t 3986 is wrong could be counterproductive. I think a better approach woul= d be for 2141bis to make a clearer justification for having a type of URI th= at is distinguished as being persistent (I.e. a URN) than was made in 2141. = Much of the criticism of URNs has come from people who did not understand t= hem. To some extent this might be because the original documents were not a= s clear as they might have been. But now we have an opportunity to fix that= . Keith From john-ietf@jck.com Thu Jun 13 14:17:57 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAF821F9B11 for ; Thu, 13 Jun 2013 14:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.985 X-Spam-Level: X-Spam-Status: No, score=-101.985 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggms9ODTh6VR for ; Thu, 13 Jun 2013 14:17:52 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3ED21F9A39 for ; Thu, 13 Jun 2013 14:17:52 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UnEtz-000CPt-MZ for urn@ietf.org; Thu, 13 Jun 2013 17:17:51 -0400 Date: Thu, 13 Jun 2013 17:17:46 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 21:17:58 -0000 Hi. I've been trying to watch this WG from a safe distance and not comment in order to avoid repeating arguments from the original URN design discussions or the more recent 2141 versus 3986 one. But a review of the correspondence of the last several weeks has convinced me that a few important principles are getting lost in the shuffle. So, some thoughts. This note may turn out to be long. If so consider the text length averaged over the last few years. Summary: While I believe that fragment identifiers on URNs are architecturally difficult and unattractive and queries even more so, I think prohibiting them is a mistake on interoperability grounds. I think we can also extrapolate from other things that have gone on with the Internet to conclude, however sadly, that having the IETF try to either hold up or deny registration of URN namespaces on aesthetic grounds or to assert authority over namespaces for which it has no real knowledge will only lead to the use of unregistered namespace names and the consequent interoperability problems. Details: In an ideal world, URNs would point to atomic objects. If chapters of books are the relevant atomic objects, then URNs should identify those chapters with some sort of aggregate URN associated with the book and reflecting the chapter URNs, rather than having a book URN and fragments or queries to identify the chapters. But I think we need to recognize that some people, libraries, and publishers (perhaps many of them) won't do it that way regardless of what we say. The fact that URNs are particular kinds of URIs and that fragments and queries are part of the basic URI syntax definition doesn't help -- if URNs were a completely different sort of creature, these things would be easier to prevent. Queries are even worse than fragments for the reasons discussed by others on the list. In the world in which we actually live, the effect of prohibiting either fragments and queries given that people think they need them will be to have them go ahead and use them --locally or even in national or other profiles-- without telling us (especially if we express no sympathy for their needs). That is pretty much a guarantee of non-interoperability. I think interoperability, rather than notions of architectural purity (including the ones I've described above) had best be our goal. So, recommendations: (1) Incorporate provisions for fragments and queries in the syntax document, allowing them to be authorized on a per-namespace basis. (2) Strongly advise against namespaces allowing them except in exceptional circumstances where the need is significant and they can be tightly defined. (3) Alter the registration template for new URN namespaces so that it explicitly permits a template to allow fragments and/or queries, pointing to the advice above to discourage their use. (4) Modify the registration procedure for URN namespaces to follow the general model established for media types and allow three types of registration instead of the current two. The third would be available to "recognized standards bodies". That term is deliberately undefined for media types and should be undefined here but the intent would be to allow (at least) bodies who have reasonable and open procedures for developing stable standards-grade specifications and who are responsible for the definition of underlying identification systems to take lead responsibility for the related URNs. The general procedure would be that they would expose their proposed definitions to the IETF for review and comment (so that we can provide advice on syntax and usage) but the final decision to ask IANA to register an appropriate namespace without a "urn-" prefix would lie with them. The usual "stable spec" rules would apply -- they could either provide IANA with a pointer to a specification they published, ask for RFC publication of their spec as an Informational document, or both. And then we move on. Suggestions and comments welcome. More arguments for purity are really not unless one is willing to to argue that non-interoperability, or producing standards we know will be ignored, are good things or at least ok. best, john I think URNs ought to point to From sm@resistor.net Thu Jun 13 15:06:51 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA89121F9B7E for ; Thu, 13 Jun 2013 15:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwOuonA8uxEz for ; Thu, 13 Jun 2013 15:06:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB82421F9B7D for ; Thu, 13 Jun 2013 15:06:50 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r5DM6kx1009377; Thu, 13 Jun 2013 15:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371161210; bh=bS8ASmxSdZ6hDW/yGtTa9O4QIJR81WeADnTOPYO/WmE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TULI5HM5SITkiCpmgce2xnN3EL9D59evFm7/Ebjh3OHlJrFWrNyDn/34VqY2uW/ah TkBpc1+Nav0cMZrWNKsUcCaIKxZJxrD9UIgzSU8WM3wdV3AEH+g283CgJhiYHm7U94 pKcsnL7bA9FXU2WgON7BvbVwY34DClU6b9rY05dc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1371161210; i=@resistor.net; bh=bS8ASmxSdZ6hDW/yGtTa9O4QIJR81WeADnTOPYO/WmE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MgF/7TX7fyqw10UJa+usSr0hnVp0zvDER7jcgKQMVaS4rcH9bCVMEY8qaPUjpn21i JBMsMap06uLy+yDZWLjCVjB6TxYd5YXoiTmaIoFtdBs22Ezd7MGYE7Kdxvjjr4zmnU rmcWtRh0xg/nVEL0f2fwEOuMwGY02jjsnQAlUKoQ= Message-Id: <6.2.5.6.2.20130613145442.0bea54a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Jun 2013 15:00:58 -0700 To: Keith Moore From: SM In-Reply-To: <51B9D808.5010301@network-heretics.com> References: <24637769D123E644A105A0AF0E1F92EFA4343843@dnbf-ex1.AD.DDB.DE> <51A631CD.2010302@network-heretics.com> <51A63A9D.8070503@stpeter.im> <24637769D123E644A105A0AF0E1F92EFA4347195@dnbf-ex1.AD.DDB.DE> <51AD5ECC.2090607@stpeter.im> <51B8C44F.7010204@network-heretics.com> <51B97196.5050709@gmx.de> <51B9C68D.4070206@network-heretics.com> <51B9C86D.8000401@gmx.de> <51B9CA16.5040207@network-heretics.com> <51B9CBD0.8020700@gmx.de> <51B9D808.5010301@network-heretics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: urn@ietf.org Subject: Re: [urn] Queries in URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 22:06:51 -0000 Hi Keith, At 07:32 13-06-2013, Keith Moore wrote: >Now I recognize that there's a tendency for people to disbelieve >something that is stated so succinctly. I could, I suppose, write >up an Internet-Draft with the title "RFC 3986 is incorrect about >URNs" (or maybe something less provocative, but you get the idea), >include all of the required boilerplate and document sections >(Security Considerations would be interesting), and ask for it to be >published as an RFC. >Either or both of two results seem likely. One result is that the >IESG would refer discussion of this I-D right back to this working group. >The other likely result is that said I-D would generate a firestorm >of controversy that would move discussion of URNs outside of this >working group, attracting input from a large number of parties with >no investment into and little understanding of the issues, and >making it even harder for this working group to conduct its business. You have been watching too many IETF movies. :-) As mentioned above the I-D would have to be discussed in here. It's unlikely that the positions would change. Regards, -sm From moore@network-heretics.com Thu Jun 13 18:59:59 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530AB21F8887 for ; Thu, 13 Jun 2013 18:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz-6uh3i-lKX for ; Thu, 13 Jun 2013 18:59:54 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id F1D3821F8C40 for ; Thu, 13 Jun 2013 18:59:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BB32520740; Thu, 13 Jun 2013 21:59:52 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 13 Jun 2013 21:59:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=wIYPU+UiLfQiO/SHhDYj/H JpJzs=; b=RPYDklkaPy4bgIig5oI6PQBptfqhi4WW4FpltlA9H/m/PKgFqvYP5d GipnjNQOw3f6QwqCQDWpTc5daYUYggKLQ6PSME2TX66PNTPGmyieXUFef6bMxv7E RMZ8cLZfkhrcgM+MOLapIj0AWebx95zGzUaLaiaiPRHW1eMpMJlIw= X-Sasl-enc: aVU+KvTg/wKZ+xt5QsEqHge0sXiMiwladsrcN/IpKLgX 1371175192 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id ECCE2680230; Thu, 13 Jun 2013 21:59:51 -0400 (EDT) Message-ID: <51BA78FB.1000808@network-heretics.com> Date: Thu, 13 Jun 2013 21:59:23 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John C Klensin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] 2141bis: abstract and intro X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 01:59:59 -0000 On 06/13/2013 06:00 AM, John C Klensin wrote: > Keith, > > I'm no fan of 3986 (and far less a fan of 3987). I loathe > fragment identifiers in particular. But 3986 managed to get > approved as a full Internet Standard. There are, as Peter > points out, no errata that support your point of view -- even if > the errata system didn't exist in its present form then, it does > now. More important, there are no published RFCs, or, as far as > I can tell, even expired I-Ds, that summarize the history and > counterarguments or even provide a "use of URIs as specified in > 3986 that were not permitted in 2141 considered harmful" > argument. > > That combination creates an extremely strong presumption that > 3987 describes a community consensus, regardless of you taste > (or mine) and of our concerns about how that consensus was > arrived at. I understand how people arrive at those presumptions. > If you don't like it, you know better than most what to do about > it: > > (1) If you believe that there are specific errors, > misrepresentations, and/or lies, submit those errata. I'd > assume that they would be rejected, but you would at least have > a stake in the ground. > > (2) Write the I-Ds that describe the issues and see if you can > get enough traction to either reopen 3986 or at least update it > with cautionary notes about conditions under which the > controversial features should be used (or not). At least for the moment, I'm not trying to fix 3986. I recognize that that's an uphill battle. I'm just trying to provide context to this group' s discussion of 2141bis. (For that matter, even if I were to be able to get 3986 updated, it probably wouldn't happen in time to affect the output of this group. And I think it's more worthwhile to fix 2141bis than to fight that battle at the moment.) > Let's concentrate on getting a spec that works and that > recognizes the reality of the situation we find ourselves in, no > matter how uncomfortable we are about that reality, unless it > can be shown that the reality is actually harmful to > interoperability or the Internet more generally. In reality, I generally find that things work better when people aren't laboring under illusions such as those documented in 3986. Keith From moore@network-heretics.com Thu Jun 13 19:07:13 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F2721F9B1D for ; Thu, 13 Jun 2013 19:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNAemVt+at-3 for ; Thu, 13 Jun 2013 19:07:07 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id A7A3121F9B12 for ; Thu, 13 Jun 2013 19:07:05 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1D88020B7A; Thu, 13 Jun 2013 22:07:05 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 13 Jun 2013 22:07:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=ee1EYfAadjDvsItvfZn3Nt Wrghw=; b=k8FnZDgqN+yy2LkC61YE91ToCdR2hcISizVve138V4Kh2zMcQW8Ezv 163P771nv6kiUZs0Kzx3VSwdPfcLsNycuLaOGWEpUwmQdmKBU+lhMMlYigiMewMX qrTrQLdtVNGFvFPrUz+i8gDS5RXNKYF/NGRmdcB4bmVDeArjzwLqc= X-Sasl-enc: BhB6rViId3q6861Eo9/Uk9z8+4fiCeQJSUuI3qFHVlQV 1371175624 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 58F74C00E80; Thu, 13 Jun 2013 22:07:04 -0400 (EDT) Message-ID: <51BA7AAB.4080301@network-heretics.com> Date: Thu, 13 Jun 2013 22:06:35 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John C Klensin References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> In-Reply-To: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 02:07:13 -0000 On 06/13/2013 05:17 PM, John C Klensin wrote: > (1) Incorporate provisions for fragments and queries in the > syntax document, allowing them to be authorized on a > per-namespace basis. I don't think this makes any sense. A fragment is a property of the resource. A query is a property of the resource and the protocol used to access the resource. Neither is, or should be, a property of the resource name. Also, making fragments/queries a per-namespace attribute increases complexity for no gain. > (2) Strongly advise against namespaces allowing them except in > exceptional circumstances where the need is significant and they > can be tightly defined. URN namespaces already cannot allow them. 2141 syntax forbids either ? or # appearing in namespaces. To change that would be an incompatible change to the protocol. Nor is there any need to change the syntax. > Suggestions and comments welcome. More arguments for purity are > really not unless one is willing to to argue that > non-interoperability, or producing standards we know will be > ignored, are good things or at least ok. This isn't an argument about purity. Making fragments and query strings properties of URN namespaces will harm interoperability rather than help it. Keith From stpeter@stpeter.im Thu Jun 13 21:28:04 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5517B21E8050 for ; Thu, 13 Jun 2013 21:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtK8vL-IlluK for ; Thu, 13 Jun 2013 21:28:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E2AF611E80D5 for ; Thu, 13 Jun 2013 21:27:59 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DC9354127A; Thu, 13 Jun 2013 22:41:37 -0600 (MDT) Message-ID: <51BA9BCA.7080407@stpeter.im> Date: Thu, 13 Jun 2013 22:27:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> In-Reply-To: <51BA7AAB.4080301@network-heretics.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 04:28:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/13/13 8:06 PM, Keith Moore wrote: > On 06/13/2013 05:17 PM, John C Klensin wrote: >> (1) Incorporate provisions for fragments and queries in the >> syntax document, allowing them to be authorized on a >> per-namespace basis. > > I don't think this makes any sense. A fragment is a property of > the resource. A query is a property of the resource and the > protocol used to access the resource. Neither is, or should be, a > property of the resource name. > > Also, making fragments/queries a per-namespace attribute increases > complexity for no gain. > >> (2) Strongly advise against namespaces allowing them except in >> exceptional circumstances where the need is significant and they >> can be tightly defined. > > URN namespaces already cannot allow them. 2141 syntax forbids > either ? or # appearing in namespaces. To change that would be an > incompatible change to the protocol. Nor is there any need to > change the syntax. > >> Suggestions and comments welcome. More arguments for purity are >> really not unless one is willing to to argue that >> non-interoperability, or producing standards we know will be >> ignored, are good things or at least ok. > > This isn't an argument about purity. Making fragments and query > strings properties of URN namespaces will harm interoperability > rather than help it. However, we know that people are going to use at least fragments and probably queries. I would really prefer to avoid the URN equivalent of LEIRI vs. IRI. John's argument makes sense to me. I don't have to like the conclusions he's reached to understand that consensus here might require compromise. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRupvKAAoJEOoGpJErxa2pCqQP+wS6H7fnqJIG/slfvsSnifnm olCZ3J99y14TWYpYE4MGxsfDsq6osewZFKVhfbt5F108iRuzWw0p1sfeLFeH6g4w w780m7HZnOn/pofTH340hDMlHvPMYgkry+GJRnvT5J1TkppNFuakmnNar81HJ2GQ qWoZPeC69fudFU9dSg22TO04+Ahv7vmO6mM+EVbM34/yMNizgb58tvU22A0latBv nY5xPF63UBpa539Kq2d2H/4lWW7RjMzxh8QYbB2Lvq8ywDAhJScdKpNqEZI1i+PD FanEqQ/8mOHP0IFDfFjLyPHQwUnynnube8FNlv5v3HwqXQOj8rvlqNYPWktdvJLn ER4S++0wBggGScxAC96HQfkpIEYm5ecc15PXY1EN8XsFCiJuJiFcRmO2NyIcdwHE P1umSZ//UM+U1ypNpN/p/DTFk4FWGnbehYepeYLyMJwWj3CTw4dS2Q4QV4kxeJpV p2Fy/g6VjBryqISakrKnkjvIfW1UbYSbAhbJq2yj/fDijz7bKsH9sMS0bi75p3WS kdOd4DuOoci3+KUK2Gg9dxpJqP7tCcXoXl26iCANJIZbXnDAH36niXIuaY3DvLXG AwYUVmQnmW9PzIHlpQu4v+olSFp4azGiQdmPGfCZMvYI2/NDIlNy7Q7Gzm1mCv33 copgS/n3uxi1K+OOGrHU =+w0g -----END PGP SIGNATURE----- From moore@network-heretics.com Thu Jun 13 21:57:59 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EBC21F9B93 for ; Thu, 13 Jun 2013 21:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Laq9u+prRS4 for ; Thu, 13 Jun 2013 21:57:54 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 39B6121F9B96 for ; Thu, 13 Jun 2013 21:57:54 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8A6AC20B49; Fri, 14 Jun 2013 00:57:53 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 14 Jun 2013 00:57:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Znku4hWZTWNopGmYgQsGez gWXNs=; b=j7PZ0qPEZee4aqfCmmYqxuEtzNv5phJjnRy7fW865//5GH50juKmYV XEhW2KlePMqZXXEBm9sofz5iHmqY2lrLc/yeGvSxqEjw6y8+vNV16G1BcCEbrWGG mSGv9D0wCRX55cw/H0c/4vj0fCz0zwoIdklY8lhaMl2k89CcJKdcA= X-Sasl-enc: HNVd7lS0PkBv3w1d+j3VDkIi/612/BqbLm+MRshuY8ho 1371185873 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BC342C00E80; Fri, 14 Jun 2013 00:57:52 -0400 (EDT) Message-ID: <51BAA2B2.5010602@network-heretics.com> Date: Fri, 14 Jun 2013 00:57:22 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> In-Reply-To: <51BA9BCA.7080407@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 04:57:59 -0000 On 06/14/2013 12:27 AM, Peter Saint-Andre wrote: > However, we know that people are going to use at least fragments and > probably queries. > > I would really prefer to avoid the URN equivalent of LEIRI vs. IRI. > > John's argument makes sense to me. I don't have to like the > conclusions he's reached to understand that consensus here might > require compromise. It's the wrong kind of compromise. It will destroy the carefully designed functionality of URNs. I'm currently writing up an Internet Draft that will explain the problem, and my proposal, in more detail. Keith From john-ietf@jck.com Fri Jun 14 09:50:00 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DD121F90E4 for ; Fri, 14 Jun 2013 09:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFbGkHFrQXlI for ; Fri, 14 Jun 2013 09:49:54 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B298921F8C1A for ; Fri, 14 Jun 2013 09:49:40 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UnXBs-000EIF-Tz; Fri, 14 Jun 2013 12:49:33 -0400 Date: Fri, 14 Jun 2013 12:49:27 -0400 From: John C Klensin To: Keith Moore , Peter Saint-Andre Message-ID: In-Reply-To: <51BAA2B2.5010602@network-heretics.com> References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@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 Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:50:00 -0000 --On Friday, June 14, 2013 00:57 -0400 Keith Moore wrote: > On 06/14/2013 12:27 AM, Peter Saint-Andre wrote: >> However, we know that people are going to use at least >> fragments and probably queries. >> >> I would really prefer to avoid the URN equivalent of LEIRI >> vs. IRI. >> >> John's argument makes sense to me. I don't have to like the >> conclusions he's reached to understand that consensus here >> might require compromise. Peter, let me stress that I don't like those conclusions at all. They make me uncomfortable and more than a little bit sad. But I think they constitute facing reality and dealing with it. Unless, as I said, we like a model in which we effectively encourage people to ignore what our specifications say and create non-interoperable situations. > It's the wrong kind of compromise. It will destroy the > carefully designed functionality of URNs. Keith, I don't really see it as a compromise as much as facing reality and trying to make the best of a bad situation. In hindsight, 2141 (or some supplemental document) should have been a lot more clear about aspects of that "carefully designed functionality" and the motivation for it. It (or something else) should have anticipated that there would be requirements that didn't conform to the URN model, specified what to do to satisfy them with some non-URN mechanism, and motivated that and the reasons to keep that mechanism and URNs clearly separated. The motivations should have been clear enough that people and implementations would have conformed because doing so was easy, straightforward, and obvious and because there were no advantages to not doing so. It is worth noting that some of the things that are called URNs but that do not conform to a narrow reading of RFC 2141 actually go back to interpretations of discussions three or four years earlier, some of which were recorded in RFC 1737. As a strategy, taking a term that has been used for something fairly broad and then trying to reuse it to describe something more specific in the hope that the prior uses will spontaneously disappear rarely works well. I believe history shows that the IETF Terminology Police have been even less effective than the IETF Protocol Police. If you don't like how that worked out, you should probably complain vigorously to the relevant AD when 2141 was completed and published. People who don't want an analysis of the history of how we got here, at least from my perspective, may want to stop reading here and skip to the end of this note. It is probably still controversial, but, again in hindsight, I think it may have been a mistake to bind URNs to the URI concept and syntax, at least without a richer elaboration and set of implementations of the whole "Internet Information Infrastructure Architecture (IIIA)" described in RFC 1737 and other documents of that period. I wish it had been possible at the time to come up and carry out a plan to develop the IIIA and fit URNs and some other URI types into it cleanly. Instead, as you will probably remember, the WG deteriorated into such hopeless bickering about different visions of architectural purity and the right ways to split hairs that, after several discussions and warnings, I, as the relevant AD at that time, notoriously decided that the only way to salvage anything was to kill the URI WG and, with it, the unified and generalized URI effort. The intent of that shutdown was to force people to regroup and get more focused rather than producing yet more grand architectures for castles in the sky and other edifices that would not, and probably could not, be built. I (and many others) knew at the time that a decision to force separate and focused work efforts was likely to result in less architectural elegance that people had hoped for, so the conclusion, like this month's conclusions, saddened me. But there was clearly no consensus around how to move forward with IIIA once people had to start talking about details and building things rather than sketching architectures. The choice was not about preserving IIIA or any other flavor of generalized architectural purity because they were already moribund. The WG shutdown action stopped the general theorizing and eventually led to the far more focused effort that produced URNs and 2141. The other major URI types contemplated by the IIIA went nowhere, which is unfortunate, but the available choices did not involve having them, architectural purity, URNs with a clear role, and clear alternatives for other purposes. It was between having the URNs we have -- including a few warts that may have been the result of trying to incorporate pieces of the architecture that arguably should have gone into other URI types -- and nothing at all other than DNS-based locators (at least nothing else that would have been URI-ish). In that context, I agree with you that RFC 3986 is an unfortunate document, both because of the reasons you have pointed out and because parts of it seem to represent a return to the thinking of the RFC 1736-1738 period that I would characterize as "if only one can generalize enough, everything will fall into place". But accepting it as part of our reality isn't a "compromise" either... it is just accepting reality... at least until someone can get traction on actually revising the thing. Now, if either the IETF time machine or my personal one worked better, there are a number of things I'd like to go back and change. I would have liked to see the slightly clearer, better explained, and even more focused URN model hinted at in my first paragraph to you above. I would have liked some other URI types to be developed in parallel -- different persistency properties and object models and maybe to have had URNs targeted a bit more on named objects and less on abstract "stuff". I would have preferred a somewhat different specification than what ended up as 3986. And, because it seems obligatory, I'd like a pony. But, in the real world, it is just too late, at least for the IETF. The Internet Architectural Philosophy Task Force might be able to do better, but what has happened and is happening in the real world is an inescapable engineering constraint. I am not suggesting that the IETF adopt and encourage things that we know to be bad practices that threaten interoperability or effective Internet operations -- I've argued strongly against the "people are doing it, so we have to accept and standardize it" approach elsewhere and will continue to do so. Now I'm making some assumptions that I should be explicit about. I assume that having a well-defined and unifying set of mechanisms for describing and handling stable identifiers is a good idea (if it isn't, it is really hard to defend URNs rather per-object-type URIs or some other per-object mechanism). I assume that a key condition for such stable identifiers is that we have a sufficient registry structure to vastly reduce the odds of two parties using the same namespace identifier for different purposes (I don't know how to maintain a useful family of stable identifiers without such arrangements, but would be interested if you have a model for doing so). I'm also assuming that the IETF's saying "these URN namespaces are a good and proven way to handle stable identifiers, people should consider them when a stable identifier type is needed" and then saying "but unless your type and definitions meet our norms and requirements, which we reserve the right to set without actually understanding your problem space, we won't let you register your namespace and therefore you can't use it" would be delusional. Unless you think there is something special about URNs, I would suggest the long history of people squatting on other identifier keywords (in many different areas) when we've created high barriers to registration makes that particular assumption a very safe one, no matter how much we would wish otherwise. Picking up a few points from your earlier note... --On Thursday, June 13, 2013 22:06 -0400 Keith Moore wrote: > On 06/13/2013 05:17 PM, John C Klensin wrote: >> (1) Incorporate provisions for fragments and queries in the >> syntax document, allowing them to be authorized on a >> per-namespace basis. > I don't think this makes any sense. A fragment is a property > of the resource. A query is a property of the resource and > the protocol used to access the resource. Neither is, or > should be, a property of the resource name. Despite your comment elsewhere, that is precisely what I've described, I believe accurately, as argument for purity. No matter how much you (or even I) might prefer it were not the case, the marketplace has decided otherwise. Adjusting things as experience accumulates is what Proposed Standards are supposed to be about, remember? But, of course, one can made the case that, contrary to the way the IETF Standards process normally works (and especially that property of Proposed Standards), 2141 freezes the name, definition, and syntax of URNs in place for all time. If so, then Peter, myself, and some others we could round up might reasonably take the existing draft documents and recast them into a new definition for USIs --Uniform Stable Identifers-- used those recast documents to explicitly deprecate 2141 and move it to historic on the ground that the marketplace had gone in another direction and 2141-style URNs were no longer relevant, and then go to the IESG and argue for a new or rechartered WG that would focus on the new specs and efficiently moving 2141-style URNs to the dustbin of protocol history. I think that would be a worse alternative than readjusting the URN definition to reflect what we understand today (and may not have understood 16 years ago) because I think the predictable result in the marketplace would be a mixture of: * Use of new format, syntax, definitions and name * Use of 2141-conformant URNs despite the IETF's deprecating them and encouraging migration * Use of the new new format, syntax, and definitions, but calling them URNs and, probably, * Use of some things, under one URI identifier or another, that conform to neither spec because we've confused people enough that they no longer care. I think a forward-compatible change that recognizes evolving understanding and applications and that legitimizes some uses that are now deployed but non-conforming would be a better plan. YMMD, of course. > Also, making fragments/queries a per-namespace attribute > increases complexity for no gain. See below. >> (2) Strongly advise against namespaces allowing them except in >> exceptional circumstances where the need is significant and >> they can be tightly defined. > > URN namespaces already cannot allow them. 2141 syntax > forbids either ? or # appearing in namespaces. To change > that would be an incompatible change to the protocol. Nor is > there any need to change the syntax. Here is where we clearly disagree and what I think may be the essence of the disagreement. First, what you see as an "incompatible change to the protocol" is what I see as a forward-compatible extension. If a tail containing a "#" or "?" is passed to a generic URN processor today, it will presumably be rejected. As far as I can tell, 2171 does not require that it be rejected with a specific "invalid syntax" status. Consistent with how we usually specify protocols, that is just outside the protocol requirements. We also know that some things that claim to be URN processors will accept these things without obvious harm and that generic URI syntax processors that conform to Internet Standard STD 66 (aka RFC 3986) will accept the syntax. Moveover, 2141 doesn't say that "?" and/or "#" are treated as normal characters and can be used that way in URN strings. _That_ would leave us with the sort of incompatible change to which you refer. It doesn't even put them on the "excluded characters" list of Section 2.4, which might be an issue. Instead, what it says (Section 2.3) is that these characters are reserved for future use associated with the uses of those characters specified in RFC 1630. Then it says (Section 2.3.2): "The URN-WG has not yet debated the applicability and precise semantics of those purposes as applied to URNs. Therefore, these characters are RESERVED for future developments." That does not sound like "chiseled into stone forever" or even "incompatible with the whole idea of URNs" to me. It says, something more like "when some future URN-related WG comes along and assigns uses and semantics, we have reserved the characters to make that possible". I read that as explicitly allowing for and authorizing the extensions we are now discussing, not consigning them to eternal damnation as your notes on the subject seem to imply. > This isn't an argument about purity. Making fragments and > query strings properties of URN namespaces will harm > interoperability rather than help it. Do you have worked examples to back up that assertion? Especially given that, as far as I can tell, 2141 explicitly predicts such extensions? Let's consider a slightly hypothetical case. There is a community that has an extremely stable identifier for books. That identifier is a well-recognized international standard in use by almost every serious book publisher worldwide. If one counts specifically-identified objects, that identifier set is probably much more used than unrelated standardized URNs and much more used outside the URN context than in it. They have even solved, to the satisfaction of their community, the always difficult object naming problem of determining when two alleged instances of something are the same object and should get the same identifier and when they are different. Now a significant constituency within that community comes along and says "we need to use a fragment identifier to point to specific chapters" and intend to do it by using URN:Our-Book-Identifier-Name:Our-Internationally-Specified-Identifier-code#ChapterN Now you propose to tell them that they can't do that. Why do you believe they will pay any attention to you? Why do you believe that your telling them that and their ignoring you will hurt the Internet? Why do you think it is better to have them do that and not document it in any way that is visible to the IETF community than to have the usage clearly-specified and documented? I just don't get it. As far as the "per namespace" part of my suggestion, I suggest to you that we have lots of protocols (including the one used to transport this message) for which we have specified syntax in a general way and then imposed contextual and semantic restrictions on how and where that syntax is actually used and permitted. I don't see the difference between that and saying, e.g., "fragments are permitted in URNs using the following general syntax, but the particular form and semantics of fragment identifiers, including whether they are permitted in practice, is part of the namespace definition". Again, I just don't see another practical way to do that, especially given that, which "#Chapter5" (or some similar syntax) might make perfectly good sense for a book, it makes little or no sense for a scientific journal, less sense for an article in such a journal, and still less sense for, e.g., a photograph. > I'm currently writing up an Internet Draft that will explain > the problem, and my proposal, in more detail. I look forward to seeing that. Given that we are some 15 or 16 years into the deployments and use of URNs for various purposes and the spectrum of fully conforming and less conforming implementations, I hoe that your I-D will also explain where you expect to see your proposal implemented and deployed in actual name-assigning and user communities. john From sm@resistor.net Fri Jun 14 12:50:44 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD8A21F9D10 for ; Fri, 14 Jun 2013 12:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mx60YqI33Yp for ; Fri, 14 Jun 2013 12:50:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DED21F9D11 for ; Fri, 14 Jun 2013 12:50:40 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r5EJoUEa029970; Fri, 14 Jun 2013 12:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371239440; bh=g4Posyehp2+arnDFDIc6FSFojOHiPw3TsVnBw0zM5wM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SGbmjCtPxqmmlEjQxEzLOrkCHjwhzkty2QPUJCRFTeU9yOvUAFGNfGpjik2Y/EWgr C6OzGr5F0sa+VLEj9uLyU32DrE7zzjgYx6KhHIN7uZiElIfuFuIA7ZJ/19nT4fTlIl 5LVdfc2/Yt2/wHDiIeU3rEFNhhhJU2BCXKitw994= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1371239440; i=@resistor.net; bh=g4Posyehp2+arnDFDIc6FSFojOHiPw3TsVnBw0zM5wM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=p/FTDkt17MsvdK3Hm5To/FSJE5X/JSk7sqQSxXn9tthDIdmr0rrITT2zbabtRjpx2 q+OJKrzpCPj9svcprBhB93POm1mN59bfMge7ryGjM0Wme31Y7AQsjbboYRy9AnCvVr fz9j9kzB8NOLfgNhQhoxDR1ICsoQylPRGqfuyH8w= Message-Id: <6.2.5.6.2.20130614123627.0cc85638@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Jun 2013 12:47:24 -0700 To: urn@ietf.org From: SM In-Reply-To: References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Keith Moore Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 19:50:44 -0000 At 09:49 14-06-2013, John C Klensin wrote: >Let's consider a slightly hypothetical case. There is a >community that has an extremely stable identifier for books. >That identifier is a well-recognized international standard in >use by almost every serious book publisher worldwide. If one >counts specifically-identified objects, that identifier set is >probably much more used than unrelated standardized URNs and >much more used outside the URN context than in it. They have >even solved, to the satisfaction of their community, the always >difficult object naming problem of determining when two alleged >instances of something are the same object and should get the >same identifier and when they are different. Now a significant >constituency within that community comes along and says "we need >to use a fragment identifier to point to specific chapters" and >intend to do it by using > >URN:Our-Book-Identifier-Name:Our-Internationally-Specified-Identifier-code#ChapterN > >Now you propose to tell them that they can't do that. Why do >you believe they will pay any attention to you? Why do you >believe that your telling them that and their ignoring you will >hurt the Internet? Why do you think it is better to have them >do that and not document it in any way that is visible to the >IETF community than to have the usage clearly-specified and >documented? I don't think that it is a good idea to tell people that they cannot do that as it does not solving the problem they would like to solve. If there isn't a convincing reason, in their opinion, not to do that I view it as the IETF community failing to find solutions. Regards, -sm From moore@network-heretics.com Fri Jun 14 12:52:05 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F22421F9D0F for ; Fri, 14 Jun 2013 12:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlfjlUnd1LOl for ; Fri, 14 Jun 2013 12:51:59 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9E92C21F9D14 for ; Fri, 14 Jun 2013 12:51:59 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A964A20DDF; Fri, 14 Jun 2013 15:51:58 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 14 Jun 2013 15:51:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=qyhFnt58XToaNzv4HD0usi ndU6Q=; b=OEU3z1Xb7qd5zmz+zoDt23mNNPvC8iemjAacuTIAeMcngAguwwaEyC lcd0+pHPDQmzHZz+Ov9gkxnnsVrJQcWZdovuhWNGfgpNEAYKhT4dI1UZU4roRUQ+ eWMjMJEMioznirVuamRZzli+LXECRdRm0fBGHTv/L/Ukci9n6Q6Q0= X-Sasl-enc: esmvVxgVW0isvUUP25Zstz1JuPq3EKJkYTqggGRhIHEV 1371239517 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0982C680277; Fri, 14 Jun 2013 15:51:56 -0400 (EDT) Message-ID: <51BB743B.2020007@network-heretics.com> Date: Fri, 14 Jun 2013 15:51:23 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John C Klensin References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 19:52:05 -0000 Without responding point-by-point (which I might do later or in private mail), I think it's pretty simple. 1. RFC 2141 defined a type of identifier which it called Uniform Resource Names or URNs. It also defined a syntax for URNs which happens to begin with 'urn:', and rules for creating and assigning and not reassigning URNs. Granted, there had been discussions for years prior to that which used the term URN more loosely and/or which proposed different rules and different syntaxes, but 2141 represents a rough-consensus result of those long discussions aimed at understanding what URNs really should be. 2. For various reasons, some people weren't happy with the URN syntax or framework that IETF decided on. One result was that the authors of RFC 3969 tried to broaden the definition of URNs in that document. 3. Even if you accept (as RFC 3969 states) that the name URN applies to things other than those defined in 2141, the situation we were left with is both confusing and cumbersome to discuss. The identifiers defined in RFC 2141 have unique properties, by design, which do not necessarily apply to other persistent URI-like identifiers. And it's cumbersome to discuss RFC 2141 identifiers specifically (for the purpose of updating RFC 2141, or for any other purpose) while still being consistent with the language in RFC 3969. You end up either saying "for the purpose of this document, URN refers to the identifiers defined in RFC 2141, language in RFC 3969 notwithstanding" (inviting confusion from those who miss that restriction), or you end up saying something like "URNs as defined in RFC 2141" every time you need to refer to that kind of identifier. Regardless of what RFC 3969 says, the identifiers most often associated with the term URN are undoubtedly those that begin with 'urn:' and have a syntax consistent with RFC 2141. Trying to say that there are URNs that don't begin with 'urn:' is like saying that there are other HTTP URLs that don't begin with 'http:'. Yes, it's true in a sense, but it's just silly and confusing and there's no good reason to define things that way. Also, regardless of what RFC 3969 says, URNs as defined in RFC 2141 weren't designed to be used with fragment identifiers or query strings - or at least, we didn't manage to define how that would work, and the reason that we didn't define how that would work is because there wasn't an obvious interpretation that didn't kill the properties we wanted for URNs. So we declined to do that in RFC 2141, and in trying to generalize URI syntax, RFC 3969 didn't address those issues either. It is of course possible to define other URIs with different syntax or rules that have persistence properties similar to, and perhaps even better than, those of URNs. Many people claim to have done so. Those identifiers, and URNs, should each succeed or fail on their own merits. However, those other URIs will inevitably have subtly different properties than URNs as defined in RFC 2141. (If someone wants a name to refer to all such identifiers, I nominate "persistent URIs".) Properties of URNs shouldn't be automatically assumed to apply to other kinds of persistent URIs, nor vice versa. 4. URNs (and when I say URN, I always mean the 2141 definition), above all else, are intended to be persistent. This is the fundamental property of URNs - not only that they are persistent, but that the presence of the 'urn:' tag is an indicator that the identifier may be interpreted as persistent, and also that the persistence of that identifier is an important property that should be maintained. Extending the concept of URNs in such a way that the resulting identifier is no longer persistent would break the essential and fundamental property of URNs. 5. It was always intended that URNs should be applicable to existing resources such as HTML documents, or HTTP-based search engines, though by no means limited to those resource types. 6. Fragment identifiers as used in existing content-types were not designed to be persistent across changes to the document. For identifiers to have persistence there needs to be some discipline in assigning meaning to them initially and in not reusing them in ways inconsistent with their originally assigned meanings. If there is any such convention for fragment identifiers, I'm not aware of it, but it certainly isn't widely used. Given the existence and utility of other kinds of identifiers which are not persistent and should not be so, I also believe that persistent identifiers need to be readily distinguished from non-persistent identifiers. Again, I'm not aware of a convention for doing this, though I hypothesize that one could exist. 7. Thus, the combination of a URN and a fragment identifier has no assurance of persistence. It follows that the combination of a URN and a fragment identifier cannot be a URN. 8. One can argue that the persistence of an identifier consisting of a URN and a query string could actually be persistent, if the resource named by the URN were defined in such a way as to make such queries persistent. For instance, if ISBNs are persistent identifiers, then a service that returned citation data associated with an ISBN, and which accepted the ISBN as a query string, would appear to have approximately the persistence properties necessary for the combination of a service URN and a query string, to itself be considered a URN. But defining those properties in a way that is generally applicable to resources that accept queries is problematic. In addition, it is desirable to be able to write an identifier that consists of a URN and a query string even for resources for which queries do not have a consistent meaning over time. 9. At any rate, existing resources that accept query strings do not in general assure persistence of the results of such queries. Thus, in general, a combination of a URN used to name an existing resource, and a query string, provides no assurance of persistence, and the combination should not be considered a URN. The above, I submit, is reality. (There are probably some other relevant and salient points which are also defensible as reality.) ------------------------------------------------------ What's below this line is brainstorming. Now, given the above, I can see the need for up to four kinds of identifiers consisting of a "base" URN and a query string or fragment identifier: 1. URN + fragment identifier, where there is no assurance of the persistence of the fragment identifier over changes to the named resource. This combined identifier is not a persistent identifier, and thus not a URN. (One can argue that such an identifier isn't really useful. But I think it's potentially useful in the same sense that a reference to a document with section or page number can still be useful if that document was revised and the old section or page number is no longer quite correct... at least it gets you to the right document.) 2. URN + query string, where there is no assurance of the persistence of the results of the query service (e.g. that the query syntax wouldn't change or that the interpretation of the query wouldn't change). This combined identifier is not a persistent identifier, and thus not a URN. 3. URN + fragment identifier, under some hypothetical scheme for naming fragments that assured the persistence of the fragment identifier over changes to the resource, and for which the fragment identifiers were themselves recognizable as being persistent. (For example, one could define a new URN for each fragment.) This combined identifier would qualify as a URN. 4. URN + query string, where there were some (as yet undefined) assurance of persistence of query results (for all possible query strings). Of these, cases 1 and 2 are easily described. Cases 3 and 4 need more work (perhaps much more work). It's important that each of these four kinds of identifier be readily distinguished from one another. I can think of several different ways to do that. Common URI syntax, and common practice, is to combine a base URI with a fragment identifier or query string by appending the latter to the former. Using this convention for cases 1 and 2 seems likely to cause confusion, because the resulting identifier would begin with 'urn:' but not have the persistence properties required and expected of URNs. Using this convention for cases 3 and 4 might also cause confusion, because people see these identifiers, and it wouldn't be obvious to most people that a string like urn:foo:bar?zot was not simply the result of appending the query string ?zot to an ordinary URN. I'm not committed to this view, but I suspect that using the existing convention for either cases 1 and 2 or cases 3 and 4 would promote widespread misunderstanding. (And URNs are already suffering from a tremendous amount of misunderstanding...). So I'm guessing that we need (at least) two separate syntactic conventions for deriving identifiers that are based on URNs, neither of which is simply URN + fragment id or query string. (One can argue for additional conventions to serve as input to URN resolution, but that would require a much more rigid definition of URN resolution than has yet been attempted, so I think we can safely say that's a topic for future study.) One approach might be to define two new kinds of identifier: non-persistent URN-derived names and persistent URN-derived names. Assign them distinct prefixes like nudn: and pudn:. Define rules for (a) creating a NUDN from URN + query string or URN + fragment ID, and (b) interpreting an NUDN by extracting the embedded URN, resolving it, and interpreting the query string or fragment id in the context of the resource resulting from resolution of the URN. Perhaps the definition of 'pudn:' should be left for further study, but it might still be useful to mention them as a way of distinguishing them from NUDNs. And reinforce the notion that neither '#' and '?' should appear in a URN; and if they do appear, the result is at best undefined, or perhaps defined to be invalid. Strawman proposal for NUDN syntax (just to have something concrete to think about, or throw tomatoes at, not because I'm in love with it): nudn = 'nudn:' + base64-encoded-URN + '?' + query-string / 'nudn': + base64-encoded-URN + '#' + fragment-id I do think it's highly desirable that identifiers from cases 1 and 2 NOT begin with 'urn:' I don't think there's any way to solve this problem that's not ugly, but some ways are less ugly than others. Keith From stpeter@stpeter.im Fri Jun 14 13:43:10 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8552821F9B0C for ; Fri, 14 Jun 2013 13:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6m46iR3an3m for ; Fri, 14 Jun 2013 13:43:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFEC21F9AE8 for ; Fri, 14 Jun 2013 13:43:05 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5FA69412C6; Fri, 14 Jun 2013 14:56:46 -0600 (MDT) Message-ID: <51BB8056.4050700@stpeter.im> Date: Fri, 14 Jun 2013 14:43:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: SM References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <6.2.5.6.2.20130614123627.0cc85638@resistor.net> In-Reply-To: <6.2.5.6.2.20130614123627.0cc85638@resistor.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 20:43:10 -0000 On 6/14/13 1:47 PM, SM wrote: > At 09:49 14-06-2013, John C Klensin wrote: >> Let's consider a slightly hypothetical case. There is a >> community that has an extremely stable identifier for books. >> That identifier is a well-recognized international standard in >> use by almost every serious book publisher worldwide. If one >> counts specifically-identified objects, that identifier set is >> probably much more used than unrelated standardized URNs and >> much more used outside the URN context than in it. They have >> even solved, to the satisfaction of their community, the always >> difficult object naming problem of determining when two alleged >> instances of something are the same object and should get the >> same identifier and when they are different. Now a significant >> constituency within that community comes along and says "we need >> to use a fragment identifier to point to specific chapters" and >> intend to do it by using >> >> URN:Our-Book-Identifier-Name:Our-Internationally-Specified-Identifier-code#ChapterN >> >> >> Now you propose to tell them that they can't do that. Why do >> you believe they will pay any attention to you? Why do you >> believe that your telling them that and their ignoring you will >> hurt the Internet? Why do you think it is better to have them >> do that and not document it in any way that is visible to the >> IETF community than to have the usage clearly-specified and >> documented? > > I don't think that it is a good idea to tell people that they cannot do > that as it does not solving the problem they would like to solve. If > there isn't a convincing reason, in their opinion, not to do that I view > it as the IETF community failing to find solutions. Yes, I think that is how it will be perceived. It's the same story as LEIRI vs. IRI and I would dearly like to avoid that fate here! Peter -- Peter Saint-Andre https://stpeter.im/ From moore@network-heretics.com Fri Jun 14 13:57:45 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BBF21F9A5E for ; Fri, 14 Jun 2013 13:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRxrmuf9pF5g for ; Fri, 14 Jun 2013 13:57:37 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 141CD21F9A5C for ; Fri, 14 Jun 2013 13:57:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5F59B208DC; Fri, 14 Jun 2013 16:57:29 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 14 Jun 2013 16:57:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=YWj7GI+SoDqasNVDYh7bdT zeCXI=; b=CKmYlzxcQG3IbPOutsqK9mcdsXfjiaD0U9lBZQCJCeX0YPMYYkVwdh FvtOjHtErifbpdygBXA9BnXvqHwtT0lxaCPieTzX+1WWuWS/OxavhqdE1L9RV5xy BjBHnPfcPxJoHOAyb7iRIhrF8wUkQ/gVFVKd0DPpRDf3uxwFOmrHE= X-Sasl-enc: FLEvV2GTzdyOS2UhAxO8DXagj9UflnqaCp6Deirr8WAn 1371243448 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 772BFC00E7F; Fri, 14 Jun 2013 16:57:28 -0400 (EDT) Message-ID: <51BB8398.4020400@network-heretics.com> Date: Fri, 14 Jun 2013 16:56:56 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <6.2.5.6.2.20130614123627.0cc85638@resistor.net> <51BB8056.4050700@stpeter.im> In-Reply-To: <51BB8056.4050700@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 20:57:45 -0000 On 06/14/2013 04:43 PM, Peter Saint-Andre wrote: >> I don't think that it is a good idea to tell people that they cannot do >> >that as it does not solving the problem they would like to solve. If >> >there isn't a convincing reason, in their opinion, not to do that I view >> >it as the IETF community failing to find solutions. > Yes, I think that is how it will be perceived. It's the same story as > LEIRI vs. IRI and I would dearly like to avoid that fate here! Without your being more specific about what you mean here, I don't know how to evaluate it. Keith p.s. responding to "it's not a good idea to tell people that they cannot do ": URNs were invented for particular purposes, and the standards for URN syntax and use were carefully tailored to fit those purposes. If someone wants to define a kind of identifier that isn't consistent with those purposes, URNs are not what they need. It happens all the time that we and others define solutions that turn out to not be appropriate for some unanticipated use case, or that some use cases were ruled out of scope. People might not like the result, but it's necessary and inevitable that it happens sometimes. To make things too general is a sure path to failure. Similarly, if we've somehow failed to be sufficiently general in how we've defined URNs, so that the syntax or other rules governing URNs don't permit uses of URNs that were nevertheless consistent with those intended purposes, it's a bit late to change those standards. That's not to say that we absolutely cannot do so. But if we attempt to do so, we risk of harming all other uses of URNs, and the risk of that has to be balanced against the perceived benefit of changing the URN specifications in an incompatible way. From julian.reschke@gmx.de Sat Jun 15 04:02:53 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690B321F9C35 for ; Sat, 15 Jun 2013 04:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI-j3vGe6q26 for ; Sat, 15 Jun 2013 04:02:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id CF09A21F9BF0 for ; Sat, 15 Jun 2013 04:02:47 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MDjZQ-1UXuUC2HfS-00H6fu for ; Sat, 15 Jun 2013 13:02:46 +0200 Received: (qmail invoked by alias); 15 Jun 2013 11:02:46 -0000 Received: from p5DD94BD0.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [93.217.75.208] by mail.gmx.net (mp020) with SMTP; 15 Jun 2013 13:02:46 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/btO9SLYTbxKfUw4eQH02k74hXoOgMN9WOgglz5E vNUx+0ELd44HUT Message-ID: <51BC49D0.6000504@gmx.de> Date: Sat, 15 Jun 2013 13:02:40 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> In-Reply-To: <51BB743B.2020007@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 11:02:53 -0000 On 2013-06-14 21:51, Keith Moore wrote: > ... > 2. For various reasons, some people weren't happy with the URN syntax or > framework that IETF decided on. One result was that the authors of RFC > 3969 tried to broaden the definition of URNs in that document. > ... s/3969/3986/ I assume. FWIW, RFC 3986 says in : "1.1.3. URI, URL, and URN A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name. An individual scheme does not have to be classified as being just one of "name" or "locator". Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]." If you really really believe there's something to fix over here then please make a concrete proposal. > 3. Even if you accept (as RFC 3969 states) that the name URN applies to > things other than those defined in 2141, the situation we were left with Actually, it recommends to avoid the term. All it says about is what it was used for historically. > is both confusing and cumbersome to discuss. The identifiers defined in > RFC 2141 have unique properties, by design, which do not necessarily > apply to other persistent URI-like identifiers. And it's cumbersome to > discuss RFC 2141 identifiers specifically (for the purpose of updating > RFC 2141, or for any other purpose) while still being consistent with > the language in RFC 3969. You end up either saying "for the purpose of > this document, URN refers to the identifiers defined in RFC 2141, > language in RFC 3969 notwithstanding" (inviting confusion from those who > miss that restriction), or you end up saying something like "URNs as > defined in RFC 2141" every time you need to refer to that kind of > identifier. I believe you read something into RFC 3986 which isn't there. > ... > Also, regardless of what RFC 3969 says, URNs as defined in RFC 2141 > weren't designed to be used with fragment identifiers or query strings - > or at least, we didn't manage to define how that would work, and the > reason that we didn't define how that would work is because there wasn't > an obvious interpretation that didn't kill the properties we wanted for > URNs. So we declined to do that in RFC 2141, and in trying to > generalize URI syntax, RFC 3969 didn't address those issues either. > ... RFC 3986 just defines generic syntax. It doesn't say anything about URI schemes having to support queries. What it *does* say is how queries, when present, affect resolution against a base URI. It also doesn't say anything specific about fragments in URI schemes. What it says () is: "The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications." Do you disagree with this? > It is of course possible to define other URIs with different syntax or > rules that have persistence properties similar to, and perhaps even > better than, those of URNs. Many people claim to have done so. Those > identifiers, and URNs, should each succeed or fail on their own > merits. However, those other URIs will inevitably have subtly > different properties than URNs as defined in RFC 2141. (If someone > wants a name to refer to all such identifiers, I nominate "persistent > URIs".) Properties of URNs shouldn't be automatically assumed to apply > to other kinds of persistent URIs, nor vice versa. Right. I don't see any disagreement about that. > 4. URNs (and when I say URN, I always mean the 2141 definition), above > all else, are intended to be persistent. This is the fundamental > property of URNs - not only that they are persistent, but that the > presence of the 'urn:' tag is an indicator that the identifier may be > interpreted as persistent, and also that the persistence of that > identifier is an important property that should be maintained. Extending > the concept of URNs in such a way that the resulting identifier is no > longer persistent would break the essential and fundamental property of > URNs. Right. I don't see any disagreement about that either. > 5. It was always intended that URNs should be applicable to existing > resources such as HTML documents, or HTTP-based search engines, though > by no means limited to those resource types. Yes. > 6. Fragment identifiers as used in existing content-types were not > designed to be persistent across changes to the document. For > identifiers to have persistence there needs to be some discipline in > assigning meaning to them initially and in not reusing them in ways > inconsistent with their originally assigned meanings. If there is any > such convention for fragment identifiers, I'm not aware of it, but it > certainly isn't widely used. Given the existence and utility of other > kinds of identifiers which are not persistent and should not be so, I > also believe that persistent identifiers need to be readily > distinguished from non-persistent identifiers. Again, I'm not aware of > a convention for doing this, though I hypothesize that one could exist. > > 7. Thus, the combination of a URN and a fragment identifier has no > assurance of persistence. It follows that the combination of a URN and > a fragment identifier cannot be a URN. I agree that it would be a bad idea. So is this about whether we allow a URI using the "urn" scheme carrying a fragment identifier to be called a URN? > 8. One can argue that the persistence of an identifier consisting of a > URN and a query string could actually be persistent, if the resource > named by the URN were defined in such a way as to make such queries > persistent. For instance, if ISBNs are persistent identifiers, then a > service that returned citation data associated with an ISBN, and which > accepted the ISBN as a query string, would appear to have approximately > the persistence properties necessary for the combination of a service > URN and a query string, to itself be considered a URN. But defining > those properties in a way that is generally applicable to resources that > accept queries is problematic. In addition, it is desirable to be able > to write an identifier that consists of a URN and a query string even > for resources for which queries do not have a consistent meaning over time. As per RFC 3986, the query component is used to identify the resource, just like the path. It's just syntax. Whether two URIs that only differ in the query part have anything in common depends solely on the URI scheme definition. > 9. At any rate, existing resources that accept query strings do not in > general assure persistence of the results of such queries. Thus, in ...so this kind of terminology is misleading. In general, you use both path and query to locate the resource. > general, a combination of a URN used to name an existing resource, and a > query string, provides no assurance of persistence, and the combination > should not be considered a URN. > > The above, I submit, is reality. (There are probably some other > relevant and salient points which are also defensible as reality.) > ------------------------------------------------------ > What's below this line is brainstorming. > > Now, given the above, I can see the need for up to four kinds of > identifiers consisting of a "base" URN and a query string or fragment > identifier: > > 1. URN + fragment identifier, where there is no assurance of the > persistence of the fragment identifier over changes to the named > resource. This combined identifier is not a persistent identifier, and > thus not a URN. > > (One can argue that such an identifier isn't really useful. But I > think it's potentially useful in the same sense that a reference to a > document with section or page number can still be useful if that > document was revised and the old section or page number is no longer > quite correct... at least it gets you to the right document.) > > 2. URN + query string, where there is no assurance of the persistence > of the results of the query service (e.g. that the query syntax wouldn't > change or that the interpretation of the query wouldn't change). This > combined identifier is not a persistent identifier, and thus not a URN. > > 3. URN + fragment identifier, under some hypothetical scheme for naming > fragments that assured the persistence of the fragment identifier over > changes to the resource, and for which the fragment identifiers were > themselves recognizable as being persistent. (For example, one could > define a new URN for each fragment.) > This combined identifier would qualify as a URN. > > 4. URN + query string, where there were some (as yet undefined) > assurance of persistence of query results (for all possible query strings). I don't like that direction. A URI scheme can allow queries. In that case, not making the query part of the scheme syntax would be totally confusing. Not *calling* it a URN might work, but still: it's part of the URI, but not part of the URN? Things might work better if you mint a new term for the URN part that *is* persistent. Or better yet, don't go there: do not allow queries purposes that conflict with the intent of URNs. > Of these, cases 1 and 2 are easily described. Cases 3 and 4 need more > work (perhaps much more work). It's important that each of these four > kinds of identifier be readily distinguished from one another. I can > think of several different ways to do that. > > Common URI syntax, and common practice, is to combine a base URI with a > fragment identifier or query string by appending the latter to the > former. Using this convention for cases 1 and 2 seems likely to cause > confusion, because the resulting identifier would begin with 'urn:' but > not have the persistence properties required and expected of URNs. Using > this convention for cases 3 and 4 might also cause confusion, because > people see these identifiers, and it wouldn't be obvious to most people > that a string like urn:foo:bar?zot was not simply the result of > appending the query string ?zot to an ordinary URN. > > I'm not committed to this view, but I suspect that using the existing > convention for either cases 1 and 2 or cases 3 and 4 would promote > widespread misunderstanding. (And URNs are already suffering from a > tremendous amount of misunderstanding...). So I'm guessing that we > need (at least) two separate syntactic conventions for deriving > identifiers that are based on URNs, neither of which is simply URN + > fragment id or query string. (One can argue for additional conventions > to serve as input to URN resolution, but that would require a much more > rigid definition of URN resolution than has yet been attempted, so I > think we can safely say that's a topic for future study.) > > One approach might be to define two new kinds of identifier: > non-persistent URN-derived names and persistent URN-derived names. > Assign them distinct prefixes like nudn: and pudn:. Define rules for (a) > creating a NUDN from URN + query string or URN + fragment ID, and (b) > interpreting an NUDN by extracting the embedded URN, resolving it, and > interpreting the query string or fragment id in the context of the > resource resulting from resolution of the URN. Perhaps the definition > of 'pudn:' should be left for further study, but it might still be > useful to mention them as a way of distinguishing them from NUDNs. And > reinforce the notion that neither '#' and '?' should appear in a URN; > and if they do appear, the result is at best undefined, or perhaps > defined to be invalid. > > Strawman proposal for NUDN syntax (just to have something concrete to > think about, or throw tomatoes at, not because I'm in love with it): > > nudn = 'nudn:' + base64-encoded-URN + '?' + query-string > / 'nudn': + base64-encoded-URN + '#' + fragment-id > > > I do think it's highly desirable that identifiers from cases 1 and 2 NOT > begin with 'urn:' > > I don't think there's any way to solve this problem that's not ugly, but > some ways are less ugly than others. Indeed. Before we go there: do we have a concrete use case that we would test these ideas with? Best regards, Julian From john-ietf@jck.com Sat Jun 15 06:16:14 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C426221F9C6C for ; Sat, 15 Jun 2013 06:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, FUZZY_VPILL=0.687, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFO1CSsjHxUB for ; Sat, 15 Jun 2013 06:16:08 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8416921F9A7E for ; Sat, 15 Jun 2013 06:16:08 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UnqKl-000GDY-2E; Sat, 15 Jun 2013 09:15:59 -0400 Date: Sat, 15 Jun 2013 09:15:53 -0400 From: John C Klensin To: Keith Moore Message-ID: <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> In-Reply-To: <51BB743B.2020007@network-heretics.com> References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@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 Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 13:16:15 -0000 Keith, It is starting to feel as if we are either reading different documents with the same names and identifiers or that we are somehow reading the same documents very differently. Key examples and some other discussion inline below. Note to impatient readers: there is a proposal for specific text (a proposed new section of 2141bis and update to 1737) at the end of this over-long note. --On Friday, June 14, 2013 15:51 -0400 Keith Moore wrote: >... > 1. RFC 2141 defined a type of identifier which it called > Uniform Resource Names or URNs. It also defined a syntax for > URNs which happens to begin with 'urn:', and rules for > creating and assigning and not reassigning URNs. Granted, > there had been discussions for years prior to that which used > the term URN more loosely and/or which proposed different > rules and different syntaxes, but 2141 represents a > rough-consensus result of those long discussions aimed at > understanding what URNs really should be. My reading of draft-ietf-urnbis-rfc2141bis-urn-05 is entirely consistent with that. It excludes the other uses of the term "URN" in favor of talking about 2141-type URNs, contains explicit statements about minimal necessary chances from 2141, etc. Now, if I thought 3986 were as bogus as you apparently do, or even found it mildly distasteful (which I do), and were holding the pen on 2141bis rather than Peter, I'd probably try to structure the introductory paragraphs to sound less like the main reason for the document was to bring 2141 into conformance with 3986. But, even if Peter rephrased things that way, they wouldn't change the spec significantly in most areas, only the vocabulary used to describe it. > 2. For various reasons, some people weren't happy with the URN > syntax or framework that IETF decided on. One result was > that the authors of RFC 3969 tried to broaden the definition > of URNs in that document. I assume you mean "3986" in the above and a few places below that you mention 3969. Whether that characterization is accurate or not --it goes almost without saying that some people (maybe exclusively the same "some people", maybe not) would disagree-- 3986 has now stood at a full Internet Standard for more than eight years without any significant challenge to its validity as a specification or claim to be an Internet Standard. Given that, I think URNBis and rfc2141bis are obligated to be consistent with it, at least unless we want to make the claim that 2141 (and 2141bis) URNs are really not URIs. I don't see any basis in the URNBis charter for either challenging the "URNs are URIs" assumption or for simply ignoring an applicable Internet Standard that is much later than 2141. > 3. Even if you accept (as RFC 3969 states) that the name URN > applies to things other than those defined in 2141, the > situation we were left with is both confusing and cumbersome > to discuss. The identifiers defined in RFC 2141 have unique > properties, by design, which do not necessarily apply to other > persistent URI-like identifiers. And it's cumbersome to > discuss RFC 2141 identifiers specifically (for the purpose of > updating RFC 2141, or for any other purpose) while still being > consistent with the language in RFC 3969. You end up either > saying "for the purpose of this document, URN refers to the > identifiers defined in RFC 2141, language in RFC 3969 > notwithstanding" (inviting confusion from those who miss that > restriction), or you end up saying something like "URNs as > defined in RFC 2141" every time you need to refer to that kind > of identifier. Yes, that is a bit of an editorial challenge. I don't see it as a serious substantive problem because I don't think anyone is claiming that draft-ietf-urnbis-rfc2141bis-urn should be anything but 2141bis... with adjustments made to conform 2141-style URNs to the requirements of 3986. I don't see that 3986 requires draft-ietf-urnbis-rfc2141bis-urn to adopt any fundamental definition for URNs other than that of 2141 and don't think the draft contains such a definitional change. So I'm not sure where we are disagreeing. > Regardless of what RFC 3969 says, the identifiers most often > associated with the term URN are undoubtedly those that begin > with 'urn:' and have a syntax consistent with RFC 2141. > Trying to say that there are URNs that don't begin with 'urn:' > is like saying that there are other HTTP URLs that don't begin > with 'http:'. Yes, it's true in a sense, but it's just silly > and confusing and there's no good reason to define things that > way. But, as far as I can tell, draft-ietf-urnbis-rfc2141bis-urn-05 doesn't do that and in fact carefully avoids it. So the above is either an attack on 3986 (and hence out of scope for the WG) or just isn't relevant. > Also, regardless of what RFC 3969 says, URNs as defined in RFC > 2141 weren't designed to be used with fragment identifiers or > query strings - or at least, we didn't manage to define how > that would work, and the reason that we didn't define how that > would work is because there wasn't an obvious interpretation > that didn't kill the properties we wanted for URNs. So we > declined to do that in RFC 2141, and in trying to generalize > URI syntax, RFC 3969 didn't address those issues either. And here we get to what I think are two of the core issues. Let's separate them into two questions: (i) If there were no syntax restrictions imposed by 2141, 3986, or anything else, would fragment identifiers and/or queries be appropriate for URNs? (ii) Is 3986 required to authorize fragments or queries in the URN syntax and, if so, is that a serious and problematic incompatible change? Let me address the second here and the first below. You read the statements in 2141 (or perhaps some oral tradition to which the rest of us don't have access) as prohibiting fragment identifiers and queries. When I read what I hope are the same statements, I conclude that there are lots of ways to say "prohibit". One of them involves the term "excluded", which is exactly what 2141 says about a number of characters in its Section 2.4. But what it says about "?" and "#" is to identify them with purposes defined in RFC 1630 -- no appeal to presumed 3986 revisionism is required-- and "has not yet debated the applicability and precise semantics of those purposes as applied to URNs". It then says "these characters are RESERVED for future developments". To me, those are statements that imply that those future developments are anticipated, even though no timeframe is given for them (and they might not happen). When the spec explicitly says those sorts of things about future definition of semantics and future use, it seems to me that comments like "weren't designed to be used..." (with the implication of "designed to _not_ be used") are a real stretch. "didn't manage to define how that would work, and the reason that we didn't define how that would work is because there wasn't an obvious interpretation that didn't kill the properties we wanted for URNs" might be true, but there is no evidence at all for it in 2141. All I can get from 2141 is that there wasn't consensus on particular semantics but that there was no particular reason to expect that semantics and consensus would not emerge in the future. Again, if the intent had been to say "we concluded that this was impossible without violating fundamental URN design decisions" or just "really bad idea" how do you explain 2141 not just saying that rather than talking about future use? Your memory or that of others as to what you thought the intent was at the time notwithstanding, 2141 is now a 16-year-old spec. I think what it actually says has to be taken at face value, especially if it seems to contradict what you believe was the intent. >... > 4. URNs (and when I say URN, I always mean the 2141 > definition), above all else, are intended to be persistent. > This is the fundamental property of URNs - not only that they > are persistent, but that the presence of the 'urn:' tag is an > indicator that the identifier may be interpreted as > persistent, and also that the persistence of that identifier > is an important property that should be maintained. > Extending the concept of URNs in such a way that the resulting > identifier is no longer persistent would break the essential > and fundamental property of URNs. I don't think anyone is disagreeing about that. At least I'm not and I don't see anything in the current version of 2141bis that does either. >... > 6. Fragment identifiers as used in existing content-types were > not designed to be persistent across changes to the document. > For identifiers to have persistence there needs to be some > discipline in assigning meaning to them initially and in not > reusing them in ways inconsistent with their originally > assigned meanings. If there is any such convention for > fragment identifiers, I'm not aware of it, but it certainly > isn't widely used. Given the existence and utility of other > kinds of identifiers which are not persistent and should not > be so, I also believe that persistent identifiers need to be > readily distinguished from non-persistent identifiers. > Again, I'm not aware of a convention for doing this, though I > hypothesize that one could exist. I think you are creating a strawman here and then demolishing it. There is no question, in my mind, at least, that using, e.g., a character offset fragment identifier would be truly stupid in a context that requires persistence, URN or otherwise. But that doesn't imply that, for some URN types (namespaces) stable fragment identifiers cannot be properly identified and defined. Second, even after rereading 2141 and 1737, I'm not sure how far one can go in the direction of an identifier that is "persistent across changes in a document" because even that statement takes one very far in the direction of needing a universal theory about what changes are still "the same document" and what changes make new documents. More important, as soon as you say "persistent identifier" and "changes to object" in the same context, you transport us all to to the edge, not of rathole, but of a bottomless pit. "Persistence" of an identifier is clear when there is a single, unique, object and the only thing that changes is its location. That is where one of the major threads that led to URNs started when web objects were considered -- URLs were just not right when one considered content that might be relocated, unchanged, from one server (and DNS name) to another. But, as soon as one talks about two objects that are alleged to be identical or changes in one object, the "persistence" and object-binding validity of the identifier become fairly deep questions that have plagued archivists, classifiers, and philosophers for centuries... questions that ultimately have no clear answers except in the axioms and postulates of object-type-specific axiomatic systems. Another key reason why I shut down the original URI WG in the hope of saving the work as that several of the efforts that were underway appeared to have comprehensive solutions to the "can it change and be the same thing" and "are two objects actually identical" questions in the critical path of a protocol or identifier type questions -- a WG that could safely be predicted to go on for years and indeed centuries and never converge was just not considered acceptable in the IETF of the time. Note that the above has nothing to do with fragments or queries. The problem exists in its full glory with URNs and URN-object bindings as soon as you say that something _is_ "designed to be persistent across changes to the document". Whether fragments make things any worse depends on what the namespace looks like and how things are designed. Let's take the fairly familiar example of a book. The publisher, library, and archival communities have established conventions about when two copies of a book are "the same". If they are "the same" then we would except either copy to represent a correct binding (and resolution response) to a given URN (or instances of that URN that match the 2141 equivalence rules). It is important to understand that "the same" represents conventions and that pushing the limits too hard leads to confusion and/or high-minded arguments. For example, two different editions are almost always considered different books for identification or classification purposes. Two different printings in which a few obvious typographical efforts are corrected in the later one are usually considered the same book. If one physical instance of the book is autographed by the author and another is not, they are the "same book" for many purposes but are certainly not "the same". The only possible definitive, convention or axiom-free definition of "the same" requires agreeing that all objects are unique and that no URN can be satisfied by more than one volume-object. (Of course, that is pretty close to an axiomatic statement too, but of a different type than we we talk about multiple satisfying objects.) But "all physically distinct volumes are unique" would, as a rule, make book-URNs useless for most of the purposes to which one would like to put them. Now, given that hypothetical book-URN (i.e., "urn:book:..."), whether a transformation of the content from bound paper form to electronic (and non-page-image) form is a change that still allows both forms to satisfy the same URN is another one of those philosophical questions that can be resolved only by convention. If the convention is that they are the same, than any fragment identifier that utilizes page numbers is obviously trash (and cannot be "persistent" across the two forms). But one that utilizes chapter numbers or even names doesn't make the URN any less persistent than it would be if fragment identifiers are not used or not allowed. Suppose, instead, that the convention is established that a translation is still "the same book". Now that convention would make me and probably others very anxious but I can find nothing specific in 2141 or even 1737 that prohibits it. The nervousness arises from the URN and namespace definition and not from the presence or absence of fragments. But it would _constrain_ the types of fragment identifiers that make any sense at all. For example, using the example above, chapter numbers would still be sensible as fragment identifiers (at least modulo a few i18n issues) but chapter names almost certainly would not. (Aside for the record: whatever that hypothetical "book" URN might be and how it might be defined, draft-ietf-urnbis-rfc3187bis-isbn-urn is not it. The latter identifies, among other things, a particular set of conventions about uniqueness and who gets to determine it together with the consequent rules about object-bindings. By doing so, it "solves" a lot of the more general issues described above but also covers over some differences that might be important for other purposes.) > 7. Thus, the combination of a URN and a fragment identifier > has no assurance of persistence. It follows that the > combination of a URN and a fragment identifier cannot be a URN. That does not follow at all. If it does, it leads to the interesting conclusion that a URN cannot be persistent enough to be a URN unless it names only a single and unique object with no possibility of changes to the object itself. It does follow that fragment identifiers to be used with (or as part of) URNs have to be designed with far more care about the nature of the namespace and what that namespace is used to identify than fragment identifiers for, e.g., URL-identified web pages have often been in the past. > 8. One can argue that the persistence of an identifier > consisting of a URN and a query string could actually be > persistent, if the resource named by the URN were defined in >... I think that query strings associated with URNs are far more problematic than fragment identifiers because fragment identifiers (at least by historical convention) point to something _within_ and object or some subdivision of it. Queries, as your example (not quoted here) suggests (at least as I interpret it), can, in principle, be used to take the rest of the URI as input and return something completely different. Defining such a situation in a way that would assure persistence is hard at best. Extending your example a bit and combining it with my hypothetical "book" URN, one could imagine urn:book:....?reverse-citation-index which would return all of the known books or articles that cite that book. Since a new citation could be added at any time, the practical persistency problems of that query are horrible even if the query could be well-defined (it can't, at least without a definition of the sources to be searched, but that is just a property of my choice of a simple, but sloppy, example). > 9. At any rate, existing resources that accept query strings > do not in general assure persistence of the results of such > queries. Thus, in general, a combination of a URN used to > name an existing resource, and a query string, provides no > assurance of persistence, and the combination should not be > considered a URN. This is where I wish the IETF could make a bam ban assertions that are not backed up by citations or evidence that is visible to the community. Let me state that in a way that more closely aligns with the reality I've seen and that has been pointed out to me. "Some existing resources that accept query strings (or fragment identifiers) do so in ways that are ill-considered and that do not assure persistence of the results. Other existing resources and uses do and are fine. The question is whether it is appropriate to try to ban the latter because there are a certain number (even a large number) of bad examples or if we should try to define things so that the good cases are allowed and we are more clear about why the bad cases are bad.". > The above, I submit, is reality. (There are probably some > other relevant and salient points which are also defensible as > reality.) Note that, while our realities may differ, part of mine is that I am extremely positive that, if the IETF says "don't do that, we think it is evil", we will mostly be ignored and fragments and queries in things that people will persist (sic) and that people will persist (sic) in calling URNs and using "urn:namespace:..." syntax to describe. If we say "the syntax is valid but one must be really, really, careful about how the things are used to ensure that persistence is maintained" and, ideally, explain why that is important, then we will affect the behavior of at least some of those who are trying to do The Right Thing. If se say "don't do it because we said so" and ban the syntax, it is nearly certain that we will be ignored by existing uses of fragments and/or queries and by lots of potential ones. And saying "even though that thing that conforms to the URI syntax and starts in 'urn:', it isn't a URN and you are forbidden to call it one" is even more useless. At least in my pragmatic, observational, reality. In the interest of even a weak approximation to brevity, I'll skip comments on your brainstorming for now. I think this does suggest that 2141bis needs an additional section that says something like the following. I've written this first cut on the assumption that we will allow fragment identifiers in queries in the syntax, but I believe, for the reasons explained above, that most of the material is needed regardless. Even if we decide to not allow fragment identifiers and/or namespaces, the relevant text below could probably usefully be adapted into a "why not" explanation (rather than having to rely on an IETF assertion of authority). Some of the other material above may be useful; I'd be happy to see it in the document if Peter and the WG believe that would help. I believe that, if this type of material is added to 2141bis, it should be explicitly identified as updating RFC 1737 by clarifying issues associated with the "requirements" of that document. "The notion of 'persistency' of a URN and its relationship to whatever resource it identifies is key to the nature of URNs as defined in this document and in the original functional specification [RFC1737]. That notion and the associated relationships are, however, somewhat elusive and are likely to depend, in practice, on conventions and the properties of particular namespaces. For example, if one can speak of replicated versions of a resource, transformation of a resource into a different form without affecting its content or nature, or even changes to a resource that don't alter what a URN identifies, one must either establish very specific conventions or move into the fundamental philosophical problem of when two objects can properly be considered "the same". In more practical terms, if replicated objects are considered different for some purposes but the same for others, the "Global uniqueness" criterion of RFC 1737 Section 2 may easily be violated. so the conventions about identity and uniqueness are important parts of the namespace definition even though, in practice, they may be better articulated for some namespaces than for others. "It is important to note that universal conventions are almost certainly impossible: there is no reason to assume that the conventions that apply for one namespace will apply to another. "These issues are a large part of what make fragment identifiers and queries problematic for many URN namespaces and create a requirement for very careful and namespace-sensitive definitions in the namespaces where they are allowed. A badly-designed fragment identifier may be inconsistent with the stability and persistence of a putative URN if replication or any changes all all to the names object are allowed. A badly-designed query string may require reference to information or resolution of objects outside the namespace, thereby undermining multiple key URN properties as identified in this document, RFC 1737, and elsewhere. In addition if ether were to follow trends common in contemporary usage of queries and sometimes fragments in URLs, the requirements of Section 3 of RFC 1737, especially those for Human transcribability and Simple comparison, could easily be violated. "To the extent feasible, definitions of particular URN namespaces should be clear about the relationships between the URN, the namespace, and the underlying objects; about the implications of replication and various changes to the named resources; and, if fragment identifiers or queries are allowed, how they should be constructed and constrained to preserve identifier persistency and to meet the other requirements of this specification and RFC 1737." That is obviously just a first cut, but maybe it will help us understand at least some of where we disagree, what the problems actually are, what problems can and cannot be solved (especially in a general, rather than per-namespace, way), and how to move forward. best, john From moore@network-heretics.com Sat Jun 15 06:59:33 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6205F21F9A80 for ; Sat, 15 Jun 2013 06:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LbieNr3LRuA for ; Sat, 15 Jun 2013 06:59:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 702B921F9A18 for ; Sat, 15 Jun 2013 06:59:28 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3865A20BF0; Sat, 15 Jun 2013 09:59:27 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Sat, 15 Jun 2013 09:59:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type; s=smtpout; bh=LO2f 7a5LqjGkqmfOwKUfAM0pSDE=; b=I2hE4E2g/GTEXhxVNI2wRuiEoWofAiLVNkaG IoAjCuljtDS/9XkSoJ9o6P1+Zq9ZWnhs6wyx+nW7rkaVGpxUTGKTem//98a5Sd8U x8ak8q5c7Npbkq1sO814Ed2SGaeBHwL3+QtTD4d1md4FielYii8Fny2HBi1F0sm4 ApRRtJs= X-Sasl-enc: fKv0sK8GCGobgoNC1O6St9NpONL5MvBKzrEiZ1UUC/bv 1371304763 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2E5E0680296; Sat, 15 Jun 2013 09:59:23 -0400 (EDT) Message-ID: <51BC7319.6020507@network-heretics.com> Date: Sat, 15 Jun 2013 09:58:49 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Julian Reschke References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <51BC49D0.6000504@gmx.de> In-Reply-To: <51BC49D0.6000504@gmx.de> Content-Type: multipart/alternative; boundary="------------090001030002020604060506" Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 13:59:33 -0000 This is a multi-part message in MIME format. --------------090001030002020604060506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/15/2013 07:02 AM, Julian Reschke wrote: > On 2013-06-14 21:51, Keith Moore wrote: >> ... >> 2. For various reasons, some people weren't happy with the URN syntax or >> framework that IETF decided on. One result was that the authors of RFC >> 3969 tried to broaden the definition of URNs in that document. >> ... > > s/3969/3986/ I assume. > > FWIW, RFC 3986 says in > : > > "1.1.3. URI, URL, and URN > > A URI can be further classified as a locator, a name, or both. The > term "Uniform Resource Locator" (URL) refers to the subset of URIs > that, in addition to identifying a resource, provide a means of > locating the resource by describing its primary access mechanism > (e.g., its network "location"). The term "Uniform Resource Name" (URN) > has been used historically to refer to both URIs under the "urn" > scheme [RFC2141], which are required to remain globally unique and > persistent even when the resource ceases to exist or becomes > unavailable, and to any other URI with the properties of a name. > > An individual scheme does not have to be classified as being just one > of "name" or "locator". Instances of URIs from any given scheme may > have the characteristics of names or locators or both, often depending > on the persistence and care in the assignment of identifiers by the > naming authority, rather than on any quality of the scheme. Future > specifications and related documentation should use the general term > "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]." > > > If you really really believe there's something to fix over here then > please make a concrete proposal. If I see a politically feasible way to fix it, I'll recommend it. Until then, I'm just going to recommend that this group's documents strictly limit their scope to URNs as defined in 2141. /But the main thing is, let's not get bogged down in discussions of RFC 3986. / It's a rathole. We should first figure out what changes are needed for RFC 2141 URNs, and only when we have that figured out should we worry about how to clearly describe that to people in light of the language in RFC 3986. [ skipping a lot of discussion that I think is a distraction... ] >> 7. Thus, the combination of a URN and a fragment identifier has no >> assurance of persistence. It follows that the combination of a URN and >> a fragment identifier cannot be a URN. > > I agree that it would be a bad idea. So is this about whether we allow > a URI using the "urn" scheme carrying a fragment identifier to be > called a URN? Yes. I started out thinking that if we had a string of the form urn:foo:bar#zot that we would just say the URN portion is urn:foo:bar and the fragment ID is #zot, but I eventually realized that people would inevitably treat the entire string urn:foo:bar#zot as the URN, and that would be bad. Now the question in my mind is, is it acceptable to use the urn: scheme for a URN carrying a fragment identifier if there's some assurance that the combination of the URN and the fragment identifier is persistent? Or will the existence in documents of URNs that look like urn:foo:bar#zot (but meeting the persistence criteria) encourage others to append fragment IDs that aren't persistent, to URNs that are persistent? (My suspicion is that the right answer for political purposes is the wrong answer if we want to encourage robustness and interoperability.) [skipping a bit more] > >> 9. At any rate, existing resources that accept query strings do not in >> general assure persistence of the results of such queries. Thus, in > > ...so this kind of terminology is misleading. In general, you use both > path and query to locate the resource. That's one way to look at it. But in practice people generally treat the search engine as a resource independent of the query string, so (for example) if they believe that they understand the nature of the queries, they feel free to substitute one query string for another. And this potentially has implications for the persistence properties of URNs containing query strings. > >> general, a combination of a URN used to name an existing resource, and a >> query string, provides no assurance of persistence, and the combination >> should not be considered a URN. >> >> The above, I submit, is reality. (There are probably some other >> relevant and salient points which are also defensible as reality.) >> ------------------------------------------------------ >> What's below this line is brainstorming. >> >> Now, given the above, I can see the need for up to four kinds of >> identifiers consisting of a "base" URN and a query string or fragment >> identifier: >> >> 1. URN + fragment identifier, where there is no assurance of the >> persistence of the fragment identifier over changes to the named >> resource. This combined identifier is not a persistent identifier, and >> thus not a URN. >> >> (One can argue that such an identifier isn't really useful. But I >> think it's potentially useful in the same sense that a reference to a >> document with section or page number can still be useful if that >> document was revised and the old section or page number is no longer >> quite correct... at least it gets you to the right document.) >> >> 2. URN + query string, where there is no assurance of the persistence >> of the results of the query service (e.g. that the query syntax wouldn't >> change or that the interpretation of the query wouldn't change). This >> combined identifier is not a persistent identifier, and thus not a URN. >> >> 3. URN + fragment identifier, under some hypothetical scheme for naming >> fragments that assured the persistence of the fragment identifier over >> changes to the resource, and for which the fragment identifiers were >> themselves recognizable as being persistent. (For example, one could >> define a new URN for each fragment.) >> This combined identifier would qualify as a URN. >> >> 4. URN + query string, where there were some (as yet undefined) >> assurance of persistence of query results (for all possible query >> strings). > > I don't like that direction. > A URI scheme can allow queries. In that case, not making the query > part of the scheme syntax would be totally confusing. > I've come to the same conclusion that "not making the query part of the scheme syntax" would be confusing, but that doesn't meant that we can't invent a new kind of URI, with a different prefix, that consists of a base URN and a query scheme or fragment identifier. > Not *calling* it a URN might work, but still: it's part of the URI, > but not part of the URN? Things might work better if you mint a new > term for the URN part that *is* persistent. Or better yet, don't go > there: do not allow queries purposes that conflict with the intent of > URNs. My concern is that if people see URNs that contain query strings, they'll assume that those query strings work just like those for http: URLs, and they'll start appending query strings to ordinary URNs. (Actually I'm much more concerned that they'll do this for fragment IDs than for query strings; I think the two cases are significantly different and the potential for fragment IDs to cause problems is much greater.) > > >> Of these, cases 1 and 2 are easily described. Cases 3 and 4 need more >> work (perhaps much more work). It's important that each of these four >> kinds of identifier be readily distinguished from one another. I can >> think of several different ways to do that. >> >> Common URI syntax, and common practice, is to combine a base URI with a >> fragment identifier or query string by appending the latter to the >> former. Using this convention for cases 1 and 2 seems likely to cause >> confusion, because the resulting identifier would begin with 'urn:' but >> not have the persistence properties required and expected of URNs. Using >> this convention for cases 3 and 4 might also cause confusion, because >> people see these identifiers, and it wouldn't be obvious to most people >> that a string like urn:foo:bar?zot was not simply the result of >> appending the query string ?zot to an ordinary URN. >> >> I'm not committed to this view, but I suspect that using the existing >> convention for either cases 1 and 2 or cases 3 and 4 would promote >> widespread misunderstanding. (And URNs are already suffering from a >> tremendous amount of misunderstanding...). So I'm guessing that we >> need (at least) two separate syntactic conventions for deriving >> identifiers that are based on URNs, neither of which is simply URN + >> fragment id or query string. (One can argue for additional conventions >> to serve as input to URN resolution, but that would require a much more >> rigid definition of URN resolution than has yet been attempted, so I >> think we can safely say that's a topic for future study.) >> >> One approach might be to define two new kinds of identifier: >> non-persistent URN-derived names and persistent URN-derived names. >> Assign them distinct prefixes like nudn: and pudn:. Define rules for (a) >> creating a NUDN from URN + query string or URN + fragment ID, and (b) >> interpreting an NUDN by extracting the embedded URN, resolving it, and >> interpreting the query string or fragment id in the context of the >> resource resulting from resolution of the URN. Perhaps the definition >> of 'pudn:' should be left for further study, but it might still be >> useful to mention them as a way of distinguishing them from NUDNs. And >> reinforce the notion that neither '#' and '?' should appear in a URN; >> and if they do appear, the result is at best undefined, or perhaps >> defined to be invalid. >> >> Strawman proposal for NUDN syntax (just to have something concrete to >> think about, or throw tomatoes at, not because I'm in love with it): >> >> nudn = 'nudn:' + base64-encoded-URN + '?' + query-string >> / 'nudn': + base64-encoded-URN + '#' + fragment-id >> >> >> I do think it's highly desirable that identifiers from cases 1 and 2 NOT >> begin with 'urn:' >> >> I don't think there's any way to solve this problem that's not ugly, but >> some ways are less ugly than others. > > Indeed. > > Before we go there: do we have a concrete use case that we would test > these ideas with? Use cases: 1. Joe would like to assign a URN to a resource that currently takes the form of an HTML document which is accessible via HTTP. That document contains fragment identifiers which aren't themselves maintained as persistent identifiers. Joe would like to be able to use that URN as a persistent reference to that resource and still be able to refer to particular fragments of that resource, even though he (hopefully) realizes that the combination of the URN and fragment ID are not persistent. 2. Carol would like to assign a URN to a resource that accepts query strings and returns different results depending on the query, in order to provide a persistent reference to that resource. She would also like to make it possible for URI references to that resource to contain query strings. However she has no assurance that the interpretation of those query strings by that resource will not change over time. 3. Jack would like to assign a URN to a resource that currently takes the form of an HTML document which is accessible via HTTP. However, Jack also wants to assign persistent identifiers to the named fragments of that document, and is willing to ensure that the fragment IDs in that document have the same persistence properties as URNs do, that fragment IDs are never reassigned within that document, and that the meanings of those fragment IDs are retained should that resource be produced in any other format that supports fragment IDs. (If necessary, Jack is even willing to register each of the combinations of base URN + fragment ID as separate URNs.... though whether things should work that way is a separate question.) 4. Alice would like to assign a URN to a resource that accepts query strings and returns different results depending on the query. However she also wants URIs that refer to that resource and contain a query string to also be persistent, and she's willing to provide assurances that the resource's interpretation of the query string will not change over time. 5. Ted knows of a resource that is named by a URN. That resource contains named fragments. Ted is authoring a document that references a particular portion of that resource and would like to provide in the document that he is authoring, a stable reference to a specific fragment of that resource. He's unsure as to whether he can simply append the fragment ID to the URN, but other URIs work that way.... 6. Bob knows of a resource that is named by a URN and which accepts query strings. Bob has found a particular query result interesting and would like to provide a reference that result by somehow composing a URI from that URN and query string. --------------090001030002020604060506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/15/2013 07:02 AM, Julian Reschke wrote:
On 2013-06-14 21:51, Keith Moore wrote:
...
2. For various reasons, some people weren't happy with the URN syntax or
framework that IETF decided on.   One result was that the authors of RFC
3969 tried to broaden the definition of URNs in that document.
...

s/3969/3986/ I assume.

FWIW, RFC 3986 says in <http://greenbytes.de/tech/webdav/rfc3986.html#URLvsURN>:

"1.1.3. URI, URL, and URN

A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name.

An individual scheme does not have to be classified as being just one of "name" or "locator". Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]."


If you really really believe there's something to fix over here then please make a concrete proposal.

If I see a politically feasible way to fix it, I'll recommend it.  Until then, I'm just going to recommend that this group's documents strictly limit their scope to URNs as defined in 2141.   

But the main thing is, let's not get bogged down in discussions of RFC 3986.   It's a rathole.   We should first figure out what changes are needed for RFC 2141 URNs, and only when we have that figured out should we worry about how to clearly describe that to people in light of the language in RFC 3986.

[ skipping a lot of discussion that I think is a distraction... ]
7. Thus, the combination of a URN and a fragment identifier has no
assurance of persistence.   It follows that the combination of a URN and
a fragment identifier cannot be a URN.

I agree that it would be a bad idea. So is this about whether we allow a URI using the "urn" scheme carrying a fragment identifier to be called a URN?

Yes.  I started out thinking that if we had a string of the form urn:foo:bar#zot that we would just say the URN portion is urn:foo:bar and the fragment ID
is #zot, but I eventually realized that people would inevitably treat the entire string urn:foo:bar#zot as the URN, and that would be bad.

Now the question in my mind is, is it acceptable to use the urn: scheme for a URN carrying a fragment identifier if there's some assurance that the combination of the URN and the fragment identifier is persistent?    Or will the existence in documents of URNs that look like urn:foo:bar#zot (but meeting the persistence criteria) encourage others to append fragment IDs that aren't persistent, to URNs that are persistent?     (My suspicion is that the right answer for political purposes is the wrong answer if we want to encourage robustness and interoperability.)

[skipping a bit more]


9. At any rate, existing resources that accept query strings do not in
general assure persistence of the results of such queries.   Thus, in

...so this kind of terminology is misleading. In general, you use both path and query to locate the resource.

That's one way to look at it.  But in practice people generally treat the search engine as a resource independent of the query string, so (for example) if they believe that they understand the nature of the queries, they feel free to substitute one query string for another.   And this potentially has implications for the persistence properties of URNs containing query strings.



general, a combination of a URN used to name an existing resource, and a
query string, provides no assurance of persistence, and the combination
should not be considered a URN.

The above, I submit, is reality.   (There are probably some other
relevant and salient points which are also defensible as reality.)
------------------------------------------------------
What's below this line is brainstorming.

Now, given the above, I can see the need for up to four kinds of
identifiers consisting of a "base" URN and a query string or fragment
identifier:

1.  URN + fragment identifier, where there is no assurance of the
persistence of the fragment identifier over changes to the named
resource.   This combined identifier is not a persistent identifier, and
thus not a URN.

(One can argue that such an identifier isn't really useful.   But I
think it's potentially useful in the same sense that a reference to a
document with section or page number can still be useful if that
document was revised and the old section or page number is no longer
quite correct... at least it gets you to the right document.)

2.  URN + query string, where there is no assurance of the persistence
of the results of the query service (e.g. that the query syntax wouldn't
change or that the interpretation of the query wouldn't change).   This
combined identifier is not a persistent identifier, and thus not a URN.

3. URN + fragment identifier, under some hypothetical scheme for naming
fragments that assured the persistence of the fragment identifier over
changes to the resource, and for which the fragment identifiers were
themselves recognizable as being persistent.   (For example, one could
define a new URN for each fragment.)
This combined identifier would qualify as a URN.

4. URN + query string, where there were some (as yet undefined)
assurance of persistence of query results (for all possible query strings).

I don't like that direction.
A URI scheme can allow queries. In that case, not making the query part of the scheme syntax would be totally confusing.


I've come to the same conclusion that "not making the query part of the scheme syntax" would be confusing, but that doesn't meant that we can't invent a new kind of URI, with a different prefix, that consists of a base URN and a query scheme or fragment identifier.

Not *calling* it a URN might work, but still: it's part of the URI, but not part of the URN? Things might work better if you mint a new term for the URN part that *is* persistent. Or better yet, don't go there: do not allow queries purposes that conflict with the intent of URNs.

My concern is that if people see URNs that contain query strings, they'll assume that those query strings work just like those for http: URLs, and they'll start appending query strings to ordinary URNs.   (Actually I'm much more concerned that they'll do this for fragment IDs than for query strings; I think the two cases are significantly different and the potential for fragment IDs to cause problems is much greater.)





Of these, cases 1 and 2 are easily described.  Cases 3 and 4 need more
work (perhaps much more work).   It's important that each of these four
kinds of identifier be readily distinguished from one another.  I can
think of several different ways to do that.

Common URI syntax, and common practice, is to combine a base URI with a
fragment identifier or query string by appending the latter to the
former.   Using this convention for cases 1 and 2 seems likely to cause
confusion, because the resulting identifier would begin with 'urn:' but
not have the persistence properties required and expected of URNs. Using
this convention for cases 3 and 4 might also cause confusion, because
people see these identifiers, and it wouldn't be obvious to most people
that a string like urn:foo:bar?zot was not simply the result of
appending the query string ?zot to an ordinary URN.

I'm not committed to this view, but I suspect that using the existing
convention for either cases 1 and 2 or cases 3 and 4 would promote
widespread misunderstanding.   (And URNs are already suffering from a
tremendous amount of misunderstanding...).   So I'm guessing that we
need (at least) two separate syntactic conventions for deriving
identifiers that are based on URNs, neither of which is simply URN +
fragment id or query string. (One can argue for additional conventions
to serve as input to URN resolution, but that would require a much more
rigid definition of URN resolution than has yet been attempted, so I
think we can safely say that's a topic for future study.)

One approach might be to define two new kinds of identifier:
non-persistent URN-derived names and persistent URN-derived names.
Assign them distinct prefixes like nudn: and pudn:. Define rules for (a)
creating a NUDN from URN + query string or URN + fragment ID, and (b)
interpreting an NUDN by extracting the embedded URN, resolving it, and
interpreting the query string or fragment id in the context of the
resource resulting from resolution of the URN.   Perhaps the definition
of 'pudn:' should be left for further study, but it might still be
useful to mention them as a way of distinguishing them from NUDNs.  And
reinforce the notion that neither '#' and '?' should appear in a URN;
and if they do appear, the result is at best undefined, or perhaps
defined to be invalid.

Strawman proposal for NUDN syntax (just to have something concrete to
think about, or throw tomatoes at, not because I'm in love with it):

nudn =  'nudn:' + base64-encoded-URN + '?' + query-string
           /   'nudn': + base64-encoded-URN + '#' + fragment-id


I do think it's highly desirable that identifiers from cases 1 and 2 NOT
begin with 'urn:'

I don't think there's any way to solve this problem that's not ugly, but
some ways are less ugly than others.

Indeed.

Before we go there: do we have a concrete use case that we would test these ideas with?

Use cases:

1.  Joe would like to assign a URN to a resource that currently takes the form of an HTML document which is accessible via HTTP.  That document contains fragment identifiers which aren't themselves maintained as persistent identifiers.   Joe would like to be able to use that URN as a persistent reference to that resource and still be able to refer to particular fragments of that resource, even though he (hopefully) realizes that the combination of the URN and fragment ID are not persistent.

2. Carol would like to assign a URN to a resource that accepts query strings and returns different results depending on the query, in order to provide a persistent reference to that resource.    She would also like to make it possible for URI references to that resource to contain query strings.   However she has no assurance that the interpretation of those query strings by that resource will not change over time.  

3. Jack would like to assign a URN to a resource that currently takes the form of an HTML document which is accessible via HTTP.   However, Jack also wants to assign persistent identifiers to the named fragments of that document, and is willing to ensure that the fragment IDs in that document have the same persistence properties as URNs do, that fragment IDs are never reassigned within that document, and that the meanings of those fragment IDs are retained should that resource be produced in any other format that supports fragment IDs.    (If necessary, Jack is even willing to register each of the combinations of base URN + fragment ID as separate URNs.... though whether things should work that way is a separate question.)

4. Alice would like to assign a URN to a resource that accepts query strings and returns different results depending on the query.  However she also wants URIs that refer to that resource and contain a query string to also be persistent, and she's willing to provide assurances that the resource's interpretation of the query string will not change over time.

5. Ted knows of a resource that is named by a URN.   That resource contains named fragments.   Ted is authoring a document that references a particular portion of that resource and would like to provide in the document that he is authoring, a stable reference to a specific fragment of that resource.   He's unsure as to whether he can simply append the fragment ID to the URN, but other URIs work that way....

6. Bob knows of a resource that is named by a URN and which accepts query strings.   Bob has found a particular query result interesting and would like to provide a reference that result by somehow composing a URI from that URN and query string.

--------------090001030002020604060506-- From moore@network-heretics.com Sat Jun 15 08:51:47 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DF021F9DE2 for ; Sat, 15 Jun 2013 08:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvshuJcQmTUd for ; Sat, 15 Jun 2013 08:51:42 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id BE34A21F9DD2 for ; Sat, 15 Jun 2013 08:51:41 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8A69E20BD2; Sat, 15 Jun 2013 11:51:40 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 15 Jun 2013 11:51:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=DR0sY7RhdV4C2OGr2Cq8X7 Z7X8o=; b=TFRL5i4ETWgcieTeirQyNcnI1Gl2XWWSxzDIraMgqcUtsdWZi9g+y/ hdx/FcN6Uw5roWGDsigZd+18FbqcwTBjOOS+jPG1/GDH/0qzCdrAe16qQxbvxGk4 Y0fhhDhTbhDSeY+UyVY3vWJYoWtn16NdN95v7iOzqNR1FlGTlvv4s= X-Sasl-enc: pOZcNZFFaRUFCYo3L0U/HPNSPsPkrFgavoNd7tTn/kOZ 1371311497 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 1792668023B; Sat, 15 Jun 2013 11:51:36 -0400 (EDT) Message-ID: <51BC8D66.9050000@network-heretics.com> Date: Sat, 15 Jun 2013 11:51:02 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John C Klensin References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> In-Reply-To: <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 15:51:47 -0000 On 06/15/2013 09:15 AM, John C Klensin wrote: > Keith, > > It is starting to feel as if we are either reading different > documents with the same names and identifiers or that we are > somehow reading the same documents very differently. Key > examples and some other discussion inline below. I also get the impression that some of us are talking about different things and/or working from vastly different assumptions. It appears to me that 3986 is a significant source of the confusion. I might be wrong, but I doubt it - because people keep talking about 3986 and quoting text from it as if its authors actually understood URNs and the implications of what they were saying for URNs, when it's clear to me that they did not. Note that I haven't mentioned draft-ietf-urnbis-rfc2141bis-urn-05 (or any version) at all. To me it seems premature to wordsmith that document (at least about these issues) until the issues regarding persistence of URNs in combination with fragment identifiers and query strings are well understood. (I have referred to "2141bis" but was using it in a generic sense of "the successor to RFC 2141", not to a specific I-D. I can see how that might have caused confusion.) > > 3. Even if you accept (as RFC 3969 states) that the name URN > applies to things other than those defined in 2141, the > situation we were left with is both confusing and cumbersome > to discuss. The identifiers defined in RFC 2141 have unique > properties, by design, which do not necessarily apply to other > persistent URI-like identifiers. And it's cumbersome to > discuss RFC 2141 identifiers specifically (for the purpose of > updating RFC 2141, or for any other purpose) while still being > consistent with the language in RFC 3969. You end up either > saying "for the purpose of this document, URN refers to the > identifiers defined in RFC 2141, language in RFC 3969 > notwithstanding" (inviting confusion from those who miss that > restriction), or you end up saying something like "URNs as > defined in RFC 2141" every time you need to refer to that kind > of identifier. > Yes, that is a bit of an editorial challenge. I don't see it as > a serious substantive problem because I don't think anyone is > claiming that draft-ietf-urnbis-rfc2141bis-urn should be > anything but 2141bis... with adjustments made to conform > 2141-style URNs to the requirements of 3986. I seriously doubt that the latter is even possible, the misunderstanding of URNs in 3986 is so great. But let's table that issue for now, figure out how to deal with query strings and fragment IDs in URNs without harming the persistence properties of URNs, and then see if it's possible to do that without 2141bis taking exception to 3986. (I do think it's reasonable for 2141bis to update 3986 if there's a need to do that.) >> Regardless of what RFC 3969 says, the identifiers most often >> associated with the term URN are undoubtedly those that begin >> with 'urn:' and have a syntax consistent with RFC 2141. >> Trying to say that there are URNs that don't begin with 'urn:' >> is like saying that there are other HTTP URLs that don't begin >> with 'http:'. Yes, it's true in a sense, but it's just silly >> and confusing and there's no good reason to define things that >> way. > But, as far as I can tell, draft-ietf-urnbis-rfc2141bis-urn-05 > doesn't do that and in fact carefully avoids it. So the above > is either an attack on 3986 (and hence out of scope for the WG) > or just isn't relevant. The only reason I'm "attacking" 3986 is that it seems to be a significant source of confusion that's making this WG have a more difficult time understanding the current topics of discussion. We can't address the problems with URNs and fragment IDs and query strings unless/until we have a shared understanding of what those problems are, and it seems to me that 3986 has muddied the waters considerably. But as I just said in another reply, I think we should just stop talking about 3986, as it has become a rathole. > >> Also, regardless of what RFC 3969 says, URNs as defined in RFC >> 2141 weren't designed to be used with fragment identifiers or >> query strings - or at least, we didn't manage to define how >> that would work, and the reason that we didn't define how that >> would work is because there wasn't an obvious interpretation >> that didn't kill the properties we wanted for URNs. So we >> declined to do that in RFC 2141, and in trying to generalize >> URI syntax, RFC 3969 didn't address those issues either. > And here we get to what I think are two of the core issues. > Let's separate them into two questions: > > (i) If there were no syntax restrictions imposed by > 2141, 3986, or anything else, would fragment identifiers > and/or queries be appropriate for URNs? > > (ii) Is 3986 required to authorize fragments or queries > in the URN syntax and, if so, is that a serious and > problematic incompatible change? > > Let me address the second here and the first below. > > You read the statements in 2141 (or perhaps some oral tradition > to which the rest of us don't have access) as prohibiting > fragment identifiers and queries. When I read what I hope are > the same statements, I conclude that there are lots of ways to > say "prohibit". One of them involves the term "excluded", which > is exactly what 2141 says about a number of characters in its > Section 2.4. But what it says about "?" and "#" is to > identify them with purposes defined in RFC 1630 -- no appeal to > presumed 3986 revisionism is required-- and "has not yet debated > the applicability and precise semantics of those purposes as > applied to URNs". It then says "these characters are RESERVED > for future developments". To me, those are statements that > imply that those future developments are anticipated, even > though no timeframe is given for them (and they might not > happen). Yes, I have a similar interpretation, and agree that RESERVED does not imply "prohibited for all time". But of course the reason they were RESERVED is that we didn't know at the time how to make them work and retain the persistence properties of URNs. It's not yet clear to me that we know how to do that now, but at least I think I personally understand the issues better than I did then. (I actually misread the ABNF in 2141 the first time I looked at it recently and missed the term in the production for , so it appeared to me that '?' and '#' could not appear in an NSS.) > >> ... >> 6. Fragment identifiers as used in existing content-types were >> not designed to be persistent across changes to the document. >> For identifiers to have persistence there needs to be some >> discipline in assigning meaning to them initially and in not >> reusing them in ways inconsistent with their originally >> assigned meanings. If there is any such convention for >> fragment identifiers, I'm not aware of it, but it certainly >> isn't widely used. Given the existence and utility of other >> kinds of identifiers which are not persistent and should not >> be so, I also believe that persistent identifiers need to be >> readily distinguished from non-persistent identifiers. >> Again, I'm not aware of a convention for doing this, though I >> hypothesize that one could exist. > I think you are creating a strawman here and then demolishing > it. There is no question, in my mind, at least, that using, > e.g., a character offset fragment identifier would be truly > stupid in a context that requires persistence, URN or > otherwise. And yet, people are accustomed to being able to compose URIs out of base URIs and fragment IDs without having to worry about whether the result will be valid. They don't know that it's stupid to do that, and nothing that 2141bis says is likely to affect the vast majority of users that are currently accustomed to appending fragment IDs to URIs. > But that doesn't imply that, for some URN types > (namespaces) stable fragment identifiers cannot be properly > identified and defined. I doubt that it's appropriate to make this a namespace-specific property. That seems to have a lot of really ugly consequences, like requiring both URN-parsing software and ordinary users to know which URN namespaces permit use of fragments and query strings. Though of course there's nothing wrong with doing a detailed analysis of those consequences. > Second, even after rereading 2141 and > 1737, I'm not sure how far one can go in the direction of an > identifier that is "persistent across changes in a document" > because even that statement takes one very far in the direction > of needing a universal theory about what changes are still "the > same document" and what changes make new documents. This problem already exists for URNs even without fragment IDs or query strings, and I don't think I've ever seen it satisfactorily articulated. (Actually it exists for naming in general - a name for something is generally too brief to including information about how specific it is.) In my mind at least, a URN shouldn't be associated with a document or resource, but rather with a resource definition that explains exactly what is being named, and that resource definition is part of what you should get back when you resolve the URN... so that the client has a better idea of how specific that particular URN is (e.g. is it a particular document or a particular version of a document or a particular rendering of a particular version of a document, or something narrower or broader?) But in practice we tend to talk about URNs being persistent across changes in the document when we actually mean something more subtle than that, much as we talk about URNs being persistent when we're really referring to a property of the binding between the URN and the resource [definition]. > More important, as soon as you say "persistent identifier" and > "changes to object" in the same context, you transport us all to > to the edge, not of rathole, but of a bottomless pit. > "Persistence" of an identifier is clear when there is a single, > unique, object and the only thing that changes is its location. > That is where one of the major threads that led to URNs started > when web objects were considered -- URLs were just not right > when one considered content that might be relocated, unchanged, > from one server (and DNS name) to another. But, as soon as one > talks about two objects that are alleged to be identical or > changes in one object, the "persistence" and object-binding > validity of the identifier become fairly deep questions that > have plagued archivists, classifiers, and philosophers for > centuries... questions that ultimately have no clear answers > except in the axioms and postulates of object-type-specific > axiomatic systems. Indeed, those are very deep and long-standing questions, and I've been involved in many long discussions about them over the years. But for better or worse, it was an explicit and strong consensus of the original URN working group that URNs weren't just to be bound to a specific document independent of location or replication, that they could reasonably refer to resources whose content intentionally changed over time but was still the same in some sense. The example of "today's weather" was often cited. Perhaps it's not readily apparent from RFC 2141, but if memory serves, other RFCs about URNs reflect that consensus. (FWIW, I've also had it forcefully argued to me that you can't make a useful identifier that only refers to a specific unchanging representation of content independent of location or replication, that if such identifiers were widely used, pressures would inevitably cause such identifiers to be used more broadly than intended. I don't agree with that view, but it's not like the argument was completely without merit.) > Another key reason why I shut down the > original URI WG in the hope of saving the work as that several > of the efforts that were underway appeared to have comprehensive > solutions to the "can it change and be the same thing" and "are > two objects actually identical" questions in the critical path > of a protocol or identifier type questions -- a WG that could > safely be predicted to go on for years and indeed centuries and > never converge was just not considered acceptable in the IETF of > the time. There's lots of both history and philosophy here, certainly more than we can reasonably relate to this group via email. (and my, how times have changed!) If anyone else is actually interested in rehashing history or philosophy, there's a high probability that I'll be in Berlin and I'd be happy (or at least willing) to discuss those things in person. But I've seen them rehashed in email list discussions enough times to convince me that there's very marginal utility in doing so, especially these days when a smartphone is the device most frequently used to read email, and people's attention spans for email seem to have diminished considerably. (not that I'm not also guilty of that.) >> 7. Thus, the combination of a URN and a fragment identifier >> has no assurance of persistence. It follows that the >> combination of a URN and a fragment identifier cannot be a URN. > That does not follow at all. I realized after I sent that message that I didn't state it precisely enough. What I meant was that if you have a URN for some resource (not one that you control) and you know of a fragment ID within that resource, it's perfectly reasonable for you to want to create a reference (URI) that combines the two - but there's no assurance that such a reference (URI) will be persistent. And so, for example, if you're used to seeing HTTP URLs constructed as base URL + fragment ID, and you think you can construct a reference consisting of a URN and a fragment ID in a similar way, what you end up producing is something that looks like a URN (and begins with urn:) but doesn't have the properties of URNs. And that, I think, is a significant problem. Note that if you don't care about users being able to compose specific URIs from a base URN + a fragment ID, and you don't care about being able to extract the base URN from a URI consisting of a URN and a fragment ID, there's no issue. Simply assign a separate URN to each fragment of the document, in addition to the URN for the entire document, with no obvious relationship between the URNs used to name fragments and the URN used to name the whole document. Then when the URNs used to name fragments get resolved, they get resolved to URLs that contain fragment IDs that are appropriate for the currently accessible version of the document. Similarly, a URN without a query string could resolve to a URL that contained a query string, so you could define any number of URNs for specific queries made to a resource. It's only because we want to be able to compose URIs by adding fragment IDs and query strings, or decompose URIs that contain fragment IDs and query strings, that we have this problem of trying to figure out how to shoehorn fragment IDs and query strings into URNs. So being able to compose those URIs is an important property, and not just for the resource owner. >> 8. One can argue that the persistence of an identifier >> consisting of a URN and a query string could actually be >> persistent, if the resource named by the URN were defined in >> ... > I think that query strings associated with URNs are far more > problematic than fragment identifiers because fragment > identifiers (at least by historical convention) point to > something _within_ and object or some subdivision of it. > Queries, as your example (not quoted here) suggests (at least as > I interpret it), can, in principle, be used to take the rest of > the URI as input and return something completely different. > Defining such a situation in a way that would assure persistence > is hard at best. > > Extending your example a bit and combining it with my > hypothetical "book" URN, one could imagine > urn:book:....?reverse-citation-index > > which would return all of the known books or articles that cite > that book. Since a new citation could be added at any time, the > practical persistency problems of that query are horrible even > if the query could be well-defined (it can't, at least without a > definition of the sources to be searched, but that is just a > property of my choice of a simple, but sloppy, example). Yes, but the _meaning_ of the URN would remain the same, and (as far as I can tell) that's what's important. I don't see how that's different than the oft-cited URN for the current weather map. (Interesting example, though) To me main problem with making URNs with query strings persistent is that the very act of assigning a URN to the resource puts responsibility on the resource maintainer to not change the interpretation of query strings, even (I suspect) to the point of defining results for query strings whose results were previously-undefined. In other words, you can't extend the query language. Perhaps more to the point, I'm wary of saying that the act of assigning a URN to a resource constrains how that resource can evolve. In particular, I don't think there should be any constraint on who can assign a URN to something. Whoever assigns the URN doesn't necessarily control the resource. But I'll readily admit (and these examples illustrate) that it might be difficult to get consensus on what URNs that contain query strings mean, and that this is probably more subtle than defining what it means to have persistent URNs that contain visible fragment IDs. > >> 9. At any rate, existing resources that accept query strings >> do not in general assure persistence of the results of such >> queries. Thus, in general, a combination of a URN used to >> name an existing resource, and a query string, provides no >> assurance of persistence, and the combination should not be >> considered a URN. > This is where I wish the IETF could make a bam ban assertions > that are not backed up by citations or evidence that is visible > to the community. > > Let me state that in a way that more closely aligns with the > reality I've seen and that has been pointed out to me. > > "Some existing resources that accept query strings (or > fragment identifiers) do so in ways that are > ill-considered and that do not assure persistence of the > results. Other existing resources and uses do and are > fine. This doesn't contradict what I wrote above. The point is, people composing URIs out of base URIs and query strings can't be assumed to be the people who maintain the resources being referred to. And those people generally don't know whether the resource is constructed in such a way as to assure persistence of the resource across the entire space of possible query strings. > The question is whether it is appropriate to try > to ban the latter because there are a certain number > (even a large number) of bad examples or if we should > try to define things so that the good cases are allowed > and we are more clear about why the bad cases are bad.". I don't want to try to ban any practice. I think there are valid use cases for all of these practices. What I want to do is figure out how to permit these practices (including the practice of users composing URIs from base URIs + query string that they supply) without degrading the notion that urn: means "persistent identifier" because I think that's a very important property of URNs. > >> The above, I submit, is reality. (There are probably some >> other relevant and salient points which are also defensible as >> reality.) > Note that, while our realities may differ, part of mine is that > I am extremely positive that, if the IETF says "don't do that, > we think it is evil", we will mostly be ignored and fragments > and queries in things that people will persist (sic) and that > people will persist (sic) in calling URNs and using > "urn:namespace:..." syntax to describe. If we say "the syntax > is valid but one must be really, really, careful about how the > things are used to ensure that persistence is maintained" and, > ideally, explain why that is important, then we will affect the > behavior of at least some of those who are trying to do The > Right Thing. If se say "don't do it because we said so" and ban > the syntax, it is nearly certain that we will be ignored by > existing uses of fragments and/or queries and by lots of > potential ones. And saying "even though that thing that > conforms to the URI syntax and starts in 'urn:', it isn't a URN > and you are forbidden to call it one" is even more useless. At > least in my pragmatic, observational, reality. I don't want to have to defend myself against implied accusations that I was trying to "ban" something, when what I'm really trying to do is preserve and improve the utility of URNs. Banning useful practices is not my goal. Trying to encourage those useful practices to be done in ways that don't cause problems is my goal. > > In the interest of even a weak approximation to brevity, I'll > skip comments on your brainstorming for now. > > I think this does suggest that 2141bis needs an additional > section that says something like the following. I've written > this first cut on the assumption that we will allow fragment > identifiers in queries in the syntax, but I believe, for the > reasons explained above, that most of the material is needed > regardless. Even if we decide to not allow fragment identifiers > and/or namespaces, the relevant text below could probably > usefully be adapted into a "why not" explanation (rather than > having to rely on an IETF assertion of authority). Some of the > other material above may be useful; I'd be happy to see it in > the document if Peter and the WG believe that would help. I > believe that, if this type of material is added to 2141bis, it > should be explicitly identified as updating RFC 1737 by > clarifying issues associated with the "requirements" of that > document. > > "The notion of 'persistency' of a URN and its > relationship to whatever resource it identifies is key > to the nature of URNs as defined in this document and in > the original functional specification [RFC1737]. That > notion and the associated relationships are, however, > somewhat elusive and are likely to depend, in practice, > on conventions and the properties of particular > namespaces. Again, I really don't think this is naturally, or should be defined as, a property of the namespace. To the extent that it appears to be a property of the namespace, it might be because some namespaces are associated with particular kinds of resources. But that's a corner case, not how URNs are supposed to work in general. In principle, any URN can refer to any kind of resource. If there are particular namespaces that constrain themselves as to only assign URNs to specific kinds of resources that have specific persistence properties, that's their business, but we shouldn't define general URN behavior in the presence of fragment IDs and/or query strings in such a way that it only works for those corner cases. Keith From john-ietf@jck.com Sat Jun 15 14:52:46 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC9B21F9E23 for ; Sat, 15 Jun 2013 14:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.285 X-Spam-Level: X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trJfpKDJ6zGp for ; Sat, 15 Jun 2013 14:52:40 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 57FD421F9DEE for ; Sat, 15 Jun 2013 14:52:39 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UnyOg-000Hcq-UH; Sat, 15 Jun 2013 17:52:35 -0400 Date: Sat, 15 Jun 2013 17:52:29 -0400 From: John C Klensin To: Keith Moore , Julian Reschke Message-ID: In-Reply-To: <51BC7319.6020507@network-heretics.com> References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <51BC49D0.6000504@gmx.de> <51BC7319.6020507@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 Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 21:52:46 -0000 --On Saturday, June 15, 2013 09:58 -0400 Keith Moore wrote: >... >> Not *calling* it a URN might work, but still: it's part of >> the URI, but not part of the URN? Things might work better >> if you mint a new term for the URN part that *is* >> persistent. Or better yet, don't go there: do not allow >> queries purposes that conflict with the intent of URNs. > > My concern is that if people see URNs that contain query > strings, they'll assume that those query strings work just > like those for http: URLs, and they'll start appending query > strings to ordinary URNs. I want to address the points I see in the above because it seems symptomatic of a number of other things. The subsequent sentence (below) identifies an interesting (to me) point of disagreement. I think we can agree that there are ignorant and stupid people in the world who will do stupid things, and that some of those stupid things will be the result of someone's looking at one case or example and making an inference from it that will lead them astray. While a mechanism for stamping out ignorance and stupidity, and even ordinary bad inferences, would create an opportunity to vastly improve the world, such a mechanism is out of scope and almost certainly outside the competence of this WG. The question is then what to do about those ignorant and/or stupid people and their potential for harm. One answer, consistent, IMO, with some of what you are suggesting, is to prohibit features that might be perfectly reasonable in context simply because they might be misinterpreted and used to justify something that is problematic. There is an argument for that sort of approach: in at least one cultural tradition, prohibiting something reasonable because an ignorant person might mistake it for something else and make a bad inference is known as "building a wall around" something that is considered important. Enough of that sort of wall-building and lead to absurd conclusions and, worse, prohibiting enough obviously reasonable situations that educated and reasonable people decide to ignore the rules entirely. In protocol design, that outcome is sometimes known as "shooting oneself in the foot" because it leads the smart people who want to faithfully implement the protocol to not do so while doing little to cure or alleviate ignorance or stupidity. Another approach is to fiddle around with names and categories. "That creature out there may look like a duck, walk like a duck, and sound like a duck, but you are forbidden to call it a duck." It doesn't work either: the smart, careful, and sophisticated people who are trying to produce good-faith implementations don't need the terminology games and the ignorant and stupid ones (and those who are easily confused) will get confused and ignore those distinctions. Worse, if someone does something stupid or harmful, it will make absolutely no difference to the Internet whether they call it a duck, a goose, or a URN. In addition to the above and the stupidity and ignorance factors, I suggest that this is just a less theoretical world than it once was. If someone has something that they sincerely believe is a real customer requirement that would be satisfied with, e.g., a fragment identifier with a persistent resource identifier and have seen URNs, they are extremely likely to use a fragment identifier with the URN. If they even manage to read out spec and all we have to say is "don't do that", we will, in the vast majority of cases, lose. Like it or not, in today's Internet, perceived customer requirements will trump theoretical models of how things are supposed to work almost every time. I am suggesting a different plan and suggesting it because it has reasonable odds of being successful among those who actually might pay attention of us. It is that we make these things valid and do so in a way that is as simple and straightforward as possible, with no hair-splitting. If we have to hold our noses to do that, we get good at nose-holding rather than getting good at telling folks what they cannot do. Then we explain, with as much clarity as possible, some examples of ways to use those identifiers that will work well, some that will be problematic, and why the latter are a bad idea. The "bad idea" part of that explanation should focus more on "bad for customers and users" than on "bad for the Internet" and should focus more on "bad for the Internet" than on "offends IETF religious beliefs" or even "violates the principles of RFC 1737" because, frankly, almost no one cares. For those who have any respect for what we do and/or who choose to read our documents, that will help because we will be giving them good advice about what will help them and their customers and they will be inclined to follow it. For those who don't... well, nothing will make any difference and we just need to accept that as part of our reality. > (Actually I'm much more concerned > that they'll do this for fragment IDs than for query strings; > I think the two cases are significantly different and the > potential for fragment IDs to cause problems is much greater.) Interesting. I would have said exactly the opposite. I think it is possible to write advice about fragment identifiers that makes it clear that: * The URN without the fragment identifier must be persistent, stable, and meet the criteria of 2141 and 1737. * The proposed fragment identifier must be structured as a pointer into the resource identified by the rest of the URN, not something that lies outside that resource or modifies it in any way. * The semantics of the proposed fragment identifier must be natural to the resource type and must neither change the semantics of the resource nor require that it have characteristics that are not natural to the resource. URN:Rabbit:...#Chapter3 must fail, not identify the right rear leg. * The semantics of the proposed fragment identifier must be stable and persistent until any transformation of the resource that does not invalidate the URN itself. (See my earlier example about the difference between book chapters and page references if transformation of book content to different media are considered to not change the resource.) * The fragment identifier, by the nature of fragment identifiers, should not require a process for interpreting it that is not natural, internal, and natural to the resource. Now, that may not be the right set of rules, but the point is that rules can be written because the natural use of a fragment identifier is to select a part of a resource by some marker or property that is intrinsic to that resource. I don't know how to write a similar set of rules for queries because they often (perhaps usually) imply some process or processor that is external to the resource. As soon as one says something like "search engine" in conjunction with a query, a high standard for persistence and predictability will require that one identify the search mechanism and its properties and that those be stable too. The final proposed rule above could be restated as "fragment identifiers must not be search specifications in disguise". So, personally, I'm a lot more afraid of queries than I am of fragments. To go a bit further, I don't think there is any point second-guessing 3986 and its predecessors at this point, but I think we would have been a lot better off with a query syntax that embedded a URI rather than a query that is part of a URI. The observation that may URIs that contain queries today contain embedded URIs as part of the query only reinforces that belief. john From moore@network-heretics.com Sat Jun 15 23:14:15 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176C921F9E01 for ; Sat, 15 Jun 2013 23:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPtL99V-SvrE for ; Sat, 15 Jun 2013 23:14:09 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id BAA1021F9CDE for ; Sat, 15 Jun 2013 23:14:08 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 07A402096F; Sun, 16 Jun 2013 02:14:08 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 16 Jun 2013 02:14:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=pjMbQWQbU1Q4Qx0HPU9MmJ 8KTrs=; b=mRTiJ/LFZednQxNFS0abe6JHRUYXtloeBVG1kmpoRegfJal/BpTVMM Q8RV/HZiGEhQa31cRcq0qTU8EoBUN5G2xhbZXA5A/7IeADLR4sUjp637kJ4U8iVi A5x9CE8fAAVLa6y9Mpo7u0MjljDZcYx2OmVHBc6I7zt2Yml4U4XbI= X-Sasl-enc: SsQwYILtVGg0Yj3MXSNtThsVwzroJJ5nO07/T8WeCzXH 1371363246 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 07E44C00E7F; Sun, 16 Jun 2013 02:14:05 -0400 (EDT) Message-ID: <51BD578A.5020408@network-heretics.com> Date: Sun, 16 Jun 2013 02:13:30 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John C Klensin References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <51BC49D0.6000504@gmx.de> <51BC7319.6020507@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 06:14:15 -0000 On 06/15/2013 05:52 PM, John C Klensin wrote: > > --On Saturday, June 15, 2013 09:58 -0400 Keith Moore > wrote: > >> ... >>> Not *calling* it a URN might work, but still: it's part of >>> the URI, but not part of the URN? Things might work better >>> if you mint a new term for the URN part that *is* >>> persistent. Or better yet, don't go there: do not allow >>> queries purposes that conflict with the intent of URNs. >> My concern is that if people see URNs that contain query >> strings, they'll assume that those query strings work just >> like those for http: URLs, and they'll start appending query >> strings to ordinary URNs. > [...] > > I think we can agree that there are ignorant and stupid people > in the world who will do stupid things, and that some of those > stupid things will be the result of someone's looking at one > case or example and making an inference from it that will lead > them astray. While a mechanism for stamping out ignorance and > stupidity, and even ordinary bad inferences, would create an > opportunity to vastly improve the world, such a mechanism is out > of scope and almost certainly outside the competence of this WG. I'm not worried about stupid people doing stupid things. That is a given, and there's nothing we can do about that. I'm worried about reasonably intelligent people doing things that look like obviously the right thing, which happen to be the wrong thing and to cause harm. Now obviously the world would be a better place if everybody thoroughly read the relevant specifications before composing URIs or writing code that deals with URIs, and all of the specifications were complete and well written, and there were no contradictions in the specifications. But that's not the real world, or even close to it. So I believe that technical standards work better in practice if they're designed so that either (a) doing the obvious thing turns out to be the right thing (happy accident) or (b) doing the obvious thing fails in such a way as to force the implementor to figure out what the right thing is. It seems to me that protocol standards that have been widely successful and have a low barrier to implementation, are usually ones where the obvious thing is the right thing a great deal of the time. (and maybe that there's a low investment to figuring out what the "obvious" and right thing is in the context of that protocol.) Now it happens that the very nature of URNs (even without considering fragments or query strings) makes using them so subtle that the obvious thing (at least to people not intimately familiar with library science or similar disciplines that have had to deal with this sort of thing) is often the wrong thing. For instance, putting any kind of human-meaningful information inside an NSS is nearly always the wrong thing, because doing that quite often creates incentives (sooner or later) to make the name non-persistent. Adding fragments or query strings just makes this problem worse and introduces more cases where the obvious thing is the wrong thing. (Though it pains me to admit it, this is one thing that DOIs got right - the DOI equivalent of an NSS is deliberately meaningless to humans. The advantage that URNs have, is that by not restricting the contents of the NSS it becomes possible to grandfather any kind of persistent name into URN-space. But that advantage comes with a curse, which is that other parties then want to change URNs in order to suit their own requirements.) But back to URNs and fragments and query strings. If we can define things in such a way that the obvious thing works well often enough, that's wonderful. (How often is "often enough"? I'm not sure.) If we can't do that, we should consider making the obvious thing fail and providing a non-obvious way to do things that works well. And in any context where other URIs are permitted, the "obvious" way of composing URIs out of URNs and fragments or query strings is likely to be the way it works for HTTP. I should probably say at this point that I don't have a firm opinion about which is the best thing to do. Right now I'm trying to understand the different options in the solution space. There are clearly more options than either (a) just say NO, or (b) recommend a syntax just like the one used for other URIs and hope that people don't abuse it. (I started writing a internet-draft to recommend one of those options, and in the process of doing so, decided that I needed to do more case analysis before recommending a solution. That's the benefit of looking at things in detail rather than trying to make decisions based on emails that need to be more brief.) > The question is then what to do about those ignorant and/or > stupid people and their potential for harm. One answer, > consistent, IMO, with some of what you are suggesting, is to > prohibit features that might be perfectly reasonable in context > simply because they might be misinterpreted and used to justify > something that is problematic. I don't think I suggested anything nearly that strongly, and I don't agree with that characterization. Again, my goal is to find a way to satisfy various reasonable use cases (which I attempted to list a message or three ago) and to have URNs work reliably for those cases. But that's not the same thing at all as either prohibiting features, or recommending "obvious" ways of doing things that will likely cause problems. > There is an argument for that > sort of approach: in at least one cultural tradition, > prohibiting something reasonable because an ignorant person > might mistake it for something else and make a bad inference is > known as "building a wall around" something that is considered > important. [...] > > Another approach is to fiddle around with names and categories. > "That creature out there may look like a duck, walk like a duck, > and sound like a duck, but you are forbidden to call it a duck." > [...] It appears that your idea of what I imagine to be the possible solution-space is very different than mine. Forgive me if I don't want to argue about your analysis of your idea of what I'm thinking, especially since what I'm thinking is still a moving target. I think it makes more sense to argue about concrete proposals. At least then we are more likely to be arguing about the same thing. > In addition to the above and the stupidity and ignorance > factors, I suggest that this is just a less theoretical world > than it once was. If someone has something that they sincerely > believe is a real customer requirement that would be satisfied > with, e.g., a fragment identifier with a persistent resource > identifier and have seen URNs, they are extremely likely to use > a fragment identifier with the URN. If they even manage to read > out spec and all we have to say is "don't do that", we will, in > the vast majority of cases, lose. It appears that we have a test case for that, as RFC 2141 essentially says "don't do that (yet)". And perhaps that is the reason that URNs haven't so far been as successful as many of us had hoped. Maybe figuring out how to add fragment IDs and query strings will make URNs more broadly applicable and thus more successful. I'm all for that, as long as we can do it without destroying the intended utility of URNs in the process. (Though I expect the real gap isn't lack of support for query strings and fragment IDs, but rather lack of a general purpose and widely-usable URN resolution solution.) > I am suggesting a different plan and suggesting it because it > has reasonable odds of being successful among those who actually > might pay attention of us. It is that we make these things > valid and do so in a way that is as simple and straightforward > as possible, with no hair-splitting. If we have to hold our > noses to do that, we get good at nose-holding rather than > getting good at telling folks what they cannot do. Assuming I understand what you mean by hair-splitting, I agree that it generally causes problems. Let's try to avoid introducing subtlety where it isn't needed. On the other hand, we may also need to recognize where there is inherent subtlety that needs to be reflected in the protocol. I'm not worried about how things smell. I'm worried about how well they work in practice. Things can smell bad and still work well. I also think that people may have trouble following technical arguments about vague generalities, and that one person's idea about what is hair-splitting or smelly or subtle might be different than the next person's. (Also, if you're trying to dismiss something that I see as a valid technical concern, it would probably help to actually name it precisely rather than refer to it in vague terms.) > Then we > explain, with as much clarity as possible, some examples of ways > to use those identifiers that will work well, some that will be > problematic, and why the latter are a bad idea. The "bad idea" > part of that explanation should focus more on "bad for customers > and users" than on "bad for the Internet" and should focus more > on "bad for the Internet" than on "offends IETF religious > beliefs" or even "violates the principles of RFC 1737" because, > frankly, almost no one cares. > > For those who have any respect for what we do and/or who choose > to read our documents, that will help because we will be giving > them good advice about what will help them and their customers > and they will be inclined to follow it. For those who don't... > well, nothing will make any difference and we just need to > accept that as part of our reality. Actually I think there's an important middle group here - people who will read our documents if necessary to get things working. If things appear to work when people do the obvious thing, but they actually fail in subtle ways (or they work when initially tried but fail at some arbitrary time in the future), it will be hard to get people to recognize their implementation errors. But if people do the obvious thing, try it, and it fails in such a way as to give them a clear error indication, they'll be more likely to refer to the specification. Something that I've observed for a long time is that plain text protocols - like RFC 822, SMTP, HTML, HTTP, XML, json, and so forth, and also URIs - have a huge advantage in deployability because people don't think that they have to actually read the specifications in order to implement them. But for the same reason, they tend to break whenever any subtlety is required in how they're used. Again, I'm still trying to understand the solution space, so I don't have a concrete proposal yet. But it seems to me that this could be part of an answer. >> (Actually I'm much more concerned >> that they'll do this for fragment IDs than for query strings; >> I think the two cases are significantly different and the >> potential for fragment IDs to cause problems is much greater.) > Interesting. I would have said exactly the opposite. I think > it is possible to write advice about fragment identifiers that > makes it clear that: > > * The URN without the fragment identifier must be > persistent, stable, and meet the criteria of 2141 and > 1737. > > * The proposed fragment identifier must be structured as > a pointer into the resource identified by the rest of > the URN, not something that lies outside that resource > or modifies it in any way. > > * The semantics of the proposed fragment identifier must > be natural to the resource type and must neither change > the semantics of the resource nor require that it have > characteristics that are not natural to the resource. > URN:Rabbit:...#Chapter3 must fail, not identify the > right rear leg. > > * The semantics of the proposed fragment identifier must > be stable and persistent until any transformation of the > resource that does not invalidate the URN itself. (See > my earlier example about the difference between book > chapters and page references if transformation of book > content to different media are considered to not change > the resource.) > > * The fragment identifier, by the nature of fragment > identifiers, should not require a process for > interpreting it that is not natural, internal, and > natural to the resource. > > Now, that may not be the right set of rules, but the point is > that rules can be written because the natural use of a fragment > identifier is to select a part of a resource by some marker or > property that is intrinsic to that resource. And the funny thing about that assumption is that the "natural" use of a fragment identifier is exactly one that is unlikely to be persistent except for very specific kinds of resources. For instance, "chapter3" works as a persistent fragment ID for a book as long as the publisher never revises the book in such a way as to renumber chapters. That might actually turn out to be likely in the case of paper books named by ISBNs, but perhaps only because ISBNs get used as inventory control numbers. So if a publisher revises a book significantly enough that the chapter numbers change, it seems likely that the book will get a new ISBN anyway, to distinguish old stock from new stock. But that's a corner case. A rule to not renumber chapters is not a constraint that we'd want to impose on URNs in general, and maybe not even on electronic resources named by ISBN. So "chapter3" might be a good example of an inappropriate fragment ID, or a case where doing the obvious thing turns out to be the wrong thing, or one that only works well in a corner case that needs to be well-understood. Or maybe we just need a way to compose URNs with fragment IDs such that the resulting URI isn't seen as a URN. For the users who are demanding that URNs support fragment IDs, how important is it to them that those composed URIs also be URNs and thus persistent? > I don't know how > to write a similar set of rules for queries because they often > (perhaps usually) imply some process or processor that is > external to the resource. As soon as one says something like > "search engine" in conjunction with a query, a high standard for > persistence and predictability will require that one identify > the search mechanism and its properties and that those be stable > too. Perhaps. I also suspect that this is a "hard problem". It's easy to get close to defining what persistence means for URNs containing query strings, but hard to nail down exactly what is required. But something I don't know is - for the use cases that people envision, how important is it that the composition of a URN and a query string be persistent? Will a non-persistent URI that combines a URN and a query string suffice for most cases? > The final proposed rule above could be restated as > "fragment identifiers must not be search specifications in > disguise". > > So, personally, I'm a lot more afraid of queries than I am of > fragments. To go a bit further, I don't think there is any > point second-guessing 3986 and its predecessors at this point, > but I think we would have been a lot better off with a query > syntax that embedded a URI rather than a query that is part of a > URI. The observation that may URIs that contain queries today > contain embedded URIs as part of the query only reinforces that > belief. Indeed, and the problem is much worse than that. The conventions of the web along with its user interface paradigm really encourages a view of the world where, outside of some very specific contexts, GET is the only thing you can expect to be able do with a URI. So you end up trying to coerce almost everything that you need to do into a GET. And that's hugely limiting, not only for URNs but for URIs in general. Keith From john-ietf@jck.com Sun Jun 16 09:25:49 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0467021F9BCE for ; Sun, 16 Jun 2013 09:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK9sv8Jr4GPm for ; Sun, 16 Jun 2013 09:25:43 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8655F21F9AF9 for ; Sun, 16 Jun 2013 09:25:43 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UoFlm-000JCr-U1; Sun, 16 Jun 2013 12:25:35 -0400 Date: Sun, 16 Jun 2013 12:25:29 -0400 From: John C Klensin To: Keith Moore Message-ID: <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> In-Reply-To: <51BC8D66.9050000@network-heretics.com> References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@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 Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 16:25:49 -0000 (note aggressively trimmed to concentrate on issues I haven't already said more than enough about) --On Saturday, June 15, 2013 11:51 -0400 Keith Moore wrote: >> Yes, that is a bit of an editorial challenge. I don't see it >> as a serious substantive problem because I don't think anyone >> is claiming that draft-ietf-urnbis-rfc2141bis-urn should be >> anything but 2141bis... with adjustments made to conform >> 2141-style URNs to the requirements of 3986. > I seriously doubt that the latter is even possible, the > misunderstanding of URNs in 3986 is so great. But let's table > that issue for now, figure out how to deal with query strings > and fragment IDs in URNs without harming the persistence > properties of URNs, and then see if it's possible to do that > without 2141bis taking exception to 3986. Wfm but see Julian's note. While I dislike several things about 3986, I don't see it as nearly as URN-hostile or, for that matter, different from its predecessors, as you obviously do. Nonetheless, I think that getting this right first and then seeing what, if necessary has to be done to align things with 3968 (or vice versa) is a reasonable strategy. That said, I think we need a 2174bis draft to use as the basis for discussion. Both in the the absence of a posted alternative and because I belief that most of what is needed is there, I would prefer to treat draft-ietf-urnbis-rfc2141bis-urn as that draft. >... > Yes, I have a similar interpretation, and agree that RESERVED > does not imply "prohibited for all time". But of course the > reason they were RESERVED is that we didn't know at the time > how to make them work and retain the persistence properties of > URNs. It's not yet clear to me that we know how to do that > now, but at least I think I personally understand the issues > better than I did then. > > (I actually misread the ABNF in 2141 the first time I looked > at it recently and missed the term in the > production for , so it appeared to me that '?' and '#' > could not appear in an NSS.) Again, if 2141 had said "prohibited" or the equivalent, we would be having a discussion that would be at least somewhat different. >... >> I think you are creating a strawman here and then demolishing >> it. There is no question, in my mind, at least, that using, >> e.g., a character offset fragment identifier would be truly >> stupid in a context that requires persistence, URN or >> otherwise. > > And yet, people are accustomed to being able to compose URIs > out of base URIs and fragment IDs without having to worry > about whether the result will be valid. They don't know that > it's stupid to do that, and nothing that 2141bis says is > likely to affect the vast majority of users that are currently > accustomed to appending fragment IDs to URIs. Ok. That, to me, is an argument for regularizing them, explaining why they are a problem in a URN context unless principles that we identify are followed, and then hoping for minimal damage. >... > I doubt that it's appropriate to make this a > namespace-specific property. That seems to have a lot of > really ugly consequences, like requiring both URN-parsing > software and ordinary users to know which URN namespaces > permit use of fragments and query strings. Though of course > there's nothing wrong with doing a detailed analysis of those > consequences. It would be, IMO, a terrible mistake to try to trap fragment identifiers in parsing. The issue should be whether they can be dealt with appropriately when the URNs are derefernced. The problem there is ultimately no different from the URL case: a meaningless fragment identifier associated with a given URI won't work and will presumably fail (see below) whether the URI is http://www.iana.org/assignments/urn-serviceid-labels/urn -serviceid-labels.xml#sos-sub-services or URN:birds:...#horse Now, that suggestion _does_ raise some issues with the Fragment definition in 3986 Section 3.5. First, 3986 ties fragment "format and resolution" to media type, which is, in the general case, meaningless for URN-type resources (independent of namespace because the namespace essentially implies whether or not a media type will even be present. Second, it says "Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications". That is one of those "predict and constrain the future in very broad terms" that gets us in trouble, sooner or later, almost every time we try to do it in an IETF specification. It never should have been permitted in an Internet Standard. But I didn't catch it and object (much less appeal after objecting), you didn't, either, and I don't believe anyone else did either. Too bad, but it can always be updated and amended either for URNs or more generally. Third, parts of the "special role" discussion (fifth paragraph by my count) would get one laughed out of most serious discussions with skilled informational scientists. Fourth, while it may not be our problem, the notion of binding fragment identifiers to media types would, in any rational world, require that the media type registry indicate whether fragment identifiers are permitted and what their syntax and semantics are. RFC 3986 doesn't appear to specify that registry. RFC 6838, Section 4.11 says "can specify how applications should interpret fragment identifiers..." and "Media types are encouraged to adopt fragment identifier schemes..." but stops far short of a requirement. That provision was included in the medial type registration spec for the first time in 6838, i.e., this year; prior that there wasn't even a slot in the template for the information and I note with amusement that no one has bothered to update even the text/html type registration at http://www.iana.org/assignments/media-types/text/html with fragment information. Finally, while the text includes a discussion that includes "not found" as an example, some media types are clearly interpreted in some places as "if the fragment identifier doesn't map to the resource, just return the resource as if no fragment was specified" (the first example above will, if dereferenced, return the relevant web page as if no fragment had been specified while a fragment that actually matches that page, e.g., http://www.iana.org/assignments/urn-serviceid-labels/urn -serviceid-labels.xml#urn-serviceid-labels-2 returns the location the user presumably intended. So, yes, if we go down this path, some updating of 3986 is likely to be needed. But, as you (I think) suggested earlier, let's figure out what we need to do and then worry about what else needs to be patched up to permit it. That seems to me to be much more of a way forward than spending energy on denouncing 3986. What is more important than either the analysis of what users typing things in might do or of the issues with 3986 and common practice is that the very nature of a fragment identifier requires that a document author or URN-assigner do something that makes it interpretable. Meaningless fragment identifiers just fail to do anything useful but may not cause much harm beyond confusing users about when happened when they specify what 3986 calls a "sub-resource" and get the resource instead. So, ignoring 3986 and reprising somewhat, I am suggesting that we (1) Allow fragment identifiers for URNs with the "#" delimiter (because switching delimiters to clearly denote these as "something else from what one might infer from 3986" would cause far more problems and incompatibility. (2) Without restricting syntax, make the presence or absence of fragment identifiers a namespace issue (not a parsing one). 2141-compliant UNR processors, and processors associated with older namespaces, will presumably get some flavor of "syntax error - reserved character" errors or some other failure condition. I don't see that as a problem. (3) _Require_ that processors for namespaces that do not allow fragment identifiers respond to their presence with an error condition, whether that is a slightly-bogus "syntax error" or "character/fragments not allowed" report (for backward compatibility) or some flavor of "not allowed" or "not found". (4) _Require_ that processors for namespaces that perform dereferencing that do allow fragment identifiers (note that, if 2141 were followed, all of these would be new or revised) reject the things if they don't match identified fragment elements in the relevant resource. I expect this requirement will be ignored in namespaces that are already using fragments, but at least we will have a clear line about compliance. (5) As discussed earlier, warn about some types of fragment identifiers are inconsistent with persistence and prohibit them in URNs for that reason. I expect this may be ignored as well, but it will give us a fairly clear line about compliance and at least won't make anything worse or make the IETF look stupid. (6) Make sure that, from a syntax standpoint, fragment identifiers are clearly part of the URN and including in the matching rules. None of URN:feline:...lion URN:feline:...lion#African URN:feline:...lion#Asian Match any of the others. That means that users who go around attaching fragment identifiers to random URNs that are not dereferenced (either in their contexts or generally) are pretty likely to find themselves in unnecessary "no match" situation. I believe that is harmless at best and probably A Good Thing. Note that this rule is not backward-incompatible because the second and third forms are now prohibited by 2141 so can't match anything. I am agnostic about whether different media types that are used within (or dereferenced from) the same namespace should be able to impose their own restrictions on fragments as long as they don't broaden the rules above. Clearly exactly what is permitted to be useful in a fragment (uing the book example again, consider "#Chapter3" versus "Chapter-III") is resource-dependent, not media type dependent. I'd prefer to avoid the complexity of an additional layer of rules so will ask for use cases, but I ultimately don't care very much. >... > In my mind at least, a URN shouldn't be associated with a > document or resource, but rather with a resource definition > that explains exactly what is being named, and that resource > definition is part of what you should get back when you > resolve the URN... so that the client has a better idea of how > specific that particular URN is (e.g. is it a particular > document or a particular version of a document or a particular > rendering of a particular version of a document, or something > narrower or broader?) > > But in practice we tend to talk about URNs being persistent > across changes in the document when we actually mean something > more subtle than that, much as we talk about URNs being > persistent when we're really referring to a property of the > binding between the URN and the resource [definition]. To me, the distinction you are trying to make has been a problem with the definition of URNs in the beginning and is part of what is wrong with 1737, not just 2141. A little hard to fix today, but see the end of this note. > Indeed, those are very deep and long-standing questions, and > I've been involved in many long discussions about them over > the years. But for better or worse, it was an explicit and > strong consensus of the original URN working group that URNs > weren't just to be bound to a specific document independent of > location or replication, that they could reasonably refer to > resources whose content intentionally changed over time but > was still the same in some sense. The example of "today's > weather" was often cited. Perhaps it's not readily apparent > from RFC 2141, but if memory serves, other RFCs about URNs > reflect that consensus. Yep. See above and below. >... > There's lots of both history and philosophy here, certainly > more than we can reasonably relate to this group via email. > (and my, how times have changed!) Yep. See below. > If anyone else is actually interested in rehashing history or > philosophy, there's a high probability that I'll be in Berlin > and I'd be happy (or at least willing) to discuss those things > in person. But I've seen them rehashed in email list > discussions enough times to convince me that there's very > marginal utility in doing so, especially these days when a > smartphone is the device most frequently used to read email, > and people's attention spans for email seem to have diminished > considerably. (not that I'm not also guilty of that.) Keith, I think it would be a real contribution for some group of people to put together a comprehensive description of the history and philosophical debates and considerations that got us to where we are today. I'd hope the Independent Submission Editor would be receptive to such a document; if not, I can identify at least a few other places that would be. But, even while I've been rehashing some of those discussions because your remarks seemed to make it necessary, I'd like to separate them as much as possible from the question of what this WG needs to do to more forward in a way that is consistent with today's realities. >>> 7. Thus, the combination of a URN and a fragment identifier >>> has no assurance of persistence. It follows that the >>> combination of a URN and a fragment identifier cannot be a >>> URN. >> That does not follow at all. > > I realized after I sent that message that I didn't state it > precisely enough. What I meant was that if you have a URN > for some resource (not one that you control) and you know of a > fragment ID within that resource, it's perfectly reasonable > for you to want to create a reference (URI) that combines the > two - but there's no assurance that such a reference (URI) > will be persistent. And so, for example, if you're used to > seeing HTTP URLs constructed as base URL + fragment ID, and > you think you can construct a reference consisting of a URN > and a fragment ID in a similar way, what you end up producing > is something that looks like a URN (and begins with urn:) but > doesn't have the properties of URNs. And that, I think, is a > significant problem. But I think it is inherent is treating URNs as just another type of URIs. > Note that if you don't care about users being able to compose > specific URIs from a base URN + a fragment ID, and you don't > care about being able to extract the base URN from a URI > consisting of a URN and a fragment ID, there's no issue. > Simply assign a separate URN to each fragment of the document, > in addition to the URN for the entire document, with no > obvious relationship between the URNs used to name fragments > and the URN used to name the whole document. Then when the > URNs used to name fragments get resolved, they get resolved to > URLs that contain fragment IDs that are appropriate for the > currently accessible version of the document. Similarly, a > URN without a query string could resolve to a URL that > contained a query string, so you could define any number of > URNs for specific queries made to a resource. And that is the "URNs only point to atomic objects" approach, which I mentioned last week and suggested long ago, in a slightly different guise. > It's only because we want to be able to compose URIs by adding > fragment IDs and query strings, or decompose URIs that contain > fragment IDs and query strings, that we have this problem of > trying to figure out how to shoehorn fragment IDs and query > strings into URNs. So being able to compose those URIs is an > important property, and not just for the resource owner. Ok. See below. >... > To me main problem with making URNs with query strings > persistent is that the very act of assigning a URN to the > resource puts responsibility on the resource maintainer to not > change the interpretation of query strings, even (I suspect) > to the point of defining results for query strings whose > results were previously-undefined. In other words, you can't > extend the query language. > > Perhaps more to the point, I'm wary of saying that the act of > assigning a URN to a resource constrains how that resource can > evolve. In particular, I don't think there should be any > constraint on who can assign a URN to something. Whoever > assigns the URN doesn't necessarily control the resource. > > But I'll readily admit (and these examples illustrate) that it > might be difficult to get consensus on what URNs that contain > query strings mean, and that this is probably more subtle than > defining what it means to have persistent URNs that contain > visible fragment IDs. Right. And that was what got me to the point I'm at. >... >> The question is whether it is appropriate to try >> to ban the latter because there are a certain number >> (even a large number) of bad examples or if we should >> try to define things so that the good cases are allowed >> and we are more clear about why the bad cases are bad.". > > I don't want to try to ban any practice. I think there are > valid use cases for all of these practices. What I want to > do is figure out how to permit these practices (including the > practice of users composing URIs from base URIs + query string > that they supply) without degrading the notion that urn: means > "persistent identifier" because I think that's a very > important property of URNs. Sure. But a different way to look at your comments above is simply to say that, as soon as one takes a URN and embeds it as part of a composed URI, it becomes impossible to make global statements about the stability and persistency of the aggregate result. I think that is inevitable even in theory; it is certainly inevitable if one considers all of the sloppy things that we know happen and will happen and that we can't prevent. I suppose that, by making enough rules and restrictions, we could figure out how to say that URNs that are fully conformant with IETF specifications and intent remain stable when embedded in URIs that are fully conformant with IETF specifications and intent. But, in the absence of ability to test URNs and URIs for conformance at that level without dereferencing anything, I don't think such a statement would be useful even in theory... and that it would be useless in practice, even if true. >... > In principle, any URN can refer to any kind of resource. If > there are particular namespaces that constrain themselves as > to only assign URNs to specific kinds of resources that have > specific persistence properties, that's their business, but we > shouldn't define general URN behavior in the presence of > fragment IDs and/or query strings in such a way that it only > works for those corner cases. Given the above, where we disagree is only about what is a corner case and what is, or is going to be, common practice. If we identify everything we don't want to see in URNs as a corner case and dismiss it, then what "URN:..." means will be determined in the marketplace with no regard to your (or my or the IETF's) beliefs about what constitutes reasonable and appropriate uses. If we are going to stick with URNs as a concept, I'd rather let go of some of that, admit that some URNs are going to be a lot more persistent and well-behaved than others. I'd like to see us try to tie that difference to namespaces --some of which will certainly be more persistent and well-behaved than others no matter what we do-- than to leave the users of URNs to guess on a per-URN basis. I do think we have fundamental problems with where we are and where we are headed. One possible conclusion from both your remarks and concerns and mine is that trying to establish a single persistent identifier model for arbitrary resources may have exceeded the IETF's knowledge and competence if, indeed, it is possible. If that is even partially true, then trying to define them as an element of a syntax-sharing "uniform resource identifier" concept was probably a worse idea whether those identifiers are the URIs described in 3986 and its predecessors or something else. It would have therefore been much easier (and more plausible) to define our persistent resource references separately from persistent resource-class references and to do so in a way that would be less likely to lead the naive but well intentioned (much less those who don't think or don't care) into situations that invite abuse and undermining the concept. But, even if that very pessimistic analysis of the problem is the right one, the question today remains how we move forward to salvage the best of a bad situation, accepting the actually practices in the field and the potential for competing standards (or at least IETF standards that are ignored in practice) as part of the reality we have to consider. I've made my proposal as to how to thread that needle; I look forward to yours. I've found this discussion very educational, thought-provoking, and illuminating. It has certainly clarified my thinking. I suspect from their silence that most of the rest of the WG's participants are less enthused or perhaps just waiting for your promised specific proposal. I don't think that the two-way conversation will help much more until others step in or your I-D is posted. So I'm going to go back to lurking and hoping for the best until one of those things happens. best, john From john-ietf@jck.com Sun Jun 16 13:27:30 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECE721F9D29 for ; Sun, 16 Jun 2013 13:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a9okrtVTX-x for ; Sun, 16 Jun 2013 13:27:26 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 08BED21F9D22 for ; Sun, 16 Jun 2013 13:27:26 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UoJXj-000JSI-Do; Sun, 16 Jun 2013 16:27:19 -0400 Date: Sun, 16 Jun 2013 16:27:14 -0400 From: John C Klensin To: Julian Reschke , Keith Moore Message-ID: <66B060F8F6FB5E53C7C5439D@JcK-HP8200.jck.com> In-Reply-To: <51BC49D0.6000504@gmx.de> References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <51BC49D0.6000504@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 Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 20:27:30 -0000 --On Saturday, June 15, 2013 13:02 +0200 Julian Reschke wrote: >... > "1.1.3. URI, URL, and URN > > A URI can be further classified as a locator, a name, or both. > The term "Uniform Resource Locator" (URL) refers to the subset > of URIs that, in addition to identifying a resource, provide a > means of locating the resource by describing its primary > access mechanism (e.g., its network "location"). The term > "Uniform Resource Name" (URN) has been used historically to > refer to both URIs under the "urn" scheme [RFC2141], which are > required to remain globally unique and persistent even when > the resource ceases to exist or becomes unavailable, and to > any other URI with the properties of a name. > > An individual scheme does not have to be classified as being > just one of "name" or "locator". Instances of URIs from any > given scheme may have the characteristics of names or locators > or both, often depending on the persistence and care in the > assignment of identifiers by the naming authority, rather than > on any quality of the scheme. Future specifications and > related documentation should use the general term "URI" rather > than the more restrictive terms "URL" and "URN" [RFC3305]." > > If you really really believe there's something to fix over > here then please make a concrete proposal. >... > Actually, it recommends to avoid the term. All it says about > is what it was used for historically. Julian, While I don't agree with what I think is Keith's perception that 3986 is the root of many of the troubles we are now facing (or at least I don't see as much trouble there), a recommendation that the term "URN" be avoided seems to contradict the charter for this WG (https://datatracker.ietf.org/wg/urnbis/charter/). That document seems pretty clear that URNs are something specific and at least rooted in 2141. As Keith and I have said to each other in our rather long thread, I think it is better than the WG figure out what we want to do, reflect it in [some] 2141bis and then figure out what, if anything, needs to be adjusted in 3986 to get things back into alignment. However, it seems to me that the material quoted above will need to be adjusted to take the stance that calling things "uniform resource names" that are not part of the URN scheme is just an error and source of confusion rather then deprecating the usage entirely. The seems necessary in order to make this WG and any possible output from it meaningful. In retrospect, that change should have been prerequisite to even chartering the WG, but it is rather late for that now. I think that one of the places that Keith's and my reasoning intersect is that, syntax aside, URNs are a rather specific type of beast. Because of the persistence concept and maybe ideas of what "resources" are about, that beast is different from, rather simply a subset of, generic URIs. Perhaps the WG can find a path that makes that not the case and makes URNs just a URI scheme. I don't see that possibility right now without in the process, making IETF-defined URNs a lot less useful, but I'm open to the idea. Unless it can be done, I think 3986 will need some adjusting (even more general than the above) to note that exception. Again, I'll defer a more specific proposal until we have 2141bis under control, but I thought I should at least respond to your challenge by telling you where I think I'm headed. I discussed the URN fragment issues in my note to Keith earlier today. best, john From moore@network-heretics.com Sun Jun 16 13:32:00 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F101421F9D18 for ; Sun, 16 Jun 2013 13:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61a2Owm3C438 for ; Sun, 16 Jun 2013 13:31:54 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id D6CBA21F9CA7 for ; Sun, 16 Jun 2013 13:31:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E661D2123B; Sun, 16 Jun 2013 16:31:53 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Sun, 16 Jun 2013 16:31:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=QGJSjlSRRf2lgV3kFUZ6Xz TUpvM=; b=kAOACirkLGELhHxi6s7r352OqNqqviNignpm0ndV7kMGRSk11DeS5X zvnqRLw6iFTIviBNQAM77rIPOV/MezvJGlck/7TePfmcGhdN0RN/nncG4y6h8Zb5 f5UJM16O18XXN2WOP98bay5Mj4v0q2ePGKUAPEg9ybzrodl8X8+0Y= X-Sasl-enc: JUDMnqD49MFzPBDuzoLVGi14USr0aaMll6ZfOZDgv2IG 1371414713 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 02035C00E81; Sun, 16 Jun 2013 16:31:52 -0400 (EDT) Message-ID: <51BE20B7.4040908@network-heretics.com> Date: Sun, 16 Jun 2013 16:31:51 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John C Klensin References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <51BC49D0.6000504@gmx.de> <66B060F8F6FB5E53C7C5439D@JcK-HP8200.jck.com> In-Reply-To: <66B060F8F6FB5E53C7C5439D@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 20:32:00 -0000 On 06/16/2013 04:27 PM, John C Klensin wrote: > However, it seems to me that the material quoted above will need > to be adjusted to take the stance that calling things "uniform > resource names" that are not part of the URN scheme is just an > error and source of confusion rather then deprecating the usage > entirely. The seems necessary in order to make this WG and any > possible output from it meaningful. In retrospect, that change > should have been prerequisite to even chartering the WG, but it > is rather late for that now. > > I think that one of the places that Keith's and my reasoning > intersect is that, syntax aside, URNs are a rather specific type > of beast. Because of the persistence concept and maybe ideas of > what "resources" are about, that beast is different from, rather > simply a subset of, generic URIs. I certainly concur. Keith From sm@resistor.net Sun Jun 16 17:57:09 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CD821F9C01 for ; Sun, 16 Jun 2013 17:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBx0IOgI+ofW for ; Sun, 16 Jun 2013 17:57:07 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8326A21F9BB6 for ; Sun, 16 Jun 2013 17:57:07 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r5H0v1xt001747; Sun, 16 Jun 2013 17:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371430626; bh=/k9qAH9bN7QUh9LImubhP0ecRif1mWv58SWM7GPOp5Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FsA/7/lR8YoDkd1mrCqmyVpuRdoI4N0USfXoGkhmW5H1lBJ4aDi15uMcRtpUvkH9P XlsZtQA/b3gjA0S6L8mXDBdA8WKu4ytZ4tdzCFeh+PZt2WwlusvKyPZx5FpxV0to0w o8fFNjerkjXOeKhVZnnur9dkVObW1vDatXqrct7M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1371430626; i=@resistor.net; bh=/k9qAH9bN7QUh9LImubhP0ecRif1mWv58SWM7GPOp5Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=feaOm5HUy9J+8hVBphsMN2RpGtUObyMhcn8xg/0UsWhFO33ToBnpwteNGmhW/GzVP m/ro+vBDJaYJbb98JCZg2nqGdZOnXvOpbPbRr2tc6Fy+HaLSnHRcrzdtj0CXQHZGFw 1qXRmuIKy/UfZlW8fYyRBRgPnNKFuNPARprVkWiI= Message-Id: <6.2.5.6.2.20130616173357.0bc90120@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 16 Jun 2013 17:48:20 -0700 To: John C Klensin , Keith Moore From: SM In-Reply-To: <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 00:57:09 -0000 At 09:25 16-06-2013, John C Klensin wrote: >I've found this discussion very educational, thought-provoking, >and illuminating. It has certainly clarified my thinking. I >suspect from their silence that most of the rest of the WG's >participants are less enthused or perhaps just waiting for your >promised specific proposal. I don't think that the two-way >conversation will help much more until others step in or your >I-D is posted. So I'm going to go back to lurking and hoping >for the best until one of those things happens. I think I might not have understood some parts of what Keith has been trying to explained. I would like to go over the messages which John and Keith have exchanged and some of the old messages to this mailing list. It's a significant amount of material for me. I would have wished that the matter was brought up earlier but we cannot change the past. :-) Regards, -sm From moore@network-heretics.com Sun Jun 16 21:44:11 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B360F21F995E for ; Sun, 16 Jun 2013 21:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j7NIOor546b for ; Sun, 16 Jun 2013 21:43:56 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id DD2C321F9952 for ; Sun, 16 Jun 2013 21:43:55 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id ED55B20DCC; Mon, 17 Jun 2013 00:43:54 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 17 Jun 2013 00:43:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=u04W9AHLc73qlRUXrhi+XR Psq+8=; b=E+k4pnLzLe8wruRGsCy05AxFfaS1Y4Mn9Vf0n5qudXUcfGGnD9XcSX y2S12Uw5W2cH9Pg6g9NkACQFJxH1yMzFre5T4VnCd5zjqlv0GgYhPXXr3hwR+qz/ rzHnfN7e173Aij0NkUnSr3/f6JY1n0oHhs773JslRFSY9A0eynrP4= X-Sasl-enc: zyM1KrfZeMyd649FzVykUfnUzgQW9q7Fuvau64qs95IY 1371444233 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 8715B680278; Mon, 17 Jun 2013 00:43:52 -0400 (EDT) Message-ID: <51BE9405.6030108@network-heretics.com> Date: Mon, 17 Jun 2013 00:43:49 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John C Klensin References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> In-Reply-To: <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: [urn] Fragment IDs and media types (was: Re: Thoughts on fragments, queues, and new URN namespaces) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 04:44:12 -0000 [more aggressive trimming to address a relatively narrow point] On 06/16/2013 12:25 PM, John C Klensin wrote: > Now, that suggestion _does_ raise some issues with the Fragment > definition in 3986 Section 3.5. > > First, 3986 ties fragment "format and resolution" to media type, > which is, in the general case, meaningless for URN-type > resources (independent of namespace because the namespace > essentially implies whether or not a media type will even be > present. I don't think that's true, or maybe I don't understand what you're claiming. URN namespaces certainly aren't inherently specific to media types. Even if some legacy namespaces were developed in the context of physical media, there seems to be a growing need for identifiers that refer to content independent of media type (say for both physical media and digital content). And though perhaps it doesn't state it clearly, I think that 3986 is essentially correct that fragments are artifacts of specific media types (i.e. content-types). Many content-types don't have the notion of fragments, and among those that do have some concept like that, different media types treat them differently. HTML fragments are technically regions of the document, and they can be nested. I seem to recall that other media types define the ability to reference a particular point in a document (like a page, or a line, or the beginning of a chapter or paragraph) but not so much a region. And different content-types may impose different constraints on how to name fragments. So there's a tension that results whenever you want to refer to fragment IDs for any resource that might exist in multiple formats - how do you keep the fragment ID meaning the same thing across multiple representations of a resource? This problem exists even in HTTP in the presence of content negotiation, but it also exists in the context of URNs that can resolve to multiple representations in different content-types. At least, that's what comes to mind when I read those sections of 3986. > Second, it says "Fragment identifier semantics are independent > of the URI scheme and thus cannot be redefined by scheme > specifications". That is one of those "predict and constrain > the future in very broad terms" that gets us in trouble, sooner > or later, almost every time we try to do it in an IETF > specification. It never should have been permitted in an > Internet Standard. But I didn't catch it and object (much less > appeal after objecting), you didn't, either, and I don't believe > anyone else did either. Too bad, but it can always be updated > and amended either for URNs or more generally. I think they just wanted to have a general URI parser that could separate fragments and query strings from the remainder of the URI. And that idea mostly works except for URNs, because the urn: prefix was supposed to be an indicator of persistence, and fragments tend to break persistence unless there's a lot of discipline in how the resource is maintained. So when I read this, I just think that the 3986 authors didn't really grasp the implications of URNs, or perhaps (based on recent rereading of some old email) simply didn't want to believe that such things should exist. > Fourth, while it may not be our problem, the notion of binding > fragment identifiers to media types would, in any rational > world, require that the media type registry indicate whether > fragment identifiers are permitted and what their syntax and > semantics are. Well, we generally do want media type registrations to reference published specifications. But we don't try to generalize aspects of media types much beyond that; we just trust that when content is presented that there will have to be some media type specific code that knows how to present them. The fragment ID is just a parameter to be passed to that code. Offhand I don't see how significant benefit would be derived from trying to extract that information from the published specification of each media type and putting it into the media type registry. This is the sort of content-specific detail that I don't want to have to know about when trying to deal with a URI at a general level. I want it to be isolated to the routines that actually do interpretation and/or presentation of that content. Now, granted, if correct interpretation of a URI with a fragment ID requires selecting the "right" version of the content - the one for which that fragment ID is meaningful - that's a problem. But I don't think that problem can be fixed by having the URI lookup or URN resolution routines consult a registry. I think it just indicates that the notion of fragments in the web architecture just wasn't well thought-out, and now we're stuck with it. (On the other hand, there are certainly aspects of the URN architecture that aren't well thought-out, and we'll be lucky if we can fix them. So I don't feel like throwing rocks over this one.) > What is more important than either the analysis of what users > typing things in might do or of the issues with 3986 and common > practice is that the very nature of a fragment identifier > requires that a document author or URN-assigner do something > that makes it interpretable. Meaningless fragment identifiers > just fail to do anything useful but may not cause much harm > beyond confusing users about when happened when they specify > what 3986 calls a "sub-resource" and get the resource instead. Mumble. If at all possible I'd like to impose the burden for ensuring URN persistence on the party that assigns the URN and maintains the resolution data for that URN, rather than the party that maintains the resources that the URN resolves to. I think that's an important separation of function. Maybe I'm sensitive to this because I've experienced too many times in which a DNS RRset was out of sync with a host's configuration. That experience has made me very aware that what a resource is/does, and what associated with the name of a resource, are two distinct things. It's important to (a) not get the two confused and (b) architect things so that the consequences of things being out of sync are minimized. As applied to URNs I think it means this: Just because someone can associate a URN with a resource, doesn't mean that that someone is in a position to impose constraints on that resource and/or how it is maintained. Instead, the person who creates that URN and assigns a meaning to it, incurs an obligation to keep that meaning consistent over time (despite changes to the resource), either by adjusting the metadata associated with the URN and/or deleting it. But one implication of that might be that fragment names in URNs (at least those for which the resulting composed URI are expected to be persistent) need to be registered as part of that URN's associated metadata, and included in URN resolution results, so that such fragment IDs from such persistent URIs can be mapped to the current fragment names in the actual resource. (That might also address some of the issues with multiple resource representations.) > So, ignoring 3986 and reprising somewhat, I am suggesting that > we > > (1) Allow fragment identifiers for URNs with the "#" delimiter > (because switching delimiters to clearly denote these as > "something else from what one might infer from 3986" would cause > far more problems and incompatibility. See my forthcoming list of proposals for how to deal with fragments, queries, etc. in URN syntax. There are several concerns that need to be balanced. Some of those proposals do use "#" and "?" as they are used in current URIs, and some don't. I'm not sure at the moment which ones I prefer, but I think the choices are interesting - especially the possibility of getting away from the notion (enforced by current syntax conventions) that the only things you can do to modify a URI (or how the indicated resource is presented) are send it a query string or reference a fragment of it. > (2) Without restricting syntax, make the presence or absence of > fragment identifiers a namespace issue (not a parsing one). > 2141-compliant UNR processors, and processors associated with > older namespaces, will presumably get some flavor of "syntax > error - reserved character" errors or some other failure > condition. I don't see that as a problem. I still don't see why this is at all a namespace issue.... other than possibly that some specific parties associated with namespaces are insisting on it. Architecturally I don't think we want different interpretations of fragments for different namespaces. If they're valid for one namespace, they're valid for all of them. But this of course reflects my assumption that it's reasonable and desirable for ordinary users to compose references to specific fragments (bookmarks if you will) of things that are referenced by a URN, independently of what the URN maintainer does. We just don't want to confuse the resulting identifiers with persistent identifiers. > (3) _Require_ that processors for namespaces that do not allow > fragment identifiers respond to their presence with an error > condition, whether that is a slightly-bogus "syntax error" or > "character/fragments not allowed" report (for backward > compatibility) or some flavor of "not allowed" or "not found". Well, that would have fragments in the context of URNs mean something very different than fragments appearing in other URIs - and I doubt that that's desirable. For other URIs, interpretation of fragments is entirely specific to content-type. Even if somehow a fragment ID were used as input to URN resolution, I think it would be "get the metadata for the base URN, see what it says about mapping persistent fragment IDs to current fragment IDs, and then produce a URI that can be used to access the result". But really I think that it's just simpler to treat fragments as being entirely about presentation/interpretation of the resource. And I still think it's reasonable for users to want to refer to fragments of things named by URNs, even if the resulting URN+fragment URIs aren't persistent. > (5) As discussed earlier, warn about some types of fragment > identifiers are inconsistent with persistence and prohibit them > in URNs for that reason. I expect this may be ignored as well, > but it will give us a fairly clear line about compliance and at > least won't make anything worse or make the IETF look stupid. I am doubtful that it's reasonable to define exactly what types of fragments are, or aren't, consistent with persistence. Any kind of fragment ID can be persistent if the resource never changes (or the URN that points to the resource is deprecated when it does) and only exists in one representation. And any meaningful section of a resource is something that might need to be refactored over time. > (6) Make sure that, from a syntax standpoint, fragment > identifiers are clearly part of the URN and including in the > matching rules. None of > > URN:feline:...lion > URN:feline:...lion#African > URN:feline:...lion#Asian > > Match any of the others. That means that users who go around > attaching fragment identifiers to random URNs that are not > dereferenced (either in their contexts or generally) are pretty > likely to find themselves in unnecessary "no match" situation. > I believe that is harmless at best and probably A Good Thing. > Note that this rule is not backward-incompatible because the > second and third forms are now prohibited by 2141 so can't match > anything. I actually believe it is a Bad Thing. I would rather say that for resolution purposes the fragment ID and/or query string are first stripped (or ignored) and that the fragment ID or query string are to be interpreted in the context of the resulting resource. I'm not so concerned (though others are) about whether the fragment ID is "part of" the URN, because no matter how you define it, you end up having to explain in more detail what is actually needed to make it work. Whichever explanation is simpler and easier to interpret correctly is ok with me. >> ... >> In my mind at least, a URN shouldn't be associated with a >> document or resource, but rather with a resource definition >> that explains exactly what is being named, and that resource >> definition is part of what you should get back when you >> resolve the URN... so that the client has a better idea of how >> specific that particular URN is (e.g. is it a particular >> document or a particular version of a document or a particular >> rendering of a particular version of a document, or something >> narrower or broader?) >> >> But in practice we tend to talk about URNs being persistent >> across changes in the document when we actually mean something >> more subtle than that, much as we talk about URNs being >> persistent when we're really referring to a property of the >> binding between the URN and the resource [definition]. > To me, the distinction you are trying to make has been a problem > with the definition of URNs in the beginning and is part of what > is wrong with 1737, not just 2141. A little hard to fix today, > but see the end of this note. Though it might be "a little hard" to fix, I think it's worth a try. > >> ... >>> The question is whether it is appropriate to try >>> to ban the latter because there are a certain number >>> (even a large number) of bad examples or if we should >>> try to define things so that the good cases are allowed >>> and we are more clear about why the bad cases are bad.". >> I don't want to try to ban any practice. I think there are >> valid use cases for all of these practices. What I want to >> do is figure out how to permit these practices (including the >> practice of users composing URIs from base URIs + query string >> that they supply) without degrading the notion that urn: means >> "persistent identifier" because I think that's a very >> important property of URNs. > Sure. But a different way to look at your comments above is > simply to say that, as soon as one takes a URN and embeds it as > part of a composed URI, it becomes impossible to make global > statements about the stability and persistency of the aggregate > result. I think that is inevitable even in theory; it is > certainly inevitable if one considers all of the sloppy things > that we know happen and will happen and that we can't prevent. > I suppose that, by making enough rules and restrictions, we > could figure out how to say that URNs that are fully conformant > with IETF specifications and intent remain stable when embedded > in URIs that are fully conformant with IETF specifications and > intent. But, in the absence of ability to test URNs and URIs > for conformance at that level without dereferencing anything, I > don't think such a statement would be useful even in theory... > and that it would be useless in practice, even if true. But that's true for URNs in general even without fragments or queries. We tried to define them in such a way as to encourage them to be persistent, but we have no way of testing that - certainly not in advance and perhaps not even over time. It's just that it's much more difficult to ensure persistence when you need to not only maintain persistence of a single name for a resource, but also persistence of every possible variant of that name that a user can concoct. > >> ... >> In principle, any URN can refer to any kind of resource. If >> there are particular namespaces that constrain themselves as >> to only assign URNs to specific kinds of resources that have >> specific persistence properties, that's their business, but we >> shouldn't define general URN behavior in the presence of >> fragment IDs and/or query strings in such a way that it only >> works for those corner cases. > Given the above, where we disagree is only about what is a > corner case and what is, or is going to be, common practice. If > we identify everything we don't want to see in URNs as a corner > case and dismiss it, then what "URN:..." means will be > determined in the marketplace with no regard to your (or my or > the IETF's) beliefs about what constitutes reasonable and > appropriate uses. If we are going to stick with URNs as a > concept, I'd rather let go of some of that, admit that some URNs > are going to be a lot more persistent and well-behaved than > others. I'd like to see us try to tie that difference to > namespaces --some of which will certainly be more persistent and > well-behaved than others no matter what we do-- than to leave > the users of URNs to guess on a per-URN basis. I think that users might well develop a sense of which namespaces are more persistent than others, and in particular they might find that URNs with certain NSIs probably just shouldn't be used. But that shouldn't change the architecture. URNs, regardless of namespace, are supposed to assure persistence. They're supposed to be distinguishable from other kinds of URIs that presumably don't make assurances of persistence. The whole point in developing a URN umbrella was to be able to provide that level of assurance without users and software having to know characteristics of different URI types. And we want software to be able to treat all URNs the same at some level, without having to deal with subtle differences in what persistence means for each. Now if people have to adjust to the notion that maybe URNs with fragments/queries don't come with an assurance of persistence (even though they start with urn:), or that URNs with fragments/queries need an explicit indication of whether they are persistent, that might be ok. Either one of those seems preferable to expecting users to know which namespaces assure one kind of persistence and which namespaces assure a different kind of persistence. > I do think we have fundamental problems with where we are and > where we are headed. One possible conclusion from both your > remarks and concerns and mine is that trying to establish a > single persistent identifier model for arbitrary resources may > have exceeded the IETF's knowledge and competence if, indeed, it > is possible. While that might be true for other reasons, I don't think it's true because we have different ideas on how to indicate persistence of URIs. Those issues are going to emerge no matter who is looking at them, as long as they're looking in sufficient depth. Granted some parties might solve things in such a way as to optimize their use cases at the expense of others', but that doesn't mean they'd do a better job. Keith From moore@network-heretics.com Sun Jun 16 22:03:54 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004A221F9A3C for ; Sun, 16 Jun 2013 22:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxdSyr6zXIEd for ; Sun, 16 Jun 2013 22:03:48 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id B007321F9A3A for ; Sun, 16 Jun 2013 22:03:42 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A21E720B7A for ; Mon, 17 Jun 2013 01:03:31 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 17 Jun 2013 01:03:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:content-type; s=smtpout; bh=OFwskHDf31a3XBMErhQQFv28tlg =; b=EOYF7ohBzXiCND5TUSLmP1GLmv2QwXwMpuQK9V5ECBCfizOS7s6LkSMhV69 bpl3BKN86LGzlwVF/hYfceX1XBGHR9XAjAIcMX7FwT/LasU6zAYw2SUo1LDOPeY/ 0x8EElgshhdHf5yojhwAmwUVjkaPkJ89qkJIulQ1tNGjXGPY= X-Sasl-enc: 0HEdOQhxLXumxwv6NPinRnOxEkfxa8VTm3R07w2mFBP6 1371445405 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 99733C00E85; Mon, 17 Jun 2013 01:03:25 -0400 (EDT) Message-ID: <51BE989B.3000700@network-heretics.com> Date: Mon, 17 Jun 2013 01:03:23 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: urn@ietf.org Content-Type: multipart/mixed; boundary="------------050106000004090903090204" Subject: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 05:03:54 -0000 This is a multi-part message in MIME format. --------------050106000004090903090204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've attached a plain text document to this message that outlines several different proposals for URN syntax to include fragments and queries. This is a result of brainstorming to see how many different ways I could think of to compromise between the different competing concerns of which I'm aware. I like some of these ideas better than others, but I don't have a strong favorite at the moment. Some of them are mentioned just for completeness, to make it easier to compare those proposals with others that are (IMO) more refined. (I hope everyone can read this without much difficulty. I didn't want to put it in the message body because I've seen too many cases where mail readers screwed things up in presentation and/or reply, nor (for various reasons) did I want to publish this as an internet-draft (at least not yet).) What I'm hoping is that this list can be narrowed down into a small number of candidates, or at least provide some concrete examples for discussion. Keith --------------050106000004090903090204 Content-Type: text/plain; charset=UTF-8; name="draft-moore-urnbis-fragquery-syntax-aa.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-moore-urnbis-fragquery-syntax-aa.txt" What follows is a list of several distinct proposals for how to adapt URN syntax to accommmodate query strings and/or fragment IDs. This list is a result of some personal brainstorming about the different ways to do this given some conflicting goals, e.g.: - Desire to retain the meaning of urn: as 'persistent identifier', or at least to be able to distinguish persistent identifiers from those for which there is no assurance of persistence; - Desire to enable users to compose a URI consisting of a URN and query strings or fragment ID, for any resource named by that URN that accepted a query string or fragment ID (respectively), regardless of whether the resulting URI is persistent - Desire to avoid accidental mislabeling of non-persistent identifiers as if they provided assurance of persistence - Desire to avoid starting turf wars about exactly what URNs can or cannot do (or look like) based on expectations of other URIs. and - [maybe] Desire to be able to specify URIs that reference URNs in ways such that some semantic other than "get the named resource" is specified. Notes: 1. For the sake of brevity in the context of this discussion, I'm going to call the combination of a URN and a fragment ID or query string (and perhaps other features; see below), a "modified URN" with the abbreviation "mURN". I'm not insisting that we coin such a term for general discussion or in RFCs, I just think it's tedious to keep typing "URN with a fragment ID or query string". (Note that depending on the specific proposal, an mURN might or might not begin with urn:. Also note that, depending on the proposal, an mURN that assures persistence might have a different syntax than an mURN that does not have an assurance of persistence.) 2. In all of the proposals below, the query string or fragment ID is ignored for the purpose of URN resolution. It is assumed that both query strings and fragment IDs are interpreted in the context of the resource once it is accessed, rather than, say, by the resolution system. This is not the only possible way of doing things. It is possible to define resolution of mURNs containing fragments (at least) in such a way that the whole mURN (including fragment) is considered for resolution. Note that the chief value in structuring such an mURN to separate the base URN from the fragment (making this structure visible) would be so that the base resource URN could be extracted. If you just want to assign a separate URN for every fragment of a resource, without exposing any relationship between the fragment and the base resource, you can already do that with URNs today. 3. These are NOT in order of my preference. I'm not entirely sure which one I prefer at this point, and for the sake of completeness I included some proposals which I don't feel are workable. I'm interested in feedback not only about preferences, but also about other possible options - whether variants of these proposals or proposals that are significantly different. In addition, if you can identify additional advantages or disadvantages to these proposals, that's also interesting to me. ------------------------------------------------------------------------------ Proposal 1. "Just say no." Disallow fragment IDs and query strings in URNs, and don't create any new kind of URI or other notation to handle the combination of the two. I'm including this only for completeness, to remind people that it is an option. I don't expect that it's an attractive option. Advantages: - maintains the status quo - well-understood Disadvantages: - will discourage some namespaces from adopting the URN framework - may encourage some namespaces to define their own URIs - introduces the risk that IETF will be ignored regarding URNs ------------------------------------------------------------------------------ Proposal 2. "Obvious put possibly wrong." Allow fragment IDs and query strings with URNs, using RFC 3969 syntax for fragment IDs and query strings. This is further broken down into three distinct sub-proposals: ------------------------------------------------------------------------------ Proposal 2.1: Restrict use of this syntax to identifiers that remain persistent even when a fragment ID or query string are included. What persistent mURNs look like under this proposal: urn:foo:bar?query%20string urn:foo:bar#fragment What non-persistent mURNs look like under this proposal: (this proposal doesn't have an option for non-pesistent mURNs) Advantages: - preserves the property that 'urn:' means "persistent identifier" (if the rules are followed) - uses familiar syntax and is consistent with RFC 3986 Disadvantages: - The appearance of persistent mURNs containing fragment IDs and query strings seems likely to encourage use of this syntax to construct non-persistent identifiers, even though those identifiers would still begin with 'urn:' - This proposal doesn't provide a way to refer to fragments or queries of resources named by URNs, but when persistence of the fragment ID or query result (for a given query string) is not assured. ------------------------------------------------------------------------------ Proposal 2.2: Like Proposal 2.1, but choose a different syntax (perhaps a new URI type) for mURNs for which persistence is not assured: What persistent mURNs look like under this proposal: urn:foo:bar?query%20string urn:foo:bar#fragment What non-persistent mURNs look like under this proposal: nurn://foo/bar?query%20string nurn://foo/bar#fragment (The URI prefix nurn: is used for purposes of illustration; I haven't thought much about what prefix name would be best. Also I'm guessing that it would be easier to get a new URI type approved if the syntax were closer to that in RFC 3986.) Advantages: - preserves the property that 'urn:' means "persistent identifier" (if the rules are followed) - uses familiar syntax and is consistent with RFC 3986 - provides a way to refer to fragments and queries which aren't assured to be persistent Disadvantages: - Introduces a new URI type - The relationship between URNs and the new type of URI might not be obvious - The appearance of persistent mURNs containing fragment IDs and query strings might still encourage use of this syntax to construct non-persistent identifiers, even though those identifiers would begin with 'urn:' ------------------------------------------------------------------------------ Proposal 2.3: Allow use of 3986 syntax for fragment IDs and query strings with URNs, and simply document the fact that a URN with a fragment ID or query string no longer provides any assurance of persistence. What persistent mURNs look like under this proposal: urn:foo:bar?query%20string urn:foo:bar#fragment What non-persistent mURNs look like under this proposal: urn:foo:bar?query%20string urn:foo:bar#fragment (i.e. you can't tell the difference) Advantages: - uses familiar syntax and is consistent with RFC 3986 - provides a way to refer to fragments and queries of URN-named resources which aren't assured to be persistent Disadvantages: - breaks the property that 'urn:' means "persistent identifier" - there's no way to tell whether such an mURN is persistent ------------------------------------------------------------------------------ Proposal 3. ("explicit persistence indicator") Define a new syntax for explicit indication of persistence (or lack of any such assurance) context of mURNs. Retain the urn: prefix. RFC 2141 makes the new syntax a fairly obvious choice, since the only reserved characters in an NSS are '/', '#', '?', and '%'. Rather than make '/' mean only one thing (and eliminate the ability of URN syntax to be extended), it seemed more useful to use '/' to introduce any of potentially several well-defined paramters. This indication (/persistent=yes or /persistent=no) would be REQUIRED for any mURN containing a fragment ID or query string. (resolution would be defined to fail without it.) It would be FORBIDDEN for any ordinary URN without a fragment ID or query string. (resolution would be defined to fail if the persistent indicator were included) What persistent mURNs look like under this proposal: urn:foo:bar/persistent=yes?query%20string urn:foo:bar/persistent=yes#fragment What non-persistent mURNs look like under this proposal: urn:foo:bar/persistent=no?query%20string urn:foo:bar/persistent=no#fragment Advantages: - explicit /persistent= indicator hopefully makes it less likely that non-persistent mURNs will be constructed by accident - explicit sanity check in resolution protects to some degree against incorrectly composed mURNs - leaves open the possibility that additional parameters could be defined, say, to affect URN resolution or resource methods other than GET Disadvantages: - introduces unfamiliar syntax - /persistent might be too verbose (and yet, anything shorter might be too obscure) - meaning of /persistent might not be obvious to ordinary users constructing mURNs - this syntax might still be seen as confusing (it says urn: but also /persistent=no?) ------------------------------------------------------------------------------ Proposal 3.1: ("resolution options") Like Proposal 3, but allow additional options to appear besides /persistent, to influence URN/mURN resolution, even for ordinary URNs: e.g. urn:foo:bar/request=bib to get the bibliographic entry for the named resource (remember URCs, anyone?). Or: urn:foo:bar/request=revisions to get a revision history, or urn:foo:bar/request=citations to find known published references to the named resource. (again, forbid /persistent= except for mURNs with queries and fragments; both for the sake of backward compatibility with ordinary URNs, and to minimize the chance that people will accidentally construct mURNs that aren't persistent from URNs that have the /persistent=yes flag.) Advantages: - this might make URNs far more functional than URLs Disadvantages: - this might anger the web gods :) - this might make it even more annoying that we don't have a URN resolution system yet - this might invite defining a wide variety of ill-conceived resolution options (worse, before we implement any kind of resolution) Aside: It strikes me as at least possible that if the notion of URN were extended to include the ability to query that URN for a history of revisions (both prior and subsequent), the notion of "persistence" might become less of an issue. A client would be able to determine whether that URN had changed meaning over time, whether the resource had never changed, or changed in a linear fashion, or been forked into multiple resources, or merged from multiple resources into a single one. Of course, we still want a stable reference. We want to have confidence that if we use a URN to refer to something, that URN will still work to refer to that thing in some other context and/or at some later time. But that's hard to guarantee. If we could instead guarantee that by having a URN that worked at one time to refer to a resource, you'd be able to find a more recent version of that resource at a later date (or perhaps choose from among several successors), that might be good enough. You'd still be able to find what you needed. Of course this assumes that the citations, including revision history, of those resources would be maintained for at least as long as any of those resources were accessible. ------------------------------------------------------------------------------ Proposal 3.2: ("all of the options") Like Proposal 3.1, except that we stop treating queries and fragments as if they were the only two content-related operations you'd want to do on a resource. syntax would be something like: URN = "urn:" NID ":" NSS *(property-option) *(resolution-option) *(content-option) property-option = "/" name [ "=" value ] resolution-option = "?" name [ "=" value ] content-option = "#" name [ "=" value ] property-option would be properties of the name, like #persistent=yes resolution-option would be directives to influence URN resolution, like ?request=bib or ?request=revisions content-option would be modifiers to content and how it were accessed, like #query=query%20string or #fragment=chapter3 Advantages: - flexible - this might make URNs far more functional than URLs - cleanly separates options that take effect at different stages Disadvantages: - this might *really* anger the web gods :) - complex - requires people to understand the subtle difference between name properties, resolution options, and content access options - this might make it even more annoying that we don't have a URN resolution system yet - this might invite defining a wide variety of ill-conceived resolution options (worse, before we implement any kind of resolution) ------------------------------------------------------------------------------ Proposal 3.3: Like Proposal 3.2, except use a parameter naming convention to distinguish between name properties, resolution options, and content access options. Then the syntax looks something like: URN = "urn:" NID ":" NSS *(option) option = "/" name [ "=" value ] but option names would be things like "name.persistence" or "resolution.request" or "content.query" or "content.fragment". ------------------------------------------------------------------------------ Proposal 4: ("separate URI types") Define two new URI types, one for persistent mURNs and the other for mURNs with no assurance of persistence: What persistent mURNs look like under this proposal: pmurn://foo/bar?query%20string pmurn://foo/bar#fragment What non-persistent mURNs look like under this proposal: nmurn://foo/bar?query%20string nmurn://foo/bar#fragment (again, don't read too much into the choice of prefixes; the important things for this proposal is that they're distinct.) note: the syntax could be defined in such a way as to also permit additional parameters beyond the NSS, separated by '/'s: pmurn://nid/nss/request=bib/format=json?query%20string or nmurn://nid/nss/request=revisions/format=xml?query%20string (I'm assuming that the new URIs would have a more conventional appearance and one that is more compatible with 3986, than existing URNs.) Resolution of ordinary URNs would be defined to fail if a query string or fragment were present. Advantages: - explicit persistence indicator (pmurn: vs. nmurn:) hopefully makes it less likely that non-persistent mURNs will be constructed by accident - explicit sanity check in resolution protects to some degree against incorrectly composed mURNs - leaves open the possibility that additional parameters could be defined, say, to affect URN resolution or resource methods other than GET Disadvantages: - introduces unfamiliar syntax - the distinction between nmurn: and pmurn: (or any other two prefixes you might pick) might be too obscure - it's no longer at all obvious how to construct mURNs from URNs, or that there's a relationship between the two. (though this might be considered a feature?) ------------------------------------------------------------------------------ --------------050106000004090903090204-- From john-ietf@jck.com Mon Jun 17 07:15:08 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD7B21F9CA8 for ; Mon, 17 Jun 2013 07:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.403 X-Spam-Level: X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH+MDssKmeij for ; Mon, 17 Jun 2013 07:15:02 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id C87DC21F9CB2 for ; Mon, 17 Jun 2013 07:15:01 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UoaCl-000L24-F8; Mon, 17 Jun 2013 10:14:47 -0400 Date: Mon, 17 Jun 2013 10:14:42 -0400 From: John C Klensin To: Keith Moore Message-ID: <6E2F77D232F2D27C06DA4372@JcK-HP8200.jck.com> In-Reply-To: <51BE989B.3000700@network-heretics.com> References: <51BE989B.3000700@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 Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 14:15:08 -0000 --On Monday, June 17, 2013 01:03 -0400 Keith Moore wrote: > I've attached a plain text document to this message that > outlines several different proposals for URN syntax to include > fragments and queries. This is a result of brainstorming to > see how many different ways I could think of to compromise > between the different competing concerns of which I'm aware. >... Keith, I had resolved to stop posting to this list before others stepped into the conversation or you actually posted an I-D, but I think something is missing from your criteria/ "conflicting goals" that deserves comment before things go further. The first part of your document includes: > What follows is a list of several distinct proposals for how > to adapt URN syntax to accommmodate query strings and/or > fragment IDs. This list is a result of some personal > brainstorming about the different ways to do this given some > conflicting goals, e.g.: > > - Desire to retain the meaning of urn: as 'persistent > identifier', or at least to be able to distinguish > persistent identifiers from those for which there is no > assurance of persistence; > - Desire to enable users to compose a URI consisting of a URN > and query strings or fragment ID, for any resource named by > that URN that accepted a query string or fragment ID > (respectively), regardless of whether the resulting URI is > persistent > - Desire to avoid accidental mislabeling of non-persistent > identifiers as if they provided assurance of persistence > - Desire to avoid starting turf wars about exactly what URNs > can or cannot do (or look like) based on expectations of > other URIs. > and > > - [maybe] Desire to be able to specify URIs that reference > URNs in ways such that some semantic other than "get the > named resource" is specified. To that list, I would add what I think is the elephant in the room. Stated in parallel with your list of goals above, it is: - Desire to have a sufficiently straightforward and efficient mechanism for documentation, review, approval, and registration of new namespaces to encourage those who intend to create or use a namespace to go through that process. I think I've explained most of the reasons I think that is important in earlier messages and will try to avoid repeating myself, but we need to remember that, in a world of voluntary standards, the IETF lost a certain amount of control over URNs the day that 2141 was published and the "URN:..." syntax was officially defined. Other than education -- specifically defining good ways to do things and explaining why they should be adopted-- there is nothing we can do to force people to use only namespaces and syntax that have our stamp of approval (or to punish them if they do something that offends us). I think figuring out the best approach --and perhaps even more important, documenting and explaining the reasons for choosing it-- is very important and that your list makes a significant contribution to that process. But I think the choices we make have to be informed by a clear understanding that, * if what we specify doesn't meet people's perceived needs, and * we don't succeed in either providing a different and at least equally attractive way to meet those needs or a really persuasive explanation of why the needs should be reconsidered, the odds are astronomical that they will just do whatever they like and ignore us with the result of damaging at least predictability across the URN space(s) and possibly interoperability across the Internet. john From moore@network-heretics.com Mon Jun 17 07:35:42 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B48721F964C for ; Mon, 17 Jun 2013 07:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zt2UuF2jRTQU for ; Mon, 17 Jun 2013 07:35:37 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 58B2021F8FF3 for ; Mon, 17 Jun 2013 07:35:37 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9C5A020E6A; Mon, 17 Jun 2013 10:35:25 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 17 Jun 2013 10:35:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=fqJFkWOL3vwXewjMgvIV7l HMa6U=; b=XeI9aQmhbv0RN3Ik516pnTDZNoMkWUTSWRvG5r3sEOtT+zaNGroGKV 9rM7N/94HKiZ4Filr/rj6tXaGvpLdTuiWPnY8sEA40WAvp1p+x0wTuG7Ffy72wkG o5ihnKStu/Sl7prUi/eHw6Zsb776YA83mUDcCwNY5Tf2PmFzhAudY= X-Sasl-enc: gZdhNdeFa6q30BJUa8baaH4eeYRwG0rxcl2zh8piV5Vt 1371479725 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A97F6802AB; Mon, 17 Jun 2013 10:35:24 -0400 (EDT) Message-ID: <51BF1EA9.1070706@network-heretics.com> Date: Mon, 17 Jun 2013 10:35:21 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John C Klensin References: <51BE989B.3000700@network-heretics.com> <6E2F77D232F2D27C06DA4372@JcK-HP8200.jck.com> In-Reply-To: <6E2F77D232F2D27C06DA4372@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 14:35:42 -0000 On 06/17/2013 10:14 AM, John C Klensin wrote: > To that list, I would add what I think is the elephant in the > room. Stated in parallel with your list of goals above, it is: > > - Desire to have a sufficiently straightforward and > efficient mechanism for documentation, review, approval, > and registration of new namespaces to encourage those > who intend to create or use a namespace to go through > that process. While I don't disagree, for the moment I was just trying to figure out which syntax might actually work. I don't immediately see how your concern influences the decision of which syntax to choose ... except perhaps that the sooner we make a decision on how to move forward with URN syntax that accommodates fragments and/or queries, the more likely it is that we can actually define documentation, review, approval, etc. procedures that people will pay attention to. > I think I've explained most of the reasons I think that is > important in earlier messages and will try to avoid repeating > myself, but we need to remember that, in a world of voluntary > standards, the IETF lost a certain amount of control over URNs > the day that 2141 was published and the "URN:..." syntax was > officially defined. Other than education -- specifically > defining good ways to do things and explaining why they should > be adopted-- there is nothing we can do to force people to use > only namespaces and syntax that have our stamp of approval (or > to punish them if they do something that offends us). Well, we can define protocols that will work if the syntax is correct and URNs are used properly, and are less likely to work if the syntax is incorrect or for URNs are used improperly. But beyond that, not much. Which is part of why it helps a lot if the protocols that we define (and specifically the URN syntax conventions that we define) work when used in a more-or-less obvious manner. > I think figuring out the best approach --and perhaps even more > important, documenting and explaining the reasons for choosing > it-- is very important and that your list makes a significant > contribution to that process. But I think the choices we make > have to be informed by a clear understanding that, > > * if what we specify doesn't meet people's perceived > needs, and > > * we don't succeed in either providing a different and > at least equally attractive way to meet those needs or > a really persuasive explanation of why the needs should > be reconsidered, > > the odds are astronomical that they will just do whatever they > like and ignore us with the result of damaging at least > predictability across the URN space(s) and possibly > interoperability across the Internet. This is the normal state of affairs. People are constantly working to damage the interoperability of the Internet, at every layer of the protocol stack. What with all of the NATs, traffic shapers, interception proxies, firewalls, content filters, split DNS, and several other really bad ideas that are now widely deployed, frankly I'm amazed that the Internet still works at all. But I don't think we should panic about it. Let's just try to solve the problems of the part that we're working on, as best we can.... and also as quickly as we can, as long as we actually are solving the problems rather than just trying to get a half-baked non-solution out the door. Keith From L.Svensson@dnb.de Tue Jun 18 11:26:42 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7221921F9C3E for ; Tue, 18 Jun 2013 11:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+CCP6FA32Py for ; Tue, 18 Jun 2013 11:26:37 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6C41311E80EE for ; Tue, 18 Jun 2013 11:26:10 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id F132282A2C; Tue, 18 Jun 2013 20:23:21 +0200 (CEST) From: "Svensson, Lars" To: John C Klensin , Keith Moore Thread-Topic: Re: [urn] Thoughts on fragments, queries, and new URN namespaces Thread-Index: Ac5sSAahYBYftny1TOaATJxPe15Gsg== Date: Tue, 18 Jun 2013 18:26:08 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA435BD98@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.78] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:26:42 -0000 John wrote on June 16, 2013:=20 > I've found this discussion very educational, thought-provoking, and > illuminating. It has certainly clarified my thinking. I suspect from th= eir silence > that most of the rest of the WG's participants are less enthused or perha= ps > just waiting for your promised specific proposal. =20 On the contrary, this is the kind of discussion I have been waiting for. Fo= r someone as new to URNs (in the 2141 sense...) as me, input from those of = you who have experience from the earlier specification work is invaluable. = Please continue to help us to understand the issues that are not really doc= umented anywhere.=20 Thanks to both of you, Lars=20 From moore@network-heretics.com Thu Jun 20 13:28:43 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E74C11E811F for ; Thu, 20 Jun 2013 13:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdMA+-Q2v3Lf for ; Thu, 20 Jun 2013 13:28:38 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 71BD911E811D for ; Thu, 20 Jun 2013 13:28:30 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7610F20ED3 for ; Thu, 20 Jun 2013 16:28:23 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 20 Jun 2013 16:28:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type; s=smtpout; bh=OREl 7ZyjAd5RTkTm0aLMQrvjVWE=; b=tzTXCxIvAy4veHrxuWWwLY6ZWVid7ZA0r0go bE/cN76/dYJpTDh9PHQWovzmcSz2cmPUthwjlJm8Eq6LeAC63GGQ/NMS4hRSadJQ NvTsxey9/8jLARkChvZKBZH0HZIajdx8piD/WRcYkSE4qa6lOGR4S36wQPHIETCs AkqFwPQ= X-Sasl-enc: JRVwtzl7UYBWbAlUENcmBhRn7xOranOWKoNSnU/wfXSn 1371760102 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 799D0680450; Thu, 20 Jun 2013 16:28:22 -0400 (EDT) Message-ID: <51C365D8.4070004@network-heretics.com> Date: Thu, 20 Jun 2013 16:28:08 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: urn@ietf.org References: <51BE989B.3000700@network-heretics.com> In-Reply-To: <51BE989B.3000700@network-heretics.com> Content-Type: multipart/alternative; boundary="------------060200080008020003060909" Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:28:43 -0000 This is a multi-part message in MIME format. --------------060200080008020003060909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It's been a few days and I haven't seen any responses to my proposals for URN syntax to include fragments or queries. It would help to have some feedback, even if it's of the form "I hate them all", or "I can't tell which ones are better than others", or "I have no idea what you're talking about", or "I haven't had time to read the proposals". ---------- After a few more days' thought, I think the proposal that I'd prefer would be Proposal 3.1 with slight modifications. - Retain the familiar ?query%20string or #fragmentID syntax for those features. These do not affect resolution (they're removed before resolving the base URN) but affect the interpretation of and/or presentation of the resource after it is accessed. - Declare that mURNs containing fragment IDs or query strings are NOT to be considered as persistent identifiers unless they include an explicit /persistent option flag following the NSS. This seems easier than trying to forbid people from using a 'urn:' prefix with non-persistent identifiers derived from base URNs. - Extend the URN syntax to permit options that affect interpretation of the name, resolution, default operation when accessed (i.e. "clicked") as follows: mURN = "urn:" NID ":" NSS *option [ "?" query ] [ "#" fragment ] option = "/" option-name [ "=" option-value ] ; option-name and option-value are forbidden to contain "/" "=" "?" or "#" - Tweak 2141 syntax to remove "?" and "#" from reserved characters in a URN NSS - Create an IANA registry for option-names. If namespace-specific option names are allowed (not sure whether this is a good idea, I can see both pluses and minuses), distinguish them somehow from namespace-independent URN option names. Require at least expert review, if not IETF consensus, for new option names. The reason I prefer this is because I think it's a good compromise between well-established URI syntax conventions and the unique requirements of URNs, and also because I think it has less potential to generate controversy than some of the other proposals (which is not to say that I think it will be entirely uncontroversial). Keith --------------060200080008020003060909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It's been a few days and I haven't seen any responses to my proposals for URN syntax to include fragments or queries.

It would help to have some feedback, even if it's of the form "I hate them all", or "I can't tell which ones are better than others", or "I have no idea what you're talking about", or "I haven't had time to read the proposals".

----------

After a few more days' thought, I think the proposal that I'd prefer would be Proposal 3.1 with slight modifications.

- Retain the familiar ?query%20string or #fragmentID syntax for those features.   These do not affect resolution (they're removed before resolving the base URN) but affect the interpretation of and/or presentation of the resource after it is accessed.

- Declare that mURNs containing fragment IDs or query strings are NOT to be considered as persistent identifiers unless they include an explicit /persistent option flag following the NSS.   This seems easier than trying to forbid people from using a 'urn:' prefix with non-persistent identifiers derived from base URNs.

- Extend the URN syntax to permit options that affect interpretation of the name, resolution, default operation when accessed (i.e. "clicked") as follows:

mURN = "urn:" NID ":" NSS *option [ "?" query ] [ "#" fragment ]

option = "/" option-name [ "=" option-value ]

; option-name and option-value are forbidden to contain "/" "=" "?" or "#"

- Tweak 2141 syntax to remove "?" and "#" from reserved characters in a URN NSS

- Create an IANA registry for option-names.    If namespace-specific option names are allowed (not sure whether this is a good idea, I can see both pluses and minuses), distinguish them somehow from namespace-independent URN option names.   Require at least expert review, if not IETF consensus, for new option names.

The reason I prefer this is because I think it's a good compromise between well-established URI syntax conventions and the unique requirements of URNs, and also because I think it has less potential to generate controversy than some of the other proposals (which is not to say that I think it will be entirely uncontroversial).

Keith

--------------060200080008020003060909-- From ri@semanticidentity.com Thu Jun 20 19:49:43 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349FC21E80F5 for ; Thu, 20 Jun 2013 19:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFCMAVpbcr8A for ; Thu, 20 Jun 2013 19:49:38 -0700 (PDT) Received: from rigel.websiteactive.com (rigel.websiteactive.com [202.191.62.234]) by ietfa.amsl.com (Postfix) with ESMTP id B938321E80DF for ; Thu, 20 Jun 2013 19:49:36 -0700 (PDT) Received: from c211-31-36-79.rochd5.qld.optusnet.com.au ([211.31.36.79]:55033 helo=[192.168.1.12]) by rigel.websiteactive.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UprPp-0030ak-SQ; Fri, 21 Jun 2013 12:49:33 +1000 Content-Type: multipart/alternative; boundary="Apple-Mail=_1814E3D8-776D-4ECA-896A-7FEE16A468DD" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Renato Iannella In-Reply-To: <51C365D8.4070004@network-heretics.com> Date: Fri, 21 Jun 2013 12:49:32 +1000 Message-Id: References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rigel.websiteactive.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - semanticidentity.com X-Get-Message-Sender-Via: rigel.websiteactive.com: authenticated_id: ri@semanticidentity.com X-Source: X-Source-Args: X-Source-Dir: Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 02:49:43 -0000 --Apple-Mail=_1814E3D8-776D-4ECA-896A-7FEE16A468DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 21 Jun 2013, at 06:28, Keith Moore = wrote: > It would help to have some feedback, even if it's of the form "I hate = them all", or "I can't tell which ones are better than others", or "I = have no idea what you're talking about", or "I haven't had time to read = the proposals". I have just not been convinced of the need to support fragments/query in = URNs. I think the purpose of the NSS was to allow communities to define their = own requirements in this respect. Cheers... Renato Iannella Semantic Identity http://semanticidentity.com Mobile: +61 4 1313 2206 --Apple-Mail=_1814E3D8-776D-4ECA-896A-7FEE16A468DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 moore@network-heretics.com&= gt; wrote:
It would help to have some = feedback, even if it's of the form "I hate them all", or "I can't tell = which ones are better than others", or "I have no idea what you're = talking about", or "I haven't had time to read the proposals".
=
Cheers...
Renato = Iannella
Semantic Identity
=
Mobile: +61 4 1313 2206
= --Apple-Mail=_1814E3D8-776D-4ECA-896A-7FEE16A468DD-- From moore@network-heretics.com Thu Jun 20 20:01:21 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0EC21E80B0 for ; Thu, 20 Jun 2013 20:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNO67S3OIImY for ; Thu, 20 Jun 2013 20:01:15 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 557F121F99BE for ; Thu, 20 Jun 2013 20:01:15 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id 6B9F221018; Thu, 20 Jun 2013 23:01:14 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 20 Jun 2013 23:01:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type; s=smtpout; bh=qJrP fB3dLc6teKRDqlzGVsS1Qx4=; b=S8xOp2uI1v+YTVogad4asgKLrCS8sTl8Jwv4 sot9Ze7wAiuluPagkSWGFfXtxrytqWkMhTmiMaSgaHlGa9DrT2agGis7jX82faL+ 05c7iYQouA1QloVcqAO/wV1YYucKOkUDxIXCbZyeQnqWRn0117DBUanhkuJ1ztzT LV62l7Y= X-Sasl-enc: wSOxgEB4DzikubqX845/PDgEUwudNQi/wNU0ubxuuUmp 1371783673 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 3AB27680442; Thu, 20 Jun 2013 23:01:13 -0400 (EDT) Message-ID: <51C3C1EB.7050007@network-heretics.com> Date: Thu, 20 Jun 2013 23:00:59 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Renato Iannella References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090200050509060604090709" Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 03:01:21 -0000 This is a multi-part message in MIME format. --------------090200050509060604090709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/20/2013 10:49 PM, Renato Iannella wrote: > > On 21 Jun 2013, at 06:28, Keith Moore > wrote: > >> It would help to have some feedback, even if it's of the form "I hate >> them all", or "I can't tell which ones are better than others", or "I >> have no idea what you're talking about", or "I haven't had time to >> read the proposals". > > I have just not been convinced of the need to support fragments/query > in URNs. > I think the purpose of the NSS was to allow communities to define > their own requirements in this respect. Thanks for replying. Why do you think that this was the purpose of the NSS? (Is it because "?" and "#" are marked as reserved characters in the NSS in RFC 2141?) Why should the semantics of queries or fragments attached to URNs be specific to the namespace? Why should queries and fragments work differently for resources named by URNs than for resources named by URLs? In other words, if "foo" is a fragment of http://example.com/resource.html and urn:example:random resolves to http://example.com/resource.html, why should http://example.com/resource.html#foo potentially refer to something different than urn:example:random#foo? In case it's not clear, I think that fragments and queries should be defined by the resource (currently) pointed to by the URN, not by the namespace. Namespaces should not inherently be associated with specific media types (though some will tend to have such an association, it shouldn't be assumed that they do). I think that if a resource that is named by a URN has fragments or accepts queries, users should be able to construct mURNs that refer to specific fragments or specific queries. To me that means that a fragment should mean the same thing regardless of whether it's being accessed via a URN or a URL, and a query from a resource should also produce the same result regardless of whether the resource is being accessed via a URN or a URL, and that the interpretation of query strings and fragments needs to be consistent across all URNs. Keith --------------090200050509060604090709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/20/2013 10:49 PM, Renato Iannella wrote:

On 21 Jun 2013, at 06:28, Keith Moore <moore@network-heretics.com> wrote:

It would help to have some feedback, even if it's of the form "I hate them all", or "I can't tell which ones are better than others", or "I have no idea what you're talking about", or "I haven't had time to read the proposals".

I have just not been convinced of the need to support fragments/query in URNs.
I think the purpose of the NSS was to allow communities to define their own requirements in this respect.

Thanks for replying.  


Why do you think that this was the purpose of the NSS?   (Is it because "?" and "#" are marked as reserved characters in the NSS in RFC 2141?)

Why should the semantics of queries or fragments attached to URNs be specific to the namespace?  

Why should queries and fragments work differently for resources named by URNs than for resources named by URLs?   In other words, if "foo" is a fragment of http://example.com/resource.html and urn:example:random resolves to http://example.com/resource.html, why should http://example.com/resource.html#foo potentially refer to something different than urn:example:random#foo?

In case it's not clear,

I think that fragments and queries should be defined by the resource (currently) pointed to by the URN, not by the namespace.   Namespaces should not inherently be associated with specific media types (though some will tend to have such an association, it shouldn't be assumed that they do).

I think that if a resource that is named by a URN has fragments or accepts queries, users should be able to construct mURNs that refer to specific fragments or specific queries.   To me that means that a fragment should mean the same thing regardless of whether it's being accessed via a URN or a URL, and a query from a resource should also produce the same result regardless of whether the resource is being accessed via a URN or a URL, and that the interpretation of query strings and fragments needs to be consistent across all URNs.

Keith


--------------090200050509060604090709-- From julian.reschke@gmx.de Fri Jun 21 00:07:59 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E7911E8136 for ; Fri, 21 Jun 2013 00:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.155 X-Spam-Level: X-Spam-Status: No, score=-106.155 tagged_above=-999 required=5 tests=[AWL=-3.556, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh6cb9iIGqe7 for ; Fri, 21 Jun 2013 00:07:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD8621E8056 for ; Fri, 21 Jun 2013 00:07:52 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LwkcQ-1UEGF80koa-016Q4Y for ; Fri, 21 Jun 2013 09:07:46 +0200 Received: (qmail invoked by alias); 21 Jun 2013 07:07:46 -0000 Received: from p5DD94FE9.dip0.t-ipconnect.de (EHLO [192.168.1.105]) [93.217.79.233] by mail.gmx.net (mp004) with SMTP; 21 Jun 2013 09:07:46 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18x1T0TCaAxUeWjKV9rnviy4teWFNvWDlUGXHCsmp 9b+MjTJ0og3Y1a Message-ID: <51C3FBBC.4050504@gmx.de> Date: Fri, 21 Jun 2013 09:07:40 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> In-Reply-To: <51C3C1EB.7050007@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 07:07:59 -0000 On 2013-06-21 05:00, Keith Moore wrote: > On 06/20/2013 10:49 PM, Renato Iannella wrote: >> >> On 21 Jun 2013, at 06:28, Keith Moore > > wrote: >> >>> It would help to have some feedback, even if it's of the form "I hate >>> them all", or "I can't tell which ones are better than others", or "I >>> have no idea what you're talking about", or "I haven't had time to >>> read the proposals". >> >> I have just not been convinced of the need to support fragments/query >> in URNs. >> I think the purpose of the NSS was to allow communities to define >> their own requirements in this respect. > > Thanks for replying. > > > Why do you think that this was the purpose of the NSS? (Is it because > "?" and "#" are marked as reserved characters in the NSS in RFC 2141?) > > Why should the semantics of queries or fragments attached to URNs be > specific to the namespace? > > Why should queries and fragments work differently for resources named by > URNs than for resources named by URLs? In other words, if "foo" is a > fragment of http://example.com/resource.html and urn:example:random > resolves to http://example.com/resource.html, why should > http://example.com/resource.html#foo potentially refer to something > different than urn:example:random#foo? I agree for fragments. I disagree with query parts. They may look like a similar construct, but they are not. > In case it's not clear, > > I think that fragments and queries should be defined by the resource > (currently) pointed to by the URN, not by the namespace. Namespaces > should not inherently be associated with specific media types (though > some will tend to have such an association, it shouldn't be assumed that > they do). No. The semantics of a query part depends on the URI scheme, not on the resource being identified. Of course you could enforce the same semantics for all uses of the "urn" scheme -- is this what you intend? > ... Best regards, Julian From barryleiba.mailing.lists@gmail.com Fri Jun 21 07:51:18 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E99721F9A7C for ; Fri, 21 Jun 2013 07:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.003 X-Spam-Level: X-Spam-Status: No, score=-102.003 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhdj0T3VemAR for ; Fri, 21 Jun 2013 07:51:17 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id C406F21F842A for ; Fri, 21 Jun 2013 07:51:12 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id p12so5881086vbe.40 for ; Fri, 21 Jun 2013 07:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0zPGfWvZDqt0/sdNVWmkj0RF4F8XOaBZkKQhphzBozw=; b=Ic1dLQu6ii/7DKXm6k1nFXw+rmsKRCZxWtQ9VO/IegLDRtmDQmcW1R04/sZND1MovW e1WMQ7YNvQHyf5nxJMe9WL5EVnKmSML2NjRp8GiXCjAgKhTamGz8t0IXTXDREVQQUsj2 42vIEBjaQlF8Y2r7hjXtgXV4zjHVzSBIrFp8Y9DoMGkrKFXEj2zaoE/93eOoqIDCdyGJ G6/Gt0hg1w50nUBISC2ZMim1lUsBT1rr6HW26aS38v5Aqhn1yFSHR3wOROI9grpdcYVm N/VY085XyaycXYgK1SDGn5nJTJSpvByLk1Wuqh//OyDx28PG52fPXhjZq3Q1vQq9DESe +0Eg== MIME-Version: 1.0 X-Received: by 10.220.181.69 with SMTP id bx5mr5571594vcb.71.1371826271788; Fri, 21 Jun 2013 07:51:11 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.234.105 with HTTP; Fri, 21 Jun 2013 07:51:11 -0700 (PDT) In-Reply-To: <51BF1EA9.1070706@network-heretics.com> References: <51BE989B.3000700@network-heretics.com> <6E2F77D232F2D27C06DA4372@JcK-HP8200.jck.com> <51BF1EA9.1070706@network-heretics.com> Date: Fri, 21 Jun 2013 10:51:11 -0400 X-Google-Sender-Auth: 1sZ37zGwoAe8x2FIAGbCZbmYUI0 Message-ID: From: Barry Leiba To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Cc: "urn@ietf.org" Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:51:18 -0000 The discussion's been quite long, and it doesn't make sense for me to reply to a particular message, so I'm just picking one. I want to make a couple of points: I think we need to be careful not to conflate persistence with immutability. In general, URNs are meant to be persistent names for things, but that doesn't guarantee that the things they're naming won't change. It would be bad if they changed fundamentally, of course, but change that makes sense in the context of the name is what makes URNs work for the real-world situations we want to use them for. To use a somewhat silly example, suppose I had a URN that identifies my car, "urn:example:thing:leiba:car". In a day of the Internet of Things, that would be a perfectly reasonable name, allowing someone to say "Put a message on Barry's car's dashboard display." The fact that I got rid of my Toyota a couple of years ago and got a Subaru doesn't matter -- that URN now names a *different* car, but it still names *my* car. Less silly: we have a URN namespace for Internet drafts, defined in RFC 2648. The URN "urn:ietf:id:ietf-urnbis-rfc2141bis-urn-04" names the recently expired version of the 2141bis document. But 2648 doesn't say much about how these names work. In real usage, it's very likely that we want to be able to name the latest version of the draft, whatever version that is at the time the name is used: "urn:ietf:id:ietf-urnbis-rfc2141bis-urn". Clearly, the content that that name ultimately gets us to will change over time -- there was a dramatic change between the -03 and -04 versions -- but the name will always get us to the current version of that particular document. Persistent, but not immutable... and we wouldn't want it to be immutable. In fact, 2648 says something about that, in "Identifier persistence considerations": Persistence of the URNs of this namespace is independent of the mutability of the underlying documents. A URN once assigned will never be reassigned to a different resource; the assignment is persistent and immutable. Immutability of RFCs, STDs, FYIs and BCPs is at the discretion of the RFC Editor. They may be composites of one or more RFCs and the set of RFCs that includes them may change with time. It is important to note that this mutability of some resources is independent of the immutability of URN assignment to a resource. Of course, that means that if we have a URN that names a part of that document, the content of that section -- or even its existence -- can change: "For information about functional equivalence in URNs, see ." That works for version -04, but Section 8 was "Security Considerations" in version -03. Whether that makes it inadvisable to do this sort of thing or not will depend upon the sub-namespaces and the way those sub-namespaces are used. We might say that it makes sense for RFCs, where, by policy, the content doesn't change, but not for I-Ds, where fragments can change *fundamentally* from version to version. I'll also note that I see a reasonable case for fragments actually changing what resource the URN winds up resolving to. Consider this: "urn:isbn:0-679-40758-8" would name the edition of "Don Quixote" that I have on my bookshelf. It's a big book; it has, in one cover, "Volume 1" (which subdivides into "Book I" through "Book IV") and "Volume 2" (which has "Book V" and "Book VI"). If fragments were allowed, it might be reasonable for, say, "urn:isbn:0-679-40758-8#volume.1" to get me to "http://example.com/don-quixote/vol1", and for "urn:isbn:0-679-40758-8:volume.2" to get me to "http://example.com/don-quixote/vol2". Similarly, "urn:isbn:0-679-40758-8#book.iii" might get me to "http://example.com/don-quixote/vol1#bk3", and "urn:isbn:0-679-40758-8#book.vi" to "http://example.com/don-quixote/vol2#bk6". The critical part here is that what we define has to be useful to the folks who will actually *use* the URNs in the real world, and I think that's where John's proposal takes us. If they don't need fragments as part of the URNs (or queries, which I find much more problematic as anything other than something that's passed to the resource), then we're fine in saying that they're not part of the URNs. But if they *do* (because they need to do the sorts of things above, or perhaps because they need to do something entirely different and I got it all wrong), then we have to allow them to do what they actually have to do -- otherwise, we'll have simply defined some architecturally pure thing that's not actually useful. Barry From moore@network-heretics.com Fri Jun 21 08:10:19 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1BE21E8121 for ; Fri, 21 Jun 2013 08:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12lgca+jTShH for ; Fri, 21 Jun 2013 08:10:14 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9070821E8101 for ; Fri, 21 Jun 2013 08:10:14 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id 926A32090A; Fri, 21 Jun 2013 11:10:11 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 21 Jun 2013 11:10:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=gbKROh1pgHsodvCrEI6zan 96Hrw=; b=Keezzv54zFCPnrAeW8HSF1bOS36QnM2RIdjBCl9ArHaZZDUAPBQfyX mm1pLjvkx6U9aiWKhxuXy/UmRYP2T3gbriwmHMarL3XBupsShMKYj00c9RuvlrSz VE+jWJM1WAfFWePEoHxauZRzUIAC9DyUhCc8VQHShM/tjZMShCFvQ= X-Sasl-enc: IeYv9GIBomezNcPE8eSt4PQxfknWlbw1zEddOiPlSwjQ 1371827410 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B24D6801C6; Fri, 21 Jun 2013 11:10:10 -0400 (EDT) Message-ID: <51C46CC3.5060402@network-heretics.com> Date: Fri, 21 Jun 2013 11:09:55 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Barry Leiba References: <51BE989B.3000700@network-heretics.com> <6E2F77D232F2D27C06DA4372@JcK-HP8200.jck.com> <51BF1EA9.1070706@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:10:20 -0000 On 06/21/2013 10:51 AM, Barry Leiba wrote: > I'll also note that I see a reasonable case for fragments actually > changing what resource the URN winds up resolving to. Consider this: > "urn:isbn:0-679-40758-8" would name the edition of "Don Quixote" that > I have on my bookshelf. It's a big book; it has, in one cover, > "Volume 1" (which subdivides into "Book I" through "Book IV") and > "Volume 2" (which has "Book V" and "Book VI"). If fragments were > allowed, it might be reasonable for, say, > "urn:isbn:0-679-40758-8#volume.1" to get me to > "http://example.com/don-quixote/vol1", and for > "urn:isbn:0-679-40758-8:volume.2" to get me to > "http://example.com/don-quixote/vol2". Similarly, > "urn:isbn:0-679-40758-8#book.iii" might get me to > "http://example.com/don-quixote/vol1#bk3", and > "urn:isbn:0-679-40758-8#book.vi" to > "http://example.com/don-quixote/vol2#bk6". > > The critical part here is that what we define has to be useful to the > folks who will actually *use* the URNs in the real world, and I think > that's where John's proposal takes us. If they don't need fragments > as part of the URNs (or queries, which I find much more problematic as > anything other than something that's passed to the resource), then > we're fine in saying that they're not part of the URNs. But if they > *do* (because they need to do the sorts of things above, or perhaps > because they need to do something entirely different and I got it all > wrong), then we have to allow them to do what they actually have to do > -- otherwise, we'll have simply defined some architecturally pure > thing that's not actually useful. I've had a couple of ideas about this: 1. One is that URN resolution of a resource could return a list of fragment mappings. So if you resolved urn:isbn:0-679-40758-8 you might get back something that included: ... "fragments" = { ( "volume.1" = "http://example.com/don-quixote/vol1" ), ( "volume.2" = "http://example.com/don-quixote/vol2" ), ( "book.i" = "http://example.com/don-quixote/vol1#bk1" ), ( "book.ii" = "http://example.com/don-quixote/vol1#bk2" ), ( "book.iii" = "http://example.com/don-quixote/vol1#bk3" ), ( "book.iv" = "http://example.com/don-quixote/vol1#bk4" ), ( "book.v" = "http://example.com/don-quixote/vol2#bk5" ), ( "book.vi" = "http://example.com/don-quixote/vol2#bk6" ) } ... (Note that there's no real reason that, for an electronic copy, it would actually be needed to split this work into the equivalent of two volumes. Though maybe you could have such a case for a work that required several terabytes of storage.) 2. Another idea is that you might need separate mechanisms to permit identifiers to refer to HTML-style fragments, than those used to refer to persistent fragments. For consistency with other URIs that refer to HTML-style fragments I'd recommend continuing to use the '#' notation for these. But using the syntax I proposed, you could define a /region=xxx option (call it something different than fragment to minimize the potential for confusion). And I'm thinking that all such options should be input to any resolution service (so the client wouldn't have to know which options applied at which layer), so the resolution service would see that the client wanted region "book.iv" and could return the right URL (if not the whole list of regions). In summary, I do see the potential that some fragment-like construct that were resolved as part of the URN could be useful. I just don't think it's a good idea to prevent users from addressing individual HTML-style fragments of a document in conjunction with URNs. And I think it would be confusing if we repurposed '#' to mean something subtly different for URNs than for other URIs. Keith From moore@network-heretics.com Fri Jun 21 16:13:59 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5888921F9EB4 for ; Fri, 21 Jun 2013 16:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljKnxgjGGolJ for ; Fri, 21 Jun 2013 16:13:54 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 362CD21F9EB0 for ; Fri, 21 Jun 2013 16:13:53 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id E26962082D; Fri, 21 Jun 2013 19:13:52 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 21 Jun 2013 19:13:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=/KhQeSyWMxlwqeDoscB2Ba MZc6I=; b=I9wKOD5ZSyVqxjo9E8sTDXMHB0ZeJRxVHZzWZJ8Th+7j9s0rksj9Cy 0qtqKhhIuZanMJLts2jDlgfn3wnlM16aWk98Ap+2PRmaQACup7G4Ztx8aWWWDCQh O8RMkcc1/Z3r7twEanSQeFfWSUlJFuV1DZ5TPRgsRmjdLCBRVakho= X-Sasl-enc: cTerf+HamNh07uMiNFS8Aj4Ksq6hkx8tJMCpJ+1fSVMG 1371856432 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id F1E0F6801CF; Fri, 21 Jun 2013 19:13:51 -0400 (EDT) Message-ID: <51C4DE1F.2090704@network-heretics.com> Date: Fri, 21 Jun 2013 19:13:35 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Julian Reschke References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C3FBBC.4050504@gmx.de> In-Reply-To: <51C3FBBC.4050504@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 23:13:59 -0000 On 06/21/2013 03:07 AM, Julian Reschke wrote: >> In case it's not clear, >> >> I think that fragments and queries should be defined by the resource >> (currently) pointed to by the URN, not by the namespace. Namespaces >> should not inherently be associated with specific media types (though >> some will tend to have such an association, it shouldn't be assumed that >> they do). > > No. The semantics of a query part depends on the URI scheme, not on > the resource being identified. That seems like an odd statement to me, because the semantics of practically every resource on the web that currently accepts queries are controlled entirely by the resource. Even within the context of a single URI scheme (e.g. http), query semantics differ widely from one resource to the next. On the other hand, after surveying the use of query syntax in each of the several existing URI schemes, I can see why you might think that. Most uses of the query syntax are not really for anything that could be considered a query, but rather, just as a way to add options or parameters to a URI. But I have to ascribe that to poor design of those URI schemes, or perhaps, to the failure of the URI syntax to incorporate a general mechanism for representing options or parameters, causing the query syntax to get repurposed in many cases. I still think that for the case of URNs, it makes more sense to have the URI query syntax apply to the resource after it is resolved, and to have a separate syntax for parameters to be considered in the resolution process. > Of course you could enforce the same semantics for all uses of the > "urn" scheme -- is this what you intend? No, and I think it would be extremely difficult to define a single set of query semantics that were useful over any wide range of resources, whether the names of these resources were minted from a single URI scheme or multiple URI schemes. Also, URNs were never intended to be just another URI scheme. They were always intended to be stable, location-independent names that resolved to URLs. Keith From julian.reschke@gmx.de Sat Jun 22 01:08:45 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4965821F9E02 for ; Sat, 22 Jun 2013 01:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=-3.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvBhTnCNZ0Om for ; Sat, 22 Jun 2013 01:08:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id D6A6521F9DB2 for ; Sat, 22 Jun 2013 01:08:26 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LsMuE-1UAbIn3Hyq-0120Zs for ; Sat, 22 Jun 2013 10:08:25 +0200 Received: (qmail invoked by alias); 22 Jun 2013 08:08:25 -0000 Received: from p5DD94E9D.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [93.217.78.157] by mail.gmx.net (mp028) with SMTP; 22 Jun 2013 10:08:25 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/PnN03bLDPkC4K9u5F/oeRyFOywadXiGvNcpzwxE Y4zESze98rrP1s Message-ID: <51C55B71.9050504@gmx.de> Date: Sat, 22 Jun 2013 10:08:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C3FBBC.4050504@gmx.de> <51C4DE1F.2090704@network-heretics.com> In-Reply-To: <51C4DE1F.2090704@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 08:08:45 -0000 On 2013-06-22 01:13, Keith Moore wrote: > On 06/21/2013 03:07 AM, Julian Reschke wrote: >>> In case it's not clear, >>> >>> I think that fragments and queries should be defined by the resource >>> (currently) pointed to by the URN, not by the namespace. Namespaces >>> should not inherently be associated with specific media types (though >>> some will tend to have such an association, it shouldn't be assumed that >>> they do). >> >> No. The semantics of a query part depends on the URI scheme, not on >> the resource being identified. > > That seems like an odd statement to me, because the semantics of > practically every resource on the web that currently accepts queries are > controlled entirely by the resource. Even within the context of a > single URI scheme (e.g. http), query semantics differ widely from one > resource to the next. That's because the HTTP URI scheme definition doesn't say; and thus it's up to the server implementer to decide. > On the other hand, after surveying the use of query syntax in each of > the several existing URI schemes, I can see why you might think that. > Most uses of the query syntax are not really for anything that could be > considered a query, but rather, just as a way to add options or > parameters to a URI. But I have to ascribe that to poor design of > those URI schemes, or perhaps, to the failure of the URI syntax to > incorporate a general mechanism for representing options or parameters, > causing the query syntax to get repurposed in many cases. The general URI syntax just defines the structure of the URIs. It's up to a scheme definition to decide what to do with this structure. > ... Best regards, Julian From moore@network-heretics.com Sat Jun 22 03:12:27 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4762F21F9ED2 for ; Sat, 22 Jun 2013 03:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaFs+pbWYgzN for ; Sat, 22 Jun 2013 03:12:22 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 252F521E808B for ; Sat, 22 Jun 2013 03:12:21 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id 00A4320D7B; Sat, 22 Jun 2013 06:12:13 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 22 Jun 2013 06:12:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=1yIQrxRjL1K3OZGAKr8M7R gtO0A=; b=KHSG/Hu1pe+lWhyWJ8Np/5a2LXBE6XEZzPCg8tkJ0lBI8ypmDflwgZ xDqtTyxhfre+5QHTiyszgJGIW3cnpYFliwFMQMbKA67Z+d69yDbScUQWJPkqqGI5 RNFYdX3MQFs9gETxPjyh/VWF0Lzugy2K+8OONmatOMCGf9Iidxkew= X-Sasl-enc: +TcTv8jB7MS1GAH65QIA1dYGYpfMkpSH1KbTkf7atmuW 1371895933 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2119B6801ED; Sat, 22 Jun 2013 06:12:13 -0400 (EDT) Message-ID: <51C5786B.6000708@network-heretics.com> Date: Sat, 22 Jun 2013 06:11:55 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Julian Reschke References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C3FBBC.4050504@gmx.de> <51C4DE1F.2090704@network-heretics.com> <51C55B71.9050504@gmx.de> In-Reply-To: <51C55B71.9050504@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 10:12:27 -0000 On 06/22/2013 04:08 AM, Julian Reschke wrote: > On 2013-06-22 01:13, Keith Moore wrote: >> On 06/21/2013 03:07 AM, Julian Reschke wrote: >>>> In case it's not clear, >>>> >>>> I think that fragments and queries should be defined by the resource >>>> (currently) pointed to by the URN, not by the namespace. Namespaces >>>> should not inherently be associated with specific media types (though >>>> some will tend to have such an association, it shouldn't be assumed >>>> that >>>> they do). >>> >>> No. The semantics of a query part depends on the URI scheme, not on >>> the resource being identified. >> >> That seems like an odd statement to me, because the semantics of >> practically every resource on the web that currently accepts queries are >> controlled entirely by the resource. Even within the context of a >> single URI scheme (e.g. http), query semantics differ widely from one >> resource to the next. > > That's because the HTTP URI scheme definition doesn't say; and thus > it's up to the server implementer to decide. That the HTTP URI scheme doesn't define the semantics of HTTP queries is entirely appropriate, because the variety of services supported by HTTP is so broad that it wouldn't make sense to define common query semantics across all of them. Similarly, the variety of services supported by URNs is intended to be so broad that it wouldn't make sense to define common query semantics across all of them. This is true even within a single URN namespace. Some namespaces might restrict the resources to which they assign names so that those resources have common query semantics, but this shouldn't be assumed to be true for URN namespaces in general. So the semantics of a query that is bundled with a URN should be assumed by the URN architecture to be determined by the resource named. Keith From julian.reschke@gmx.de Sat Jun 22 03:16:21 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252F921F96EB for ; Sat, 22 Jun 2013 03:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.508 X-Spam-Level: X-Spam-Status: No, score=-105.508 tagged_above=-999 required=5 tests=[AWL=-2.909, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPJEt0I9F7CR for ; Sat, 22 Jun 2013 03:16:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 321F821E808B for ; Sat, 22 Jun 2013 03:16:14 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LpzgH-1UKq4I0vB9-00fj6S for ; Sat, 22 Jun 2013 12:16:13 +0200 Received: (qmail invoked by alias); 22 Jun 2013 10:16:12 -0000 Received: from p5DD94B36.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [93.217.75.54] by mail.gmx.net (mp035) with SMTP; 22 Jun 2013 12:16:12 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+K9rwZO1GKxojtA5eeJTDszfyn4SHzbqPnTkaAJm Dn4qow+LzF3Cpl Message-ID: <51C5795E.9070702@gmx.de> Date: Sat, 22 Jun 2013 12:15:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C3FBBC.4050504@gmx.de> <51C4DE1F.2090704@network-heretics.com> <51C55B71.9050504@gmx.de> <51C5786B.6000708@network-heretics.com> In-Reply-To: <51C5786B.6000708@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 10:16:21 -0000 On 2013-06-22 12:11, Keith Moore wrote: > ... > That the HTTP URI scheme doesn't define the semantics of HTTP queries is > entirely appropriate, because the variety of services supported by HTTP > is so broad that it wouldn't make sense to define common query semantics > across all of them. > > Similarly, the variety of services supported by URNs is intended to be > so broad that it wouldn't make sense to define common query semantics > across all of them. This is true even within a single URN namespace. > Some namespaces might restrict the resources to which they assign names > so that those resources have common query semantics, but this shouldn't > be assumed to be true for URN namespaces in general. > > So the semantics of a query that is bundled with a URN should be assumed > by the URN architecture to be determined by the resource named. I find this use of terminology very confusing - the query is *part* of the name. Best regards, Julian From moore@network-heretics.com Sat Jun 22 03:40:46 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8353221E808F for ; Sat, 22 Jun 2013 03:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRDqZVr6Qy4t for ; Sat, 22 Jun 2013 03:40:41 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 74A9321E8088 for ; Sat, 22 Jun 2013 03:40:41 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id 41234211B1; Sat, 22 Jun 2013 06:40:37 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 22 Jun 2013 06:40:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from :subject:date:to; s=smtpout; bh=1e63dJ7hdkDEbJrjBMZoyPIlI1o=; b= tfhEGRzrilFk/1nt01FLktlcWDNu8QcHIfWB4AlvanRjh0wACFn7eQqHjMKctTGN k+IlYu42bBlFc0lo8I8aKZ52bjmqoWw2yCFi0kitnmUTa9MUQoxejvO9PQeVRyut IWjWSevJLKlJ+eJtwP7/dTpcHyNBvmO+Xc18htf9GCo= X-Sasl-enc: TtuhBL/qA6epTfHT2SLAQmLjGVkreNTOduV4dbYnZpd7 1371897637 Received: from [21.147.82.124] (unknown [66.87.152.124]) by mail.messagingengine.com (Postfix) with ESMTPA id 2E21668027B; Sat, 22 Jun 2013 06:40:37 -0400 (EDT) References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C3FBBC.4050504@gmx.de> <51C4DE1F.2090704@network-heretics.com> <51C55B71.9050504@gmx.de> <51C5786B.6000708@network-heretics.com> <51C5795E.9070702@gmx.de> In-Reply-To: <51C5795E.9070702@gmx.de> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B329) From: Keith Moore Date: Sat, 22 Jun 2013 06:40:35 -0400 To: Julian Reschke Cc: "urn@ietf.org" Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 10:40:46 -0000 Sent from my iPhone On Jun 22, 2013, at 6:15 AM, Julian Reschke wrote: > On 2013-06-22 12:11, Keith Moore wrote: >> ... >> That the HTTP URI scheme doesn't define the semantics of HTTP queries is >> entirely appropriate, because the variety of services supported by HTTP >> is so broad that it wouldn't make sense to define common query semantics >> across all of them. >>=20 >> Similarly, the variety of services supported by URNs is intended to be >> so broad that it wouldn't make sense to define common query semantics >> across all of them. This is true even within a single URN namespace. >> Some namespaces might restrict the resources to which they assign names >> so that those resources have common query semantics, but this shouldn't >> be assumed to be true for URN namespaces in general. >>=20 >> So the semantics of a query that is bundled with a URN should be assumed >> by the URN architecture to be determined by the resource named. >=20 > I find this use of terminology very confusing - the query is *part* of the= name. I find it confusing to speak of a URN that contains a query, because a URN i= s supposed to be persistent, and a URN that contains a query is very unlikel= y to be persistent. And yet, I recognize that we need the ability to bundle= queries with URNs, and that people will think of those queries as being "pa= rt of" those URNs.=20 Really I suspect that the idea that a query is "part of" any URI is a mistak= e. It makes more sense for the named resource to be the engine to which a q= uery is submitted, than for the named resource to be the query result. But t= he thinking that the query is part of the URI is too well established to cha= nge it. From barryleiba.mailing.lists@gmail.com Sat Jun 22 06:16:20 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B709E21F8F61 for ; Sat, 22 Jun 2013 06:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.022 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi6lw6q3qXgS for ; Sat, 22 Jun 2013 06:16:20 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBE621F8F3A for ; Sat, 22 Jun 2013 06:16:20 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id da11so7391800veb.34 for ; Sat, 22 Jun 2013 06:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=x7wui2sYyFXjbgBGvvbiXSe7uccGV86cJEm7yKKK8s4=; b=JGLVogaFWTCoqW4JJnQ0dxs0AYX/O7/MbLzLuM8tV5OaicG80rucM4kvfSe6Z5xTvw 8IGyDX1w/UA77Ksiy4B6SrbTBaCYFhqVZbrlXNpwqWl47Kbref00bZzBrX/FUyME8bFZ btnP98uHnRD94rqpZCB+/zycGIlR1yrLBFddsVxDvodHO5x/O8P+bpIm9L22aIoxRCSB kyseSaeMRdfMN6AZzc9QkH4cNNTRM1374KiT8mGQv6CQ8zuijJUW6BCDRNxbXyghjPhk YeyzmKinBL61/0+abEVsx5CPoXeOnaiIxWEGMI0A8kTMydDCM24gg/kAbqnynT4JEq8O wdew== MIME-Version: 1.0 X-Received: by 10.220.44.195 with SMTP id b3mr7578744vcf.62.1371906979711; Sat, 22 Jun 2013 06:16:19 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.234.105 with HTTP; Sat, 22 Jun 2013 06:16:19 -0700 (PDT) In-Reply-To: References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C3FBBC.4050504@gmx.de> <51C4DE1F.2090704@network-heretics.com> <51C55B71.9050504@gmx.de> <51C5786B.6000708@network-heretics.com> <51C5795E.9070702@gmx.de> Date: Sat, 22 Jun 2013 09:16:19 -0400 X-Google-Sender-Auth: 3By9CBB3PGwTzghFpvtEMWpxnRQ Message-ID: From: Barry Leiba To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 13:16:20 -0000 > I find it confusing to speak of a URN that contains a query, because a URN is > supposed to be persistent, and a URN that contains a query is very unlikely to > be persistent. Again, be careful about conflating persistence and immutability. We can argue about where the line is, but a URN that names "all books written by Keith Moore" (or all IoT objects owned by Keith Moore) could well be a reasonable thing, which meets a meaning of persistence that makes sense for the domain of use for those URNs. Consider: 1. All RFCs that have Keith Moore as an author. 2. All RFCs that have an author affiliated with Cisco. 3. All RFCs produced by the MPLS working group. 4. All RFCs that have "MPLS" as a keyword. 5. All RFCs with the word "persistent" in the text. I think we'd all agree that the last one is a transient query, not a persistent thing. On the others, we might have a variety of opinions (mine is that (1) and (3) could reasonably be given persistent names). That's why I think this needs to be defined down in the (sub-)namespace specs. > Really I suspect that the idea that a query is "part of" any URI is a mistake. > It makes more sense for the named resource to be the engine to which a query > is submitted, than for the named resource to be the query result. I mostly agree with this. The trouble with what I say above is that if I say that the queries in (1) and (3) above are part of the URNs, and the queries in the others aren't, then how is anyone looking at the URN supposed to know that? And yet I can see value, for research and reference purposes, to have "a URN" that names "all books written by Barack Obama" (as opposed to "all books *about* Barack Obama", which, to me, would clearly be a transient query). Barry From moore@network-heretics.com Sat Jun 22 07:49:34 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE9021F9F8A for ; Sat, 22 Jun 2013 07:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81bdv+VRslJQ for ; Sat, 22 Jun 2013 07:49:29 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6F05C21F9F86 for ; Sat, 22 Jun 2013 07:49:29 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id 6921C20F6E; Sat, 22 Jun 2013 10:49:28 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 22 Jun 2013 10:49:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=DZUxYWWp5jK8H1up9GrJ6Z h1LRI=; b=P5MGh5Gi43i1JuFmsCPKaTzW3c4ujr4BO30qzpibrxhWbR9+jApkGw 2zCtUO0S1j3GvOlOWqAc2eAFTh2T8TmP+hJmsIAOH0vje5hIISgVzBUUhVkYCdfY KVnf1xCR2w/jyBpTUIeGk0r5P5Z66h10SNfFUtJzMt/r5snSD02iE= X-Sasl-enc: eJ6ACo5ed9v6d0O0kQx82R451/E8mLhaJSGrTCmKloCa 1371912567 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 5798D68027B; Sat, 22 Jun 2013 10:49:27 -0400 (EDT) Message-ID: <51C5B964.7060105@network-heretics.com> Date: Sat, 22 Jun 2013 10:49:08 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Barry Leiba References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C3FBBC.4050504@gmx.de> <51C4DE1F.2090704@network-heretics.com> <51C55B71.9050504@gmx.de> <51C5786B.6000708@network-heretics.com> <51C5795E.9070702@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 14:49:34 -0000 On 06/22/2013 09:16 AM, Barry Leiba wrote: >> I find it confusing to speak of a URN that contains a query, because a URN is >> supposed to be persistent, and a URN that contains a query is very unlikely to >> be persistent. > Again, be careful about conflating persistence and immutability. I don't think I'm conflating the two. When I say persistent, I am reasonably sure that I mean persistent. > We > can argue about where the line is, but a URN that names "all books > written by Keith Moore" (or all IoT objects owned by Keith Moore) > could well be a reasonable thing, which meets a meaning of persistence > that makes sense for the domain of use for those URNs. > > Consider: > 1. All RFCs that have Keith Moore as an author. > 2. All RFCs that have an author affiliated with Cisco. > 3. All RFCs produced by the MPLS working group. > 4. All RFCs that have "MPLS" as a keyword. > 5. All RFCs with the word "persistent" in the text. > > I think we'd all agree that the last one is a transient query, not a > persistent thing. Not necessarily. As long as the meaning associated with the URN remains the same, it's persistent. All of these seem like valid things with which to associate a URN. (And none of these necessarily involve query strings within a URN.) > On the others, we might have a variety of opinions > (mine is that (1) and (3) could reasonably be given persistent names). > > That's why I think this needs to be defined down in the (sub-)namespace specs. I don't see how that follows at all. The meaning of a query is associated with the name of the resource that implements the query, not with anything higher than that. URNs with queries become much less useful (i.e. much less generally applicable) if you try to associate query semantics with the namespace. And such a requirement would introduce a rather silly practice of having to define a new namespace every time you needed to name a new kind of query. >> Really I suspect that the idea that a query is "part of" any URI is a mistake. >> It makes more sense for the named resource to be the engine to which a query >> is submitted, than for the named resource to be the query result. > I mostly agree with this. The trouble with what I say above is that > if I say that the queries in (1) and (3) above are part of the URNs, > and the queries in the others aren't, then how is anyone looking at > the URN supposed to know that? None of the examples you cited above require use of a query string within the URN. A URN can be associated with a query without having to contain a query string. The only reason for a URN to contain a query string is if you want to be able to substitute one query string for another, or to expose the relationship between the query and the base resource (i.e. the query engine) for some other reason. > And yet I can see value, for research and reference purposes, to have > "a URN" that names "all books written by Barack Obama" (as opposed to > "all books *about* Barack Obama", which, to me, would clearly be a > transient query). No, "all books about Barack Obama" would not clearly be a transient query. Again, when we talk about persistence of a URN, we're not talking about whether the results are the same from one reference of the URN to the next, we're talking about whether the meaning of the URN changes. The problem with having a URN that contains a query string be persistent is that it's hard to nail down, in technical terms, what it means for a query to be persistent across all possible query strings. And to me the simplest answer seems to be that while the base URN is expected to be persistent, a URN that contains a query string (or for that matter a fragment ID) has no assurance of persistence. Keith From moore@network-heretics.com Sat Jun 22 12:21:02 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E5C21F9E7A for ; Sat, 22 Jun 2013 12:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCVInpqk-6by for ; Sat, 22 Jun 2013 12:20:56 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id C007C21F9DE9 for ; Sat, 22 Jun 2013 12:20:55 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id 5B566211D0; Sat, 22 Jun 2013 15:20:36 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Sat, 22 Jun 2013 15:20:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=dwhAGjjYu7zjyvyGF1q81Y Hsyqo=; b=Wj7eF4i7/coD4YcBjbJybLw1fhgGOFYAAZIeo6zquYhCgUg9KmRE/S FsAZr9E6YSSVnkFHZo68gHHa2E+3922+rKIPJtvL6YHKoSM2XVqmB4FQ2ciBO3gp y8dvydlYjJJc+f1j2VnjJ89bodhslIZIP7JovcyWnqOIdbbZ1rnqo= X-Sasl-enc: wu+8kxZUGEEw3gWHxHY0G0JviRglR3yhmKWjC1mkzKLb 1371928836 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D342B68045D; Sat, 22 Jun 2013 15:20:35 -0400 (EDT) Message-ID: <51C5F8F0.6020309@network-heretics.com> Date: Sat, 22 Jun 2013 15:20:16 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Barry Leiba References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C3FBBC.4050504@gmx.de> <51C4DE1F.2090704@network-heretics.com> <51C55B71.9050504@gmx.de> <51C5786B.6000708@network-heretics.com> <51C5795E.9070702@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "urn@ietf.org" Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 19:21:02 -0000 On 06/22/2013 09:16 AM, Barry Leiba wrote: > >> Really I suspect that the idea that a query is "part of" any URI is a mistake. >> It makes more sense for the named resource to be the engine to which a query >> is submitted, than for the named resource to be the query result. > I mostly agree with this. The trouble with what I say above is that > if I say that the queries in (1) and (3) above are part of the URNs, > and the queries in the others aren't, then how is anyone looking at > the URN supposed to know that? (I neglected to address this bit in my previous response.) First, I think it's probably too confusing to say that a query string that is bundled with a URN, isn't "part of" a URN. No matter what we say in an RFC, people are going to think of whatever goes between quotes in an or or any other context in which a URI appears, as all being "part of" that URI, and they won't parse URNs any differently in that respect. I'm still not really comfortable with the idea that there will be things that begin with 'urn:' that aren't persistent. But trying to finesse that issue by saying that the query or fragment isn't "part of" the URN seems much more likely to cause confusion than simply declaring that when a URN contains a query string or a fragment, persistence is assured only for the "base" URN and not the entire URN. And if it's "probably" too confusing to say that a query string that's bundled with a URN isn't "part of" the URN, it's certainly too confusing to say that some queries are "part of" a URN while others are not. But that's also an illustration of why I think it's important to carefully specify the actual behavior of the various roles with respect to URNs, rather than hoping that those behaviors will be implied by what is or is not "part of" the URN. Keith From julian.reschke@gmx.de Sun Jun 23 03:28:20 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7856321F9B98 for ; Sun, 23 Jun 2013 03:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEpkCNcm0OB6 for ; Sun, 23 Jun 2013 03:28:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5A79021F9C6A for ; Sun, 23 Jun 2013 03:28:14 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MaoXk-1Uag2p1aFW-00KTky for ; Sun, 23 Jun 2013 12:28:13 +0200 Received: (qmail invoked by alias); 23 Jun 2013 10:28:12 -0000 Received: from p54BB2AB8.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [84.187.42.184] by mail.gmx.net (mp016) with SMTP; 23 Jun 2013 12:28:12 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX191hNx7y6117DBASL1U2O0yIZmyja3R0U44UQ5xIs p1IlyKpwIZTUW8 Message-ID: <51C6CDB1.8010305@gmx.de> Date: Sun, 23 Jun 2013 12:28:01 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Keith Moore References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C3FBBC.4050504@gmx.de> <51C4DE1F.2090704@network-heretics.com> <51C55B71.9050504@gmx.de> <51C5786B.6000708@network-heretics.com> <51C5795E.9070702@gmx.de> <51C5F8F0.6020309@network-heretics.com> In-Reply-To: <51C5F8F0.6020309@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 10:28:20 -0000 On 2013-06-22 21:20, Keith Moore wrote: > On 06/22/2013 09:16 AM, Barry Leiba wrote: >> >>> Really I suspect that the idea that a query is "part of" any URI is a >>> mistake. >>> It makes more sense for the named resource to be the engine to which >>> a query >>> is submitted, than for the named resource to be the query result. >> I mostly agree with this. The trouble with what I say above is that >> if I say that the queries in (1) and (3) above are part of the URNs, >> and the queries in the others aren't, then how is anyone looking at >> the URN supposed to know that? > > (I neglected to address this bit in my previous response.) > > First, I think it's probably too confusing to say that a query string > that is bundled with a URN, isn't "part of" a URN. No matter what we > say in an RFC, people are going to think of whatever goes between quotes > in an or or any other context in which a > URI appears, as all being "part of" that URI, and they won't parse URNs > any differently in that respect. Absolutely! > ... Best regards, Julian From ri@semanticidentity.com Sun Jun 23 04:28:23 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038C721F9C9E for ; Sun, 23 Jun 2013 04:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86yTf+1FLKNZ for ; Sun, 23 Jun 2013 04:28:17 -0700 (PDT) Received: from rigel.websiteactive.com (rigel.websiteactive.com [202.191.62.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4B721F9C98 for ; Sun, 23 Jun 2013 04:28:16 -0700 (PDT) Received: from c211-31-36-79.rochd5.qld.optusnet.com.au ([211.31.36.79]:55172 helo=[192.168.1.4]) by rigel.websiteactive.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UqiSp-002B1M-OH; Sun, 23 Jun 2013 21:28:11 +1000 Content-Type: multipart/alternative; boundary="Apple-Mail=_BE1D9545-1AB4-4F35-A5C2-7D34C38206A0" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Renato Iannella In-Reply-To: <51C3C1EB.7050007@network-heretics.com> Date: Sun, 23 Jun 2013 21:28:10 +1000 Message-Id: References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rigel.websiteactive.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - semanticidentity.com X-Get-Message-Sender-Via: rigel.websiteactive.com: authenticated_id: ri@semanticidentity.com X-Source: X-Source-Args: X-Source-Dir: Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 11:28:23 -0000 --Apple-Mail=_BE1D9545-1AB4-4F35-A5C2-7D34C38206A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 21 Jun 2013, at 13:00, Keith Moore = wrote: > Why should the semantics of queries or fragments attached to URNs be = specific to the namespace? =20 Because that was why it was called the namespace-specific-string....it = was designed to allow the community to support its own requirements, not = force on them any current mechanism for fragment/query or anything else = that we _currently_ do - but may not in the future. Cheers... Renato Iannella Semantic Identity http://semanticidentity.com Mobile: +61 4 1313 2206 --Apple-Mail=_BE1D9545-1AB4-4F35-A5C2-7D34C38206A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 moore@network-heretics.com&= gt; wrote:
Why should the semantics of = queries or fragments attached to URNs be specific to the = namespace?   
Cheers...
Renato = Iannella
Semantic Identity
=
Mobile: +61 4 1313 2206
= --Apple-Mail=_BE1D9545-1AB4-4F35-A5C2-7D34C38206A0-- From moore@network-heretics.com Sun Jun 23 07:37:04 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA56D21F9D4E for ; Sun, 23 Jun 2013 07:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRfxhZtKElsX for ; Sun, 23 Jun 2013 07:36:59 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5E721F9D1A for ; Sun, 23 Jun 2013 07:36:59 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id 71C8D213AC; Sun, 23 Jun 2013 10:36:58 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Sun, 23 Jun 2013 10:36:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type; s=smtpout; bh=mUJX lIrWMIpgDzmz+6voP5NHWJ0=; b=OVE4bGrSyWGTq4L18vNcM4HbU/66S80xHWzL NvPh/ACJCOBV95R88l9sLskbcnhjLEJGDgm+t+m4VcsEuv4HiC3mJZW4XS4rd8O0 Jifdi61EEekzez84HuH1wdG5bIDp07Fhwg6v3O/kC8zfY/d3wbhTIS+PRhsTmgiQ pRzvoWQ= X-Sasl-enc: c8mssR801oDNziVmSdxX81yj1YxjkM8MyX04PsL9+Y23 1371998217 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 6A179680248; Sun, 23 Jun 2013 10:36:57 -0400 (EDT) Message-ID: <51C707F3.1070203@network-heretics.com> Date: Sun, 23 Jun 2013 10:36:35 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Renato Iannella References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080302070103050507080708" Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 14:37:04 -0000 This is a multi-part message in MIME format. --------------080302070103050507080708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/23/2013 07:28 AM, Renato Iannella wrote: > > On 21 Jun 2013, at 13:00, Keith Moore > wrote: > >> Why should the semantics of queries or fragments attached to URNs be >> specific to the namespace? > > Because that was why it was called the namespace-specific-string....it > was designed to allow the community to support its own requirements, > not force on them any current mechanism for fragment/query or anything > else that we _currently_ do - but may not in the future. Yes, but as URNs are currently defined, the NSS cannot contain a query or a fragment - precisely because at the time that 2141 was written, we didn't know how to make them work. And I would propose that we extend the URN syntax in such a way that the query or fragment is not part of the NSS, but instead appears after the NSS. This wouldn't invalidate current URN syntax. Keith --------------080302070103050507080708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/23/2013 07:28 AM, Renato Iannella wrote:

On 21 Jun 2013, at 13:00, Keith Moore <moore@network-heretics.com> wrote:

Why should the semantics of queries or fragments attached to URNs be specific to the namespace?   

Because that was why it was called the namespace-specific-string....it was designed to allow the community to support its own requirements, not force on them any current mechanism for fragment/query or anything else that we _currently_ do - but may not in the future.

Yes, but as URNs are currently defined, the NSS cannot contain a query or a fragment - precisely because at the time that 2141 was written, we didn't know how to make them work.    And I would propose that we extend the URN syntax in such a way that the query or fragment is not part of the NSS, but instead appears after the NSS.    This wouldn't invalidate current URN syntax.

Keith

--------------080302070103050507080708-- From michael@refactored-networks.com Sun Jun 23 13:11:38 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCE921F9A65 for ; Sun, 23 Jun 2013 13:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db+76iEUSggh for ; Sun, 23 Jun 2013 13:11:30 -0700 (PDT) Received: from smtp-out-1.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 543EE21F9A5B for ; Sun, 23 Jun 2013 13:11:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 76997294001; Sun, 23 Jun 2013 15:11:27 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8PELdyq6KpV; Sun, 23 Jun 2013 15:11:27 -0500 (CDT) Received: from smtp-out-1.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 53336294015; Sun, 23 Jun 2013 15:11:27 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3DBBE294001; Sun, 23 Jun 2013 15:11:27 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id alLvRIRbhFS5; Sun, 23 Jun 2013 15:11:27 -0500 (CDT) Received: from [192.168.1.100] (c-98-192-98-17.hsd1.ga.comcast.net [98.192.98.17]) by smtp-out-1.01.com (Postfix) with ESMTPSA id CD895294007; Sun, 23 Jun 2013 15:11:26 -0500 (CDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Mealling In-Reply-To: Date: Sun, 23 Jun 2013 16:11:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E0E667E-0A0C-4E27-B454-E0AF8BA7D66D@refactored-networks.com> References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C707F3.1070203@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1503) Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 20:11:38 -0000 Just out of curiosity and possible clarity, is there a document that = shows example of what people are proposing to do with query strings and = fragments with URNs? -MM Michael Mealling Co-Founder Pipefish.com +1-678-640-6884 @mmealling Schedule a meeting: http://meetme.so/michaelmealling From moore@network-heretics.com Sun Jun 23 13:45:33 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B7A21F9F02 for ; Sun, 23 Jun 2013 13:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR2jWxQlUqL5 for ; Sun, 23 Jun 2013 13:45:28 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5339F21F9D1D for ; Sun, 23 Jun 2013 13:45:27 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway2.nyi.mail.srv.osa (Postfix) with ESMTP id E3FE62132A; Sun, 23 Jun 2013 16:45:26 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 23 Jun 2013 16:45:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=gQhj+B66aLrIwCTpKZDe9s 77N8A=; b=MQBv1Z7eo9LttG5smj7KibxIEfOdCcKTG+rfmuP4rRfvxpTrrbiFlY Glvz+hHDphQVmg1RnAYC+ec9osztWJy1/6Pm0vBrELyZlIYenPf47RgC2MvD26cs W7yJ37SmseteLoczHqPwLxSZXzdnXET4gvz7MpqyjJHgFSAFjaBYA= X-Sasl-enc: wkWK+J7sGIE06cCq5krZ7rO9JfyAKoKc4VBsEsWuXLR8 1372020326 Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0B859680462; Sun, 23 Jun 2013 16:45:25 -0400 (EDT) Message-ID: <51C75E4F.9020803@network-heretics.com> Date: Sun, 23 Jun 2013 16:45:03 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Mealling References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C707F3.1070203@network-heretics.com> <9E0E667E-0A0C-4E27-B454-E0AF8BA7D66D@refactored-networks.com> In-Reply-To: <9E0E667E-0A0C-4E27-B454-E0AF8BA7D66D@refactored-networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 20:45:33 -0000 On 06/23/2013 04:11 PM, Michael Mealling wrote: > Just out of curiosity and possible clarity, is there a document that shows example of what people are proposing to do with query strings and fragments with URNs? I'd be interested in such a document (or maybe several documents, each from different parties) also. Keith From juha.hakala@helsinki.fi Mon Jun 24 05:09:52 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814C111E8136 for ; Mon, 24 Jun 2013 05:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51WeqkaFHAxi for ; Mon, 24 Jun 2013 05:09:48 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id E714911E8131 for ; Mon, 24 Jun 2013 05:09:46 -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 r5OC9gCH001180 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 24 Jun 2013 15:09:43 +0300 Message-ID: <51C83706.2050508@helsinki.fi> Date: Mon, 24 Jun 2013 15:09:42 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: urn@ietf.org References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C707F3.1070203@network-heretics.com> <9E0E667E-0A0C-4E27-B454-E0AF8BA7D66D@refactored-networks.com> In-Reply-To: <9E0E667E-0A0C-4E27-B454-E0AF8BA7D66D@refactored-networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 12:09:52 -0000 Hello, Our plan here in Finland is to allow the use of fragments to specify locations within documents that have been previously identified with URNs. From library point of view, identification of a (persistent) resource is a non-trivial act, preferably performed by professionals who apply well established written rules which are identifier system (that is, namespace) specific. For instance, a book which is published in three volumes and many parallel forms (for instance, hardback, paperback, PDF) receives many ISBNs, as dictated by the ISBN rules. For each form there should be one ISBN to cover all three volumes, and then one for each volume. Therefore there will be e.g. urn:isbn:foo for the PDF version of the volume 3. This ISBN should never be re-assigned to another book or later manifestation of the same book, such as volume 3 in EPUB 3 format. That book will get a different ISBN; metadata records describing the two versions will be linked to one another and to the record describing the (immaterial) work. [I am well aware that some publishers do not use ISBNs correctly. But there are also people who jaywalk, and nobody argues that there should not be traffic lights for pedestrians because of that.] It is not feasible to extend the act of formal identifier assignment to fragments, such as chapter 1 of volume 3. This would be too time consuming, and our existing identifier systems for (digital) manifestations such as ISBN for books as a rule do not allow extensions for e.g. fragment identification. Also, it is impossible to know in advance what kind of fragment identification will be desired by the users. So, we want to allow our users - that is, all sorts of lay people who are not familiar with the principles of how to apply bibliographic identifiers - to specify fragments when they need to e.g. make a reference to certain location of a book that has previously been identified with e.g. urn:isbn. The resulting URI (urn:isbn:foo#bar) will be, due to the ISBN application rules, tied to the PDF manifestation of the volume 3 of the book, so after a while some digital archaeology will be needed to guarantee that the document can be displayed to the user. But the URN + fragment combo will be as persistent as the base URN. If the book is held in national bibliography collection there will be more modern versions of the resource with different URNs; the user will find out about them with the help of resource metadata. Using the same identifier for all these versions would be an abomination, given that there will be significant differences in look and feel and perhaps also in intellectual content between them. In this model, fragment is not and must not be part of the identifier (namespace specific string). It follows that fragment does not identify anything, it is only used to indicate a location within the identified document. Fragments can be used whenever they are applicable (based on RFC 3986). This means, among other things, that fragments can only be applied in namespaces which deal with identification of (digital) manifestations when locations within these resources can be pinpointed with RFC 3986. And anyone can add fragment to an existing URN any time after the URN has been assigned. Our need to use queries is based on the fact that there are a lot of URN resolution services already, and when the applications used by libraries, archives, museums etc. multiply, it will be possible to use additional services that we can't even imagine now. I agree with the view that using fragments is easier than using queries because fragments are always applied to resources that have already been identified (persistently). Any identifier system (URN namespace) which can be used to identify resource manifestations such as PDF versions of books can benefit from fragment use; being able to use fragments would significantly broaden the scope of e.g. the ISBN system. Identifier systems which do not identify tangible documents (such as ISSN which identifies periodicals and ISTC which identifies textual works) will not be able to benefit from fragments since it is a priori impossible to use fragments with e.g. urn:istc. Queries, however, are not namespace dependent. The resolution services available will depend on technical infrastructure the URN resolver can use. For instance, if somebody uses URN resolver to require resource metadata from the National Library of Finland now, we would be able to supply just descriptive metadata (author, title, isbn etc.). In 2023 our URN resolver should be able to provide also administrative metadata (rights information; technical metadata about a text document; preservation metadata describing the changes due to the file format migration) as well. But in order to supply this information, we need digital archive (which contains this metadata) and a mechanism with which to pass service related parameters to the resolver, so that the query can be passed to the correct target. National libraries are already building international resolver networks. If these service parameters are local, maintaining these networks will become difficult. There is a need to agree on services and service parameters to avoid plenty of re-invention of wheels. Some people participating in the discussion have expressed the view that an URN + query identifies a different resource than the base URN. I disagree: query is not part of the NSS. From library point of view, the identified resource remains the same, only the resource related resolution service required changes. Then anyone (a human or an application) can add a query to an existing URN any time after the URN has been assigned, without any limitations apart from those imposed by the resolver and the rest of the technical infrastructure. There is of course one interesting borderline case here. One of the services could (and should) be "migrate this document to file format X and deliver it to me". For instance, I may be unable to read OOXML documents and therefore want the document in PDF/A. In such a case, there is a need to specify migration service (in this particular case, migration has to take place in two steps: first to PDF with Office, and then to PDF/A with Acrobat for reasons which are obvious to anyone who has ever tested this migration). But if the resulting PDF/A file is preserved for long term and therefore identified, the act of identification will be independent of the user and resolution service which migrated the document to the new file format. Best regards, Juha On 23.6.2013 23:11, Michael Mealling wrote: > Just out of curiosity and possible clarity, is there a document that shows example of what people are proposing to do with query strings and fragments with URNs? > > -MM > > Michael Mealling > Co-Founder > Pipefish.com > +1-678-640-6884 @mmealling > Schedule a meeting: http://meetme.so/michaelmealling > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293