From nobody Sun Nov 2 22:52:57 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFD81A1A5F for ; Sun, 2 Nov 2014 22:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZIHM31_mmXs for ; Sun, 2 Nov 2014 22:52:54 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E1D1A1A5B for ; Sun, 2 Nov 2014 22:52:54 -0800 (PST) Received: from [192.168.123.151] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 76B7E509B5; Mon, 3 Nov 2014 01:52:51 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <5452D0B5.8060008@network-heretics.com> Date: Mon, 3 Nov 2014 01:52:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Q-OaQ37Thr8-2xQ6wHK0CQzPqnI Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 06:52:56 -0000 On Oct 30, 2014, at 7:58 PM, Keith Moore = wrote: > On 10/30/2014 07:55 PM, "Martin J. D=FCrst" wrote: >>>> What I'm pushing for is a spec that is sufficiently clear that the >>>> relative resolution algorithm defined by RFC 3986 indeed applies to >>>> URN URIs, even though the results it yields for most URN schemes = might >>>> not be very useful. >>=20 >> The relative resolution algorithm applies to any and all schemes = (including URNs) where it is applied. >=20 > Sorry, that's just insane. It makes no technical sense whatsoever. = 3986 is simply incorrect, and needs to be obsoleted and move to = Historic. >=20 > Keith All of this frustration with relative references and URNs illustrates a = general point: Since relative references don=92t make sense with URNs, URNs SHOULD NOT = include slash / characters. That is why it looks like urn:ietf:rfc:3986 and not urn:/ietf/rfc/3986. In the case of a syntax like urn:/ietf/rfc/3986, a relative reference to = =93../std/1=94 makes technical sense and common sense. But URNs are not = like that, because =93ietf=94 and =93rfc=94 are not path containers = (e.g., directories); they are more like prefixes that disambiguate the = last part (3986) to make the last part more universal. In fact there is = no semantic difference between urn:ietf:rfc:3986, and urn:ietf-rfc:3986; = one could register the ietf-rfc namespace identifier with no loss of URN = namespace uniqueness or persistence guarantees. The point of the : style is that it doesn=92t participate in / path = segregation. Sean From nobody Sun Nov 2 22:57:18 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46F71A1A5E for ; Sun, 2 Nov 2014 22:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of2FPg69FXQJ for ; Sun, 2 Nov 2014 22:57:16 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E2B1A1A5D for ; Sun, 2 Nov 2014 22:57:16 -0800 (PST) Received: from [192.168.123.151] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D1EBE509B6 for ; Mon, 3 Nov 2014 01:57:14 -0500 (EST) From: Sean Leonard Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 3 Nov 2014 01:57:12 -0500 To: urn@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/yj-V-hjH80XwOYd5gSncVHNgYu0 Subject: [urn] exemplary URNs for revised URN syntax X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 06:57:17 -0000 It would be helpful for this URNBIS discussion if we can agree on a = common set of exemplary URN namespaces, where there is rough consensus = that whatever URNs are supposed to be, these URN namespaces are = =93quality=94 and we can all think about them for the purpose of making = cogent arguments. I consider the following namespaces to be exemplary: urn:isbn urn:ucode urn:issn urn:ietf urn:oid urn:uuid urn:lex [latest Internet-Draft] Anything else? Sean= From nobody Mon Nov 3 07:16:04 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E125D1A03A6 for ; Mon, 3 Nov 2014 07:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCxYCYWTNB2A for ; Mon, 3 Nov 2014 07:15:49 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A67D1A040B for ; Mon, 3 Nov 2014 07:15:05 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7AE9420A32 for ; Mon, 3 Nov 2014 10:15:04 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 03 Nov 2014 10:15:04 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=LLFx0V1g+bt7q65cRvqHTt wLBoI=; b=nU4R/hXV30qDBy9ZR3TeW1hlv56myvFOs5JJbthygcK217rCu9CdgY swluKyRE1H8W1ghxHndya9/TPAlCX2I/yAftyb/7w/iAVbEkhWLl/z+0gMj/bpAZ yoKRaWCOZw+ku0BWobfro1K50lB1KCdX6I24pgKm+V3DIMpSOVYPA= X-Sasl-enc: FzgregFJ0y4RUrAdpgOY5aylTK0+0HGDYDUhe/tdtlIe 1415027704 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id EEDF9C00011; Mon, 3 Nov 2014 10:15:03 -0500 (EST) Message-ID: <54579BED.9000503@network-heretics.com> Date: Mon, 03 Nov 2014 10:14:53 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Leonard References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/BNyJkJW2PiIXKA6sKSoHjFMjmSM Cc: urn@ietf.org Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 15:16:00 -0000 On 11/03/2014 01:52 AM, Sean Leonard wrote: > All of this frustration with relative references and URNs illustrates a general point: > > Since relative references don’t make sense with URNs, URNs SHOULD NOT include slash / characters. > > That is why it looks like urn:ietf:rfc:3986 and not urn:/ietf/rfc/3986. Having hosted the Knoxville meeting where we first got some agreement on the syntax, I don't recall that being part of the discussion. But the intent was certainly that URNs wouldn't look like URLs, other than having a similar prefix and not using any of the characters not allowed for URLs. If using "/" in a URN makes people more likely to think that URNs make sense with relative URIs, then by a similar argument using "?" makes people more likely to think that queries can be applied to the resources named by URNs, and using "#" makes people more likely to assume that HTML-style fragments make sense with URNs. In the past I've argued fairly vigorously that if "?" and "#" are applied to URNs that they should have very similar meanings as when they are used with URLs - namely that "?" be used for queries submitted to the resource itself (and not, say, to the resolution service), and "#" should be used to identify fragments determined by the content of the resource, as they are in HTML. But if we extend the same logic to "/" and relative URIs then we paint ourselves into a corner where it's not possible to have any modifiers for URNs at all. So maybe you and I both should reconsider our positions on the meanings of these characters as applied to URNs? Keith From nobody Mon Nov 3 08:12:35 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C19B1A0404 for ; Mon, 3 Nov 2014 08:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNK1GhrbHAZ4 for ; Mon, 3 Nov 2014 08:12:29 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23CB1A008D for ; Mon, 3 Nov 2014 08:12:28 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5ED3C20A11 for ; Mon, 3 Nov 2014 11:12:28 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 03 Nov 2014 11:12:28 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=UcQdjFLSgBSihI5qGonV4Z aBmAM=; b=UW1G1YXgRoKCJsP9/Sa8aKrTJ2RmXrMD5A5TY5dSKHlIYqIh5FIvi7 LJ+99GmiAa5ytIWgsjOBe/PHi7s/wDCyWiB0LDDqRoq6VQ6fYfCNof30OS4dn7At Y80YrxSvRZgvQwsXmaKZdrhTMAxk4Myf9mqh+gS07TGEweBcv2vJg= X-Sasl-enc: icalrroBxlQ2y8XuwTFJbpDKk8HXvZmE2DRniv2+u33v 1415031148 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id E7FB168015E; Mon, 3 Nov 2014 11:12:27 -0500 (EST) Message-ID: <5457A96B.2020406@network-heretics.com> Date: Mon, 03 Nov 2014 11:12:27 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/JmAruqFhrbkaLGJ4GFQI70_2bKE Subject: Re: [urn] exemplary URNs for revised URN syntax X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 16:12:33 -0000 On 11/03/2014 01:57 AM, Sean Leonard wrote: > It would be helpful for this URNBIS discussion if we can agree on a common set of exemplary URN namespaces, where there is rough consensus that whatever URNs are supposed to be, these URN namespaces are “quality” and we can all think about them for the purpose of making cogent arguments. > > I consider the following namespaces to be exemplary: > urn:isbn > urn:ucode > urn:issn > urn:ietf > urn:oid > urn:uuid > urn:lex [latest Internet-Draft] The problem with casting things in this light is that URNs were originally intended to be identifiers for network-accessible resources. Even though they were considered suitable as names for other kinds of resources, the primary reason for creating URNs was that there wasn't a good stable naming scheme for resources accessible over the network. Most of the examples you've cited above don't really fit that pattern. And in a desire to better accommodate use of URNs with non-network-accessible resources, there's been an unfortunate tendency to want to compromise URNs' suitability for network-accessible resources (say by repurposing query syntax in such a way that it can no longer be used to query the resource itself, or by allowing interpretation of modifiers to vary on a per-NID basis). So while it's fine to cite examples from time to time, please don't get into the habit of thinking that these examples really illustrate what URNs are. URNs are still in their infancy, and if we are at all successful, they're likely to get used in many more ways in the future than they are at present. Keith From nobody Mon Nov 3 08:21:47 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DF51A0469; Mon, 3 Nov 2014 08:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHCBCcZhzJH7; Mon, 3 Nov 2014 08:21:41 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB281A19FC; Mon, 3 Nov 2014 08:21:38 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XlKNp-000Az7-Cr; Mon, 03 Nov 2014 11:21:33 -0500 Date: Mon, 03 Nov 2014 11:21:28 -0500 From: John C Klensin To: alexey.melnikov@isode.com Message-ID: <86601DE9FC5C6E8AB9E981FE@JcK-HP8200.jck.com> In-Reply-To: <20141103130845.9428.55882.idtracker@ietfa.amsl.com> References: <20141103130845.9428.55882.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MH6dtZYmhuSoPWJTp7OIv9v1Z4c Cc: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org, urn@ietf.org, apps-discuss@ietf.org Subject: Re: [urn] [apps-discuss] ID Tracker State Update Notice: X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 16:21:45 -0000 --On Monday, November 03, 2014 05:08 -0800 IETF Secretariat wrote: > IESG state changed to AD Evaluation from Publication Requested > ID Tracker URL: > http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme- > reg/ Alexey and relevant ADs, Independent of its particular merits, I believe this proposal should be put on hold. A controversy has been going on in the URNbis WG for some time that is, at root, how much RFC 3986 constrains the use, assumptions, and semantics of various URIs, including, but not limited to URNs (i.e., URI-format identifiers that use the "urn:" scheme) and more general name, or even "urn", systems that use other schemes. At times in that discussion, several people have proposed that some things people want to do with URNs would be ok in a different scheme, but not the "urn:" one. Keeping in mind that there is no requirement for URNs to resolve and that some of our URI assumptions include resolution, if such additional schemes were created, the community would presumably need to review their relationship to various understandings of RFC 3986 as well. Neither the AppsAWG nor, as far as I know, anyone else has done a careful review of draft-ietf-appsawg-uri-scheme-reg against developments and discussions in URNBIS. It cannot be evaluated against the conclusions of URNBIS because, at least based on consensus statements by the Chair or co-Chairs, such conclusions have not been reached. The above creates a situation in which we could either end up issuing contradictory standards or or in which the advancement of this specification could be used to turn the task of URNBIS from "difficult" to "impossible without making URNs much less useful". Consequently, this specification should either be put on hold until after URNBIS successfully concludes its work or should be assigned to URNBIS for a pre-IETF-LC review and progressed into IETF LC only after URNBIS has affirmatively reached consensus that it does not pose a problem. regards, john From nobody Mon Nov 3 08:24:31 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB92C1A19F3; Mon, 3 Nov 2014 08:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMjlG69vqfpI; Mon, 3 Nov 2014 08:24:29 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25C91A19E4; Mon, 3 Nov 2014 08:24:25 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gq15so9882983lab.15 for ; Mon, 03 Nov 2014 08:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/y7x7FhClBWm4poTwLQWuh5h9pc8JPnCaLUOXQRz2Xo=; b=T/soyARZ316px8Iz7r6vjErQfTiO3IGs1bqIDdv+qlZIPLRnmalacUR5Jk5JKpcIwH xT7Rbu/F4vdC5jGdIY1DEVssg001gWSZ/TciLhCGYwhUtZp1SOnCEv86H/BvZcf4cIiD t6VZFPrX4OmxoVLc6NkJdDeQjLspSBaM6mxLbygR3Oh4PlNCu1zYOtgwO4x0Bm21ur14 qLmv49LAnrNd80KrDc1+jNbxIGfq2m+e2IJVXEGO0vfI37zObSVQHiV18jsNXm3lSGKW ecoT8Kz2qDxdrzkXAbGrqwa/XKRF9rT0/0DIc8oyYKaenopgWOOBWA3u2HCeukDf6Usu JZyQ== MIME-Version: 1.0 X-Received: by 10.112.132.104 with SMTP id ot8mr51942865lbb.3.1415031863918; Mon, 03 Nov 2014 08:24:23 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Mon, 3 Nov 2014 08:24:23 -0800 (PST) In-Reply-To: <86601DE9FC5C6E8AB9E981FE@JcK-HP8200.jck.com> References: <20141103130845.9428.55882.idtracker@ietfa.amsl.com> <86601DE9FC5C6E8AB9E981FE@JcK-HP8200.jck.com> Date: Mon, 3 Nov 2014 11:24:23 -0500 X-Google-Sender-Auth: 1EE_foDAFu0melFYPMlkWI71g3k Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/SV0FOGlg4Qv5V7HznyLqSi2tEmY Cc: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org, Alexey Melnikov , "urn@ietf.org" , Apps Discuss Subject: Re: [urn] [apps-discuss] ID Tracker State Update Notice: X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 16:24:31 -0000 So noted. There is also a discussion going on with W3C about URIs, IRIs, and URLs, which has to be resolved before this document moves ahead. I'll be holding it in AD Evaluation state, and making sure the appropriate groups and people get involved before we continue, Barry, the relevant AD On Mon, Nov 3, 2014 at 11:21 AM, John C Klensin wrote: > > > --On Monday, November 03, 2014 05:08 -0800 IETF Secretariat > wrote: > >> IESG state changed to AD Evaluation from Publication Requested >> ID Tracker URL: >> http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme- >> reg/ > > Alexey and relevant ADs, > > Independent of its particular merits, I believe this proposal > should be put on hold. A controversy has been going on in the > URNbis WG for some time that is, at root, how much RFC 3986 > constrains the use, assumptions, and semantics of various URIs, > including, but not limited to URNs (i.e., URI-format identifiers > that use the "urn:" scheme) and more general name, or even > "urn", systems that use other schemes. At times in that > discussion, several people have proposed that some things people > want to do with URNs would be ok in a different scheme, but not > the "urn:" one. Keeping in mind that there is no requirement > for URNs to resolve and that some of our URI assumptions include > resolution, if such additional schemes were created, the > community would presumably need to review their relationship to > various understandings of RFC 3986 as well. > > Neither the AppsAWG nor, as far as I know, anyone else has done > a careful review of draft-ietf-appsawg-uri-scheme-reg against > developments and discussions in URNBIS. It cannot be evaluated > against the conclusions of URNBIS because, at least based on > consensus statements by the Chair or co-Chairs, such conclusions > have not been reached. > > The above creates a situation in which we could either end up > issuing contradictory standards or or in which the advancement > of this specification could be used to turn the task of URNBIS > from "difficult" to "impossible without making URNs much less > useful". Consequently, this specification should either be put > on hold until after URNBIS successfully concludes its work or > should be assigned to URNBIS for a pre-IETF-LC review and > progressed into IETF LC only after URNBIS has affirmatively > reached consensus that it does not pose a problem. > > regards, > john > > From nobody Mon Nov 3 08:51:00 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6B91A1A17 for ; Mon, 3 Nov 2014 08:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN5taUT1Z7Re for ; Mon, 3 Nov 2014 08:50:54 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683171A0211 for ; Mon, 3 Nov 2014 08:50:54 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-11v.sys.comcast.net with comcast id B4mZ1p00726dK1R014qt9j; Mon, 03 Nov 2014 16:50:53 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-01v.sys.comcast.net with comcast id B4qr1p00S1KKtkw014qsP4; Mon, 03 Nov 2014 16:50:53 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id sA3GopIs029718; Mon, 3 Nov 2014 11:50:51 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sA3GooRa029717; Mon, 3 Nov 2014 11:50:50 -0500 Date: Mon, 3 Nov 2014 11:50:50 -0500 Message-Id: <201411031650.sA3GooRa029717@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Sean Leonard In-reply-to: (dev+ietf@seantek.com) References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415033453; bh=IidQ8E9qpVCWWxy+DhnWfZtpPd/slkHrlfgCpp2UXqs=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject:MIME-version:Content-type; b=K3WeQ2V8kIHaPrKUwUjWKozqIbGKlJL1Bq2QcFnbpLor1kuH7r8QST9x2Nebz8twO Et6Jbo5f4N/F3LPtlfFtyKIaX5Smnpll6FdsidqZqJEm7IE64+MsYOOP9tHfSuV8Af AAqf0MpFG3NmNuzjU2Wt8wtC9ekMoOjznYvf1RnFokyCy4zPdDfkKlvUizjHtnDs+P pT76d7jAQ2bFbSEL1KrHcicxI7Ydj5gaomDokngAq/Ds15MrVPqT1NVIwvxsu0YP+q 478b1yDBoxkRCDVbOvaxyy1VBrU5d60vVIUGas9T1iWzhkFCripPs1F9bgv7Dl7GbT PsVEaIN58USiA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/8UBUMSlO7fNhBlVo1Ib5ZVxsSZA Cc: urn@ietf.org, moore@network-heretics.com Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 16:50:57 -0000 > From: Sean Leonard > All of this frustration with relative references and URNs > illustrates a general point: > > Since relative references don’t make sense with URNs, URNs SHOULD > NOT include slash / characters. Or we can look at this as a design rule: If relative references have a defined meaning, use "/" to separate the relevant substrings. If relative references do not have a defined meaning, forbid "/". Dale From nobody Mon Nov 3 08:51:20 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A1C1A1A33; Mon, 3 Nov 2014 08:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INjYHBEOe6ep; Mon, 3 Nov 2014 08:51:15 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02F01A1A1B; Mon, 3 Nov 2014 08:51:15 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XlKqT-000B3D-Uw; Mon, 03 Nov 2014 11:51:09 -0500 Date: Mon, 03 Nov 2014 11:51:04 -0500 From: John C Klensin To: Barry Leiba Message-ID: <517D07E9E55809F8F97AA169@JcK-HP8200.jck.com> In-Reply-To: References: <20141103130845.9428.55882.idtracker@ietfa.amsl.com> <86601DE9FC5C6E8AB9E981FE@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 X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/ERcz2b-VYehPpv2nOscdI5Ni0S0 Cc: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org, Alexey Melnikov , urn@ietf.org, Apps Discuss Subject: Re: [urn] [apps-discuss] ID Tracker State Update Notice: X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 16:51:17 -0000 --On Monday, November 03, 2014 11:24 -0500 Barry Leiba wrote: > So noted. There is also a discussion going on with W3C about > URIs, IRIs, and URLs, which has to be resolved before this > document moves ahead. I'll be holding it in AD Evaluation > state, and making sure the appropriate groups and people get > involved before we continue, Thanks Barry. Exactly what I had hoped for and consider appropriate. Let me also use this as an advertisement: people in AppsAWG who are interested in or concerned about this topic and who have not been following the URNBIS work, probably want to do so. Having issues and positions emerge within WG discussions rather than during IETF Last Call is always A Good Thing. john From nobody Mon Nov 3 09:10:35 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDB21A1A2D for ; Mon, 3 Nov 2014 09:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2bRTMD_w3Nt for ; Mon, 3 Nov 2014 09:10:24 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 591DB1A1A45 for ; Mon, 3 Nov 2014 09:10:20 -0800 (PST) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 240538ACF0; Mon, 3 Nov 2014 18:10:19 +0100 (CET) From: "Svensson, Lars" To: Peter Saint-Andre - &yet Thread-Topic: [urn] next steps Thread-Index: AQHP7V7HekgaAeYQB0mP2LtKG+am3JxPMGHQ Date: Mon, 3 Nov 2014 17:10:17 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC5F43C@dnbf-ex1.AD.DDB.DE> References: <5446A902.4030904@andyet.net> In-Reply-To: <5446A902.4030904@andyet.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.84] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/GhRTHSWZd_IooPNVRTzIYlIf8EM Cc: "urn@ietf.org" Subject: Re: [urn] next steps X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 17:10:30 -0000 Peter, all, > I have a revised I-D almost ready for consideration by the WG, which I > plan to submit tonight. >=20 > Two things to note: >=20 > 1. Because of his significant contributions to the concepts and text, I > have added John Klensin as co-author. >=20 > 2. To reduce confusion and cross-references (and with approval of the WG > chairs), I have combined 2141bis and 3406bis into a single document that > covers both URN syntax and URN namespaces. >=20 > Naturally, there are still some open issues being discussed on the list. > I cannot promise that the revised I-D closes them all, but I think it > brings us much closer to having a specification we can live with. Having finally come around to read 2141bis-08, it certainly brings me towar= ds a spec I can live with. There are some things I have issues with (partic= ularly the relation between q-components and resolvers), but I'm not concer= ned enough about them that I'd try to stop it from becoming a specification= .=20 Comments (please read them in the light of the above): 1) =A71 states that "a string that conforms to the URN syntax is not necess= arily a valid URN [...]." Is there a way to find out if something just look= s like a URN or if it actually is one? If so, I think we should add some te= xt explaining that. 2) My reading of =A73 is that p-component is not part of the NSS. Is that c= orrect? If so, the URN comparison becomes a bit counter-intuitive since the= p-component is used to determine comparison and it would be easier to stat= e that for comparison, only the schema, the NID and the NSS are relevant. 3) The last sentence in =A73 has two verbs in it (describe provide), to me = "provide" sounds best. 4) =A73.1: This shouldn't be a problem since there currently are no NSS end= ing with '-', but we should add some text about that. 5) =A73.3 (this is my main concern): the third paragraph says "For example,= it is possible that the q-component might be used in requests to URN resol= ution services." I still think that the components of a URN should apply to= the identified resources and not be hijacked to pass information to other = services (e. g. resolvers). Information related to resolution services shou= ld be part of 2483bis. 6) In =A74.2 is would be helpful to have some examples using p-, q- and f-c= omponents, too. 7) =A75: What is a URI browser? A short search did not reveal any really us= eful information... So yes, from me there is rough consensus that we can move forward with this= . Best, Lars From nobody Mon Nov 3 13:15:02 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDA41A871E for ; Mon, 3 Nov 2014 13:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCI22rVNxPOc for ; Mon, 3 Nov 2014 13:14:59 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5C11A873A for ; Mon, 3 Nov 2014 13:14:58 -0800 (PST) Received: from [172.20.10.3] (unknown [70.197.64.88]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 45B01509B5 for ; Mon, 3 Nov 2014 16:14:56 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_1C8910DB-7087-43F4-9B37-54C503FF6520"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Mon, 3 Nov 2014 13:14:02 -0800 References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54579BED.9000503@network-heretics.com> To: urn@ietf.org In-Reply-To: <54579BED.9000503@network-heretics.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/I_0wkDb7CPljkNYE9NJE2Kt7IT8 Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 21:15:01 -0000 --Apple-Mail=_1C8910DB-7087-43F4-9B37-54C503FF6520 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 3, 2014, at 7:14 AM, Keith Moore = wrote: > On 11/03/2014 01:52 AM, Sean Leonard wrote: >> All of this frustration with relative references and URNs illustrates = a general point: >>=20 >> Since relative references don=92t make sense with URNs, URNs SHOULD = NOT include slash / characters. >>=20 >> That is why it looks like urn:ietf:rfc:3986 and not = urn:/ietf/rfc/3986. > Having hosted the Knoxville meeting where we first got some agreement = on the syntax, I don't recall that being part of the discussion. But = the intent was certainly that URNs wouldn't look like URLs, other than = having a similar prefix and not using any of the characters not allowed = for URLs. >=20 > If using "/" in a URN makes people more likely to think that URNs make = sense with relative URIs, then by a similar argument using "?" makes = people more likely to think that queries can be applied to the resources = named by URNs, and using "#" makes people more likely to assume that = HTML-style fragments make sense with URNs. On Nov 3, 2014, at 8:50 AM, Dale R. Worley wrote: > Or we can look at this as a design rule: If relative references have > a defined meaning, use "/" to separate the relevant substrings. If > relative references do not have a defined meaning, forbid "/". Since I wasn=92t at the Knoxville meeting, perhaps a fresh pair of eyes = (plus just someone new, relatively speaking, to the discussion) can = bring a new perspective. Yes, it appears to be a design rule, or at = least a design principle. It would have made sense for the data: URL to use base64url encoding = rather than basic base64 encoding, but the interactions between relative = references and RFC 3986 weren=92t fully appreciated at that time. In RFC = 3986 parlance, a non-empty hierarchical path can be: authority path-abempty path-absolute path-rootless In the first two cases, the path starts with / . In the last case, / can = appear but not at the start. I=92m not sure if it was by design or = accident, but urn:NID:NSS puts URNs in the class of path-rootless. It = sort of follows that for URI schemes where you don=92t want hierarchical = path processing (syntactically, or semantically), at a minimum you = wouldn=92t want / at the beginning. Ideally, you wouldn=92t use / at = all. It seems logical to me that if an absolute URI has a path part that = starts with / , then it is designed to be used with relative path = processing. If it does not start with / , then that is an implicit = design signal that relative path processing would be relatively [lol] = useless. Widely used URI schemes that do not participate in path = segmentation include: mailto, news, cid, geo, tel.=20 Back to URNs: A lot of URNs seem to divide the namespace with colons : . This seems = reasonable. A better and more consistent approach to URN construction is = inductive. Consider a name, and make it universally unique by prefixing = the name with colon-separated namespace dividers. Thus: 3986 rfc:3986 ietf:rfc:3986 urn:ietf:rfc:3986 Sean= --Apple-Mail=_1C8910DB-7087-43F4-9B37-54C503FF6520 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTEwMzIxMTQ1NFowIwYJKoZIhvcNAQkEMRYEFP7EY/6Zu6TvggfI7wxczIGO 5OHkMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAUJiPBU5RJhMBH3VONi6As9NsI+YCRl+yWW6q47jEU+49wg29FnkcSzdvx9FmOQTvJ1QUOViw /b8eR9hFpUkPZvlCZCTkS1jtBUQWyOA2FyA57WN/ZjO8KISmrvbB5f3G3aYV1reQo/OEXALJOdKO JuWS5/uS5cFNBCRInc5twuONTFPOiumansLnsbIXMMQl1z29tUvKm/3jRVO6RP5xUKGcfix99wBu lwRFYRcA8+OYOKuPMtfBLWcwEGSeEZP029Hb/W7y91rBPU03RXinWBPFiyPF4kxkGqqIiPua+4OM rRKDEYZhIHeFjXUfVZpJPKQlAHD5RjX6vmlPqyQw2wAAAAAAAA== --Apple-Mail=_1C8910DB-7087-43F4-9B37-54C503FF6520-- From nobody Mon Nov 3 13:38:45 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8081A19E3 for ; Mon, 3 Nov 2014 13:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co3Uj_jbQBUO for ; Mon, 3 Nov 2014 13:38:42 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ECB1A06FD for ; Mon, 3 Nov 2014 13:38:41 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1DC3E20944 for ; Mon, 3 Nov 2014 16:38:41 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 03 Nov 2014 16:38:41 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=G5FPgDN7ZSPsF8CWKnO5G8 KRXFw=; b=P56Y0rfKMY+Gaa6HAq4QnyCTLDA745f9LNKbGdpsqiNMcbGt9fvUAN vBpHlzQOmPq1Sn7jK4Dz4xmWDywwEqkHkcYK6oEt+NVQa6bpih61WqUIh9n4WrhP nOJuRBuDO/4uHvRTRcRSwqfIlh6cqk+oRQ6Ah1GxNzLXqNcd9UjjA= X-Sasl-enc: drqOX1f2yvq2nplhmdV9EJbW2q9fmP3Ake/qjnTr/KI+ 1415050720 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id B6923C00012; Mon, 3 Nov 2014 16:38:40 -0500 (EST) Message-ID: <5457F5D5.2080308@network-heretics.com> Date: Mon, 03 Nov 2014 16:38:29 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54579BED.9000503@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/VUvtJpqIPrKIhnvIvGMWhIRgWNo Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 21:38:43 -0000 On 11/03/2014 04:14 PM, Sean Leonard wrote: > On Nov 3, 2014, at 7:14 AM, Keith Moore wrote: > >> On 11/03/2014 01:52 AM, Sean Leonard wrote: >>> All of this frustration with relative references and URNs illustrates a general point: >>> >>> Since relative references don’t make sense with URNs, URNs SHOULD NOT include slash / characters. >>> >>> That is why it looks like urn:ietf:rfc:3986 and not urn:/ietf/rfc/3986. >> Having hosted the Knoxville meeting where we first got some agreement on the syntax, I don't recall that being part of the discussion. But the intent was certainly that URNs wouldn't look like URLs, other than having a similar prefix and not using any of the characters not allowed for URLs. >> >> If using "/" in a URN makes people more likely to think that URNs make sense with relative URIs, then by a similar argument using "?" makes people more likely to think that queries can be applied to the resources named by URNs, and using "#" makes people more likely to assume that HTML-style fragments make sense with URNs. > On Nov 3, 2014, at 8:50 AM, Dale R. Worley wrote: > >> Or we can look at this as a design rule: If relative references have >> a defined meaning, use "/" to separate the relevant substrings. If >> relative references do not have a defined meaning, forbid "/". > > Since I wasn’t at the Knoxville meeting, perhaps a fresh pair of eyes (plus just someone new, relatively speaking, to the discussion) can bring a new perspective. Yes, it appears to be a design rule, or at least a design principle. I disagree. To me it looks like you're trying to retroactively impose design requirements on URNs that were never there in the first place, and where the need for them is dubious. URNs are not URLs; they have different syntaxes because they serve different purposes and therefore have different requirements. We would of course like to avoid confusion of various kinds between the two, and would like to minimize the potential for anomalous behavior when either users or implementations treat URNs as if they are URLs. But fundamentally, to the extent that users or implementors do that, those are errors on their part. It's not a design principle that URNs should have to act just like URNs; it's actually contrary to their design. > It would have made sense for the data: URL to use base64url encoding rather than basic base64 encoding, but the interactions between relative references and RFC 3986 weren’t fully appreciated at that time. That's irrelevant. The data: URL is not a URN. > In RFC 3986 parlance, a non-empty hierarchical path can be: > authority path-abempty > path-absolute > path-rootless URNs do not have paths. > Back to URNs: > A lot of URNs seem to divide the namespace with colons : . This seems reasonable. A better and more consistent approach to URN construction is inductive. Consider a name, and make it universally unique by prefixing the name with colon-separated namespace dividers. Again, URNs do not have paths or any other kind of hierarchy within a namespace. How any NID assigns URNs that start with its prefix is its own business. But trying to impose hierarchy within a URN namespace is harmful to URN persistence. The namespace specific portion of a URN should be considered opaque. Keith From nobody Tue Nov 4 05:16:06 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1B51A0105 for ; Tue, 4 Nov 2014 05:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8P_DiYqiXNa for ; Tue, 4 Nov 2014 05:16:00 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878691A010A for ; Tue, 4 Nov 2014 05:16:00 -0800 (PST) Received: from [128.214.71.147] (dh9-kkv47.lib.helsinki.fi [128.214.71.147]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id sA4DG3ZB015585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 4 Nov 2014 15:16:04 +0200 Message-ID: <5458D18C.5010800@helsinki.fi> Date: Tue, 04 Nov 2014 15:15:56 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: urn@ietf.org References: <5446A902.4030904@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC5F43C@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC5F43C@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/02P754G-wwu1KRSi7vjbfd3NY6o Subject: Re: [urn] next steps X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 13:16:04 -0000 Hello Lars, Some tentative answers below. On 3.11.2014 19:10, Svensson, Lars wrote: > Peter, all, > >> Having finally come around to read 2141bis-08, it certainly brings me towards a spec I can live with. There are some things I have issues with (particularly the relation between q-components and resolvers), but I'm not concerned enough about them that I'd try to stop it from becoming a specification. >> >> Comments (please read them in the light of the above): >> 1) §1 states that "a string that conforms to the URN syntax is not necessarily a valid URN [...]." Is there a way to find out if something just looks like a URN or if it actually is one? If so, I think we should add some text explaining that. URNs must conform both to the general requirements set by URI syntax and constraints specified in the namespace registration request (if any). Within URN:ISBN namespace only those URNs are valid in which NSS is conformant to either ISBN-10 or ISBN-13 (or some future version of the ISBN standard). If the namespace registration request specifies the NSS syntax in sufficient detail it is possible to determine if the URN is valid. But there are many namespaces including URN:NBN in which there is no way to determine whether the NSS is well formed or not. >> 2) My reading of §3 is that p-component is not part of the NSS. Is that correct? If so, the URN comparison becomes a bit counter-intuitive since the p-component is used to determine comparison and it would be easier to state that for comparison, only the schema, the NID and the NSS are relevant. Agreed. Alas, I have to admit that I don't understand the role of p-component in the URN syntax / URN comparison. I wonder if this uncertainty concerning the role of p element is just one aspect of a more general question: what path actually means in the URN context. I am tempted to say that it is allowed in theory in order to maintain conformance to RFC 3986, but any namespace which plans to allow its usage should consider that decision carefully. I am pretty sure that ISO identifiers shall not use it, but URN:NBN may be a different story. >> >> 5) §3.3 (this is my main concern): the third paragraph says "For example, it is possible that the q-component might be used in requests to URN resolution services." I still think that the components of a URN should apply to the identified resources and not be hijacked to pass information to other services (e. g. resolvers). Information related to resolution services should be part of 2483bis. Based on the practical experiences we know that resolution services required / available will change over time. I don't think that carving resolution services (and service parameters) in stone (standards track RFC) is a good idea, since we have to be able to add (at least in the context of ISO bibliographic identifiers and systems using them) new services & service parameters easily but in a controlled manner. Whether the components apply to the identified resource strictly or loosely is determined by the URI syntax. F-component, assuming that it bears resemblance to fragment, has to be closely linked to the identified resource which in this case has to be a single manifestation of a work. The relation between the identified resource and the result of the resolution process is less strict (but it still exists) if the q component is applied. I see no problem in applying the q component for e.g. retrieving descriptive / administrative / etc. metadata about the identified resource. Usage of q component for passing requests to resolution services is likely to happen even if URNBIS cannot agree on if and how the q component should be used. Information sciences community must make its URN resolvers more versatile, and q component seems to be the simplest means for this. Other persistent identifiers (ARK and Handle) are already using query for passing resolution requests. If IETF version of URN syntax does not provide the functionality my community urgently needs, then one option we must consider is to develop our own, enriched version of the URN syntax. Unlike URNBIS, we would approach this challenge mainly from practical point of view. Whether our version would be 100 % compliant with whatever it is that some people think URI syntax requires /allows would not be the topmost priority for us. And to be honest, we don't care too much if there is something wrong with RFC 3986, as long as the real / imaginary issues do not prevent URNBIS from achieving useful results. Best regards, Juha >> 6) In §4.2 is would be helpful to have some examples using p-, q- and f-components, too. >> 7) §5: What is a URI browser? A short search did not reveal any really useful information... >> >> So yes, from me there is rough consensus that we can move forward with this. >> >> Best, >> >> Lars >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Tue Nov 4 16:08:31 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77D71A6FE6 for ; Tue, 4 Nov 2014 16:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thZ-kzG64n-t for ; Tue, 4 Nov 2014 16:08:22 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0100.outbound.protection.outlook.com [207.46.100.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76AC01A1A4F for ; Tue, 4 Nov 2014 16:08:21 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) with Microsoft SMTP Server (TLS) id 15.1.11.14; Wed, 5 Nov 2014 00:08:20 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0011.000; Wed, 5 Nov 2014 00:08:20 +0000 From: Larry Masinter To: Sean Leonard , Keith Moore Thread-Topic: [urn] syntax and registration: a proposal Thread-Index: AQHP6YXxq/DFKj0YXEWFhMCYbmDkYZw01xy7gACcpICAABVUgIAAAVKAgAASNgCAABFxgIAA/ZMAgABpPICAAfh1AIAAB5kAgAGupjSAACZxAIAOQJOAgAA8OwCAAAEFgIAFKq+AgAKy0VA= Date: Wed, 5 Nov 2014 00:08:19 +0000 Message-ID: References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2601:9:8380:992:b18a:76c8:a9f8:f244] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0960; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(51704005)(189002)(106356001)(105586002)(2656002)(107046002)(76176999)(62966003)(46102003)(77156002)(99396003)(31966008)(106116001)(95666004)(92566001)(99286002)(122556002)(77096003)(87936001)(40100003)(76576001)(86362001)(4396001)(93886004)(54356999)(50986999)(108616004)(64706001)(20776003)(101416001)(33646002)(97736003)(74316001)(120916001)(21056001)(3826002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0960; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1qteWFH7r2wL3QSCJwc0S7kAIy8 Cc: "urn@ietf.org" Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 00:08:28 -0000 PiA+PiBUaGUgcmVsYXRpdmUgcmVzb2x1dGlvbiBhbGdvcml0aG0gYXBwbGllcyB0byBhbnkgYW5k IGFsbCBzY2hlbWVzDQo+IChpbmNsdWRpbmcgVVJOcykgd2hlcmUgaXQgaXMgYXBwbGllZC4NCj4g Pg0KPiA+IFNvcnJ5LCB0aGF0J3MganVzdCBpbnNhbmUuICBJdCBtYWtlcyBubyB0ZWNobmljYWwg c2Vuc2Ugd2hhdHNvZXZlci4NCg0KSXQgbWFkZSBnb29kIHRlY2huaWNhbCBzZW5zZSB0byBzdXBw b3J0IHNjaGVtZS1pbmRlcGVuZGVudCByZWxhdGl2ZSByZXNvbHV0aW9uLg0KUGVyaGFwcyB5b3Ug ZGlzYWdyZWUgd2l0aCBwcmlvcml0aXppbmcgc2ltcGxpY2l0eSBvdmVyIHBvd2VyLCBidXQgaXQn cyBoYXJkbHkgZ3JvdW5kcyBmb3IgY2FsbGluZyB0aGUgZGVzaWduICJpbnNhbmUiLg0KDQpMYXJy eQ0KIA0K From nobody Tue Nov 4 17:27:39 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7613E1A1AD4 for ; Tue, 4 Nov 2014 17:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmqWL9E41-7e for ; Tue, 4 Nov 2014 17:27:36 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264941A00B2 for ; Tue, 4 Nov 2014 17:27:36 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8F53020958 for ; Tue, 4 Nov 2014 20:27:35 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 04 Nov 2014 20:27:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=LdVBOaihpIEjAmhrKKScVE Hc4zg=; b=LRtqgraKUBdgFLHNxkqsFArHBS4gTU4X2jl8+4uOAjV5FnlLmUojB+ jrPQPSycwWAqWWMUnxGpwTJUDNO212afHCmQnOXYpdrGtQBorrDQhITQ1+B3spVx oQA3tHrrEs9KmpjYOrtwjoOZbbJMjSa4MQapqX6Vu71bW+Wi+fvcE= X-Sasl-enc: fs0tmuENkS9cg5X3MNuGdbnklxnRCDYY4KXKEv2r9LAC 1415150855 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 716EA6801AB; Tue, 4 Nov 2014 20:27:34 -0500 (EST) Message-ID: <54597CFA.8090304@network-heretics.com> Date: Tue, 04 Nov 2014 20:27:22 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Larry Masinter , Sean Leonard References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/_g6CoV6hY3E6aKHXG0Qk_QfblBE Cc: "urn@ietf.org" Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 01:27:37 -0000 On 11/04/2014 07:08 PM, Larry Masinter wrote: > It made good technical sense to support scheme-independent relative resolution. > Perhaps you disagree with prioritizing simplicity over power, but it's hardly grounds for calling the design "insane". I'm all for scheme independence. Heck, I'm the one arguing that interpretation of URN modifiers must be scheme-independent. But I've never seen how relative resolution of URNs (for any scheme) made any sense. Keith From nobody Tue Nov 4 17:32:01 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0714D1A1A31 for ; Tue, 4 Nov 2014 17:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsJU1zcgy1v4 for ; Tue, 4 Nov 2014 17:31:59 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115FC1A00E6 for ; Tue, 4 Nov 2014 17:31:59 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 611A720958 for ; Tue, 4 Nov 2014 20:31:58 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 04 Nov 2014 20:31:58 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=vy4/iyVSwdfkAPdmiBctiK /+f9k=; b=hgk3fL5aFRWPTyr39u0IXbOKVe1P8foDUAYyp+ul/Z9mcnffEgmgFQ G7Csk9AEowl6yF1Nf1orevL1GvN4efofWxQzDAABnp8yMocJoMaxppGGtixxgI5Y SjIoE/1etM4wVbdOx/0qPPPpi72HIgH5E07bYeElvkhTcDfl6RYac= X-Sasl-enc: N2yHHUmTPMy9w3gooIw1uXU9539irYmsI0CtogqiZQod 1415151118 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 97D9AC0000A; Tue, 4 Nov 2014 20:31:57 -0500 (EST) Message-ID: <54597E02.8080603@network-heretics.com> Date: Tue, 04 Nov 2014 20:31:46 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Larry Masinter , Sean Leonard References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54597CFA.8090304@network-heretics.com> In-Reply-To: <54597CFA.8090304@network-heretics.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/O5wjerEMN8Dyp3GCvRzHI-rcZEI Cc: "urn@ietf.org" Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 01:32:00 -0000 On 11/04/2014 08:27 PM, Keith Moore wrote: >> It made good technical sense to support scheme-independent relative >> resolution. >> Perhaps you disagree with prioritizing simplicity over power, but >> it's hardly grounds for calling the design "insane". > I'm all for scheme independence. Heck, I'm the one arguing that > interpretation of URN modifiers must be scheme-independent. > > But I've never seen how relative resolution of URNs (for any scheme) > made any sense. Ah, now that I've written the above, I see I should have said "namespace" rather than scheme. URNs are fundamentally different creatures than (most) URLs. Because we'd like to be able to use both kinds of names in many of the same contexts, it's handy if the two can be handled in a similar fashion. And I've argued in the past that "#" and "?" for URNs should be handled exactly like they are for the most common URLs - by being interpreted in the context of the resources themselves. But it really does seem that trying to shoehorn URNs into URL syntax and conventions for interpretation in every case just ends up being too much of a constraint, and the desire to make one syntax do too many different things threatens to make URN interpretation namespace-dependent, which is even worse than scheme-dependence. Keith From nobody Wed Nov 5 05:43:04 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247BB1A88F5 for ; Wed, 5 Nov 2014 05:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-hH2jFVD1kJ for ; Wed, 5 Nov 2014 05:42:59 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F831A1A5F for ; Wed, 5 Nov 2014 05:42:59 -0800 (PST) Received: from [192.168.123.151] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4D575509B6 for ; Wed, 5 Nov 2014 08:42:57 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <54597E02.8080603@network-heretics.com> Date: Wed, 5 Nov 2014 05:42:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <397DB12C-C4B1-4387-8CBC-2C07E2D788EC@seantek.com> References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54597CFA.8090304@network-heretics.com> <54597E02.8080603@network-heretics.com> To: "urn@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1xNZg-0JzRe-BGRROEQ6eyarXKc Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 13:43:02 -0000 On Nov 4, 2014, at 5:31 PM, Keith Moore = wrote: > On 11/04/2014 08:27 PM, Keith Moore wrote: >>> It made good technical sense to support scheme-independent relative = resolution. >>> Perhaps you disagree with prioritizing simplicity over power, but = it's hardly grounds for calling the design "insane". >> I'm all for scheme independence. Heck, I'm the one arguing that = interpretation of URN modifiers must be scheme-independent. >>=20 >> But I've never seen how relative resolution of URNs (for any scheme) = made any sense. >=20 > Ah, now that I've written the above, I see I should have said = "namespace" rather than scheme. >=20 > URNs are fundamentally different creatures than (most) URLs. Because = we'd like to be able to use both kinds of names in many of the same = contexts, it's handy if the two can be handled in a similar fashion. = And I've argued in the past that "#" and "?" for URNs should be handled = exactly like they are for the most common URLs - by being interpreted in = the context of the resources themselves. >=20 > But it really does seem that trying to shoehorn URNs into URL syntax = and conventions for interpretation in every case just ends up being too = much of a constraint, I agree with these literal statements. However, I want to point out that these statements are comparing URNs = and *URLs*. A URL (to the extent that still exists=97I think it does = exist) is a locator for a network-accessible resource. URNs are not = locators, since they do not contain network address information, as = network address information is not durable, persistent, unique, or = registrable. There are URIs that are not URLs. Behaviorally, these URIs illustrate = similar behaviors and features to URNs. Examples: news:example.group.this cid:foo4%25foo1@bar.net tel:+1-201-555-0123 mailto:jsmith@example.com?subject=3DA%20Test Some of these URIs (e.g., mailto) embed network resource identifiers = (e.g., domain names), but they aren=92t network addresses=97they are = basically launch commands to do local things. As I see it, the main difference between these types of URIs and URNs is = that URN namespaces undertake specific obligations for durability, = persistence, uniqueness, and registrability. Thus, urn:cid:foo4%25foo1@bar.net is inappropriate because it may not be = unique; no standard requires that the Content-ID be universally unique = (and if the domain name is reassigned, there is no guarantee that the = old and new registrants will coordinate this). URNs are not URLs. But they are still identifiers=97they just have = specific properties. Saying that URNs are not URIs overstates the case. Sean PS Relative resolution for the URIs above (news, cid, tel, mailto) also = does not make sense. I agree with Larry that scheme-independent relative = resolution still has technical value. It is useful for a broad range of = URIs, just not for all of them. Maybe it would be a good idea for new = URI scheme registrations to state whether relative resolution has = practical value. (The *mechanism* for relative resolution remains = scheme-independent=97an URI scheme shouldn=92t invent a new kind of = reference parsing algorithm, such as one that runs on . or : instead of = / .)= From nobody Wed Nov 5 05:57:35 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FAF1A010A for ; Wed, 5 Nov 2014 05:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMSQGxfNTCoZ for ; Wed, 5 Nov 2014 05:57:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D07B1A8916 for ; Wed, 5 Nov 2014 05:57:27 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MS1g6-1XaUky3XSs-00TDIa; Wed, 05 Nov 2014 14:57:23 +0100 Message-ID: <545A2CC1.60802@gmx.de> Date: Wed, 05 Nov 2014 14:57:21 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Leonard , "urn@ietf.org" References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54597CFA.8090304@network-heretics.com> <54597E02.8080603@network-heretics.com> <397DB12C-C4B1-4387-8CBC-2C07E2D788EC@seantek.com> In-Reply-To: <397DB12C-C4B1-4387-8CBC-2C07E2D788EC@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:7Z70ennP2RjfjxSoz4Mse8whWoe3Pc/0tEz2SpAtriWWGaurhSR WCvxq2SF6YzsOtEDZI+0CiARr0M7sztUsIk/zyurWMLsYbr5JuIs6XkeFULjy87EClwSQPq SqVxaodeJ2zeEotAax/5+Nb9KHWbdgIU2QqpXbn33rUK0kTzKlNIHhZvqVnRYU/tLweC70H LDi9WOjayLg+LDHO2eYog== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/TqAL8ioFeLvm4gamr7MY247mNJw Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 13:57:34 -0000 On 2014-11-05 14:42, Sean Leonard wrote: > > On Nov 4, 2014, at 5:31 PM, Keith Moore wrote: > >> On 11/04/2014 08:27 PM, Keith Moore wrote: >>>> It made good technical sense to support scheme-independent relative resolution. >>>> Perhaps you disagree with prioritizing simplicity over power, but it's hardly grounds for calling the design "insane". >>> I'm all for scheme independence. Heck, I'm the one arguing that interpretation of URN modifiers must be scheme-independent. >>> >>> But I've never seen how relative resolution of URNs (for any scheme) made any sense. >> >> Ah, now that I've written the above, I see I should have said "namespace" rather than scheme. >> >> URNs are fundamentally different creatures than (most) URLs. Because we'd like to be able to use both kinds of names in many of the same contexts, it's handy if the two can be handled in a similar fashion. And I've argued in the past that "#" and "?" for URNs should be handled exactly like they are for the most common URLs - by being interpreted in the context of the resources themselves. >> >> But it really does seem that trying to shoehorn URNs into URL syntax and conventions for interpretation in every case just ends up being too much of a constraint, > > I agree with these literal statements. (I don't) > However, I want to point out that these statements are comparing URNs and *URLs*. A URL (to the extent that still exists—I think it does exist) is a locator for a network-accessible resource. URNs are not locators, since they do not contain network address information, as network address information is not durable, persistent, unique, or registrable. "network address information is not durable, persistent, unique, or registrable" Hmm, no. It's just a different kind of registry with properties different from the URN registration process. > There are URIs that are not URLs. Behaviorally, these URIs illustrate similar behaviors and features to URNs. Examples: > > news:example.group.this > cid:foo4%25foo1@bar.net > tel:+1-201-555-0123 > mailto:jsmith@example.com?subject=A%20Test > > Some of these URIs (e.g., mailto) embed network resource identifiers (e.g., domain names), but they aren’t network addresses—they are basically launch commands to do local things. > > As I see it, the main difference between these types of URIs and URNs is that URN namespaces undertake specific obligations for durability, persistence, uniqueness, and registrability. > > Thus, urn:cid:foo4%25foo1@bar.net is inappropriate because it may not be unique; no standard requires that the Content-ID be universally unique (and if the domain name is reassigned, there is no guarantee that the old and new registrants will coordinate this). > > URNs are not URLs. But they are still identifiers—they just have specific properties. Saying that URNs are not URIs overstates the case. +1 on that. Furthermore, I keep hearing of people who want to make URNs network-resolvable, in which case they become URLs as well, no? > Sean > > PS Relative resolution for the URIs above (news, cid, tel, mailto) also does not make sense. I agree with Larry that scheme-independent relative resolution still has technical value. It is useful for a broad range of URIs, just not for all of them. Maybe it would be a good idea for new URI scheme registrations to state whether relative resolution has practical value. (The *mechanism* for relative resolution remains scheme-independent—an URI scheme shouldn’t invent a new kind of reference parsing algorithm, such as one that runs on . or : instead of / .) +1 on that too. Optimally, the URI registration process document would point out that relative resolution is going to yield surprising results if you don't stick to the hierarchical model (and that registrants should make a conscious decision about that when defining a new scheme). And, surprise (); > New schemes SHOULD reuse the common URI components of [RFC3986] for > the definition of hierarchical naming schemes. If there is a strong > reason for a scheme not to use the hierarchical syntax, then the new > scheme definition SHOULD follow the syntax of previously registered > schemes. > > Schemes that are not intended for use with relative URIs SHOULD avoid > use of the forward slash "/" character, which is used for > hierarchical delimiters, and the complete path segments "." and ".." > (dot-segments). Best regards, Julian From nobody Wed Nov 5 06:16:17 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC331A8919 for ; Wed, 5 Nov 2014 06:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAkeGmW5nbfe for ; Wed, 5 Nov 2014 06:16:13 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E601A1B57 for ; Wed, 5 Nov 2014 06:16:13 -0800 (PST) Received: from [192.168.123.151] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8CB8B50AA2; Wed, 5 Nov 2014 09:16:11 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <5457F5D5.2080308@network-heretics.com> Date: Wed, 5 Nov 2014 06:16:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54579BED.9000503@network-heretics.com> <5457F5D5.2080308@network-heretics.com> To: Keith Moore , urn@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/COsaAza8eX3Ag7gwBBrlGblV-hc Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:16:15 -0000 Keith, I think we are on the same page here=97we are just using = differing terminology. On Nov 3, 2014, at 1:38 PM, Keith Moore = wrote: > On 11/03/2014 04:14 PM, Sean Leonard wrote: >>=20 >>> Or we can look at this as a design rule: If relative references = have >>> a defined meaning, use "/" to separate the relevant substrings. If >>> relative references do not have a defined meaning, forbid "/". >>=20 >> Since I wasn=92t at the Knoxville meeting, perhaps a fresh pair of = eyes (plus just someone new, relatively speaking, to the discussion) can = bring a new perspective. Yes, it appears to be a design rule, or at = least a design principle. >=20 > I disagree. To me it looks like you're trying to retroactively impose = design requirements on URNs that were never there in the first place, = and where the need for them is dubious. URNs are not URLs; they have = different syntaxes because they serve different purposes and therefore = have different requirements. We would of course like to avoid = confusion of various kinds between the two, and would like to minimize = the potential for anomalous behavior when either users or = implementations treat URNs as if they are URLs. But fundamentally, to = the extent that users or implementors do that, those are errors on their = part. It's not a design principle that URNs should have to act just = like URNs; it's actually contrary to their design. Ok=97did you mean something else though by =93It=92s not a design = principle that URNs should have to act just like URNs=94? URNs are = URNs=85are you contrasting URNs with URLs? >=20 >> In RFC 3986 parlance, a non-empty hierarchical path can be: >> authority path-abempty >> path-absolute >> path-rootless >=20 > URNs do not have paths. I *think* we are in agreement. URNs do not have paths. But according to RFC 3986, the =93NID:NSS=94 part is part of the = path-rootless production, for urn: URIs. Thus when analyzed with the RFC = 3986 URI generic syntax, NID:NSS are what some folks are now calling the = =93p-component=94. I was just pointing out some mechanics. >=20 >> Back to URNs: >> A lot of URNs seem to divide the namespace with colons : . This seems = reasonable. A better and more consistent approach to URN construction is = inductive. Consider a name, and make it universally unique by prefixing = the name with colon-separated namespace dividers. > Again, URNs do not have paths or any other kind of hierarchy within a = namespace. How any NID assigns URNs that start with its prefix is its = own business. =20 > But trying to impose hierarchy within a URN namespace is harmful to = URN persistence. I was very careful in choosing the terms =93prefix=94 and =93namespace = dividers=94, rather than hierarchy. I was not proposing hierarchy in the = RFC 3986 sense of a =93hier-part=94. The purpose was to point out that punctuation serves to *divide* the = namespace. The punctuation need not be a colon : ; it can be a period . = or an at symbol @ . For example: urn:oid:2.5.4.3 (which is for commonName) is materially different from: urn:oid:2.54.3 urn:oid:2.543 Punctuation matters. Punctuation serves to divide the namespace. Semantically, a colon could have been used instead: urn:oid:2:5:4:3 To Keith's point, the choice of punctuation is the namespace=92s = business. =46rom a generic URN (or URI) parser=92s perspective, fine, = maybe they are opaque. But the punctuation serves a common purpose to divide the arbitrary = sequence of characters into discrete parts. A URN parser that is going = to interpret OIDs for OID purposes needs to know how to divide the = =93opaque=94 string into numeric sequences, using =93.=94 (not =93:=94) = as the divider. Compare this with urn:isbn. ISBNs can be 10 or 13 digits. RFC 3187 = suggests that urn:isbn use - to separate certain number groups, such as: urn:isbn:0-395-36341-1 But unlike . in OIDs, - in ISBNs do not affect lexical equivalence. (See = Section 3.2 of RFC 3187.) Thus: urn:isbn:0395363411 is lexically equivalent. Furthermore, urn:isbn resolution may depend on digit sequences that are = not neatly divided by - characters. This is straight from RFC 3187: For instance, "951-0" is the unique ISBN publisher identifier of the largest publisher in Finland, Sanoma-WSOY. If they launch their own URN resolution services, resolution requests for ISBNs starting with "951-0" will be directed to the publisher's server, and all other requests to the national bibliography. =20 Anyway, since URN namespaces always include at least one colon, it is = not surprising that the colon is used when the local identifier (name) = does not have a preference for particular punctuation characters. For example: urn:ietf:rfc:3986 urn:iet:frfc:3986 urn:ietf:rfc3:986 are not the same. -Sean From nobody Wed Nov 5 06:29:19 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF7B1A1B46 for ; Wed, 5 Nov 2014 06:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g11njMjXm3XM for ; Wed, 5 Nov 2014 06:29:17 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065531A8923 for ; Wed, 5 Nov 2014 06:29:17 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4AD28203B6 for ; Wed, 5 Nov 2014 09:29:16 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 05 Nov 2014 09:29:16 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=6vzE0bhic9A1MdeF1I+UTw twdxQ=; b=jm8cfajpW2r086Av/Hp2BFmprwh9Gb5pv8xpdI18gQyr5v290E9eW1 ai/i3+aXIz+NmHdRfh3+zB3xtVYJFAW3reKAbgTg7tcl+a1pRZsVRsaXkOCyvaHT zSB5PdxXY5k9ufUm79+BnH1OtsPn/KAyZIg+CIH5Zu/V+h+nuctA0= X-Sasl-enc: iMAFqV/McVpZ9isjOV2X9KSW+m3Eve3DVeXQBbnxw0sw 1415197756 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id DBF136800AE; Wed, 5 Nov 2014 09:29:15 -0500 (EST) Message-ID: <545A3430.7040705@network-heretics.com> Date: Wed, 05 Nov 2014 09:29:04 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Leonard , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54579BED.9000503@network-heretics.com> <5457F5D5.2080308@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/nVScIyU1eWQMbyI6iceGU3euZ1g Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:29:18 -0000 On 11/05/2014 09:16 AM, Sean Leonard wrote: > Ok—did you mean something else though by “It’s not a design principle > that URNs should have to act just like URNs”? URNs are URNs…are you > contrasting URNs with URLs? I meant "It's not a design principle that URNs should have to act just like URLs". > >> >> URNs do not have paths. > I *think* we are in agreement. > > URNs do not have paths. > > But according to RFC 3986, the “NID:NSS” part is part of the path-rootless production, for urn: URIs. Thus when analyzed with the RFC 3986 URI generic syntax, NID:NSS are what some folks are now calling the “p-component”. I was just pointing out some mechanics. The chair has forbidden me to speak the truth about that RFC. However, I refuse to participate in telling lies about it. So IMO it's better to not mention it at all in connection with URNs. > >> >> Again, URNs do not have paths or any other kind of hierarchy within a namespace. How any NID assigns URNs that start with its prefix is its own business. >> But trying to impose hierarchy within a URN namespace is harmful to URN persistence. > I was very careful in choosing the terms “prefix” and “namespace dividers”, rather than hierarchy. I was not proposing hierarchy in the RFC 3986 sense of a “hier-part”. > > The purpose was to point out that punctuation serves to *divide* the namespace. The punctuation need not be a colon : ; it can be a period . or an at symbol @ . > > For example: > urn:oid:2.5.4.3 > (which is for commonName) > > is materially different from: > urn:oid:2.54.3 > urn:oid:2.543 > > Punctuation matters. Punctuation serves to divide the namespace. Punctuation within the namespace specific string has no special meaning and should be treated just as if it were any other character, unless the thing doing the processing happens to know the specific rules for assigning names within that namespace. But the whole point of URNs is to permit uniform handling of different kinds of URNs. So things that process URNs in general shouldn't be trying to infer meaning from portions of the namespace specific string. Keith From nobody Wed Nov 5 06:37:41 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5301A1B4E for ; Wed, 5 Nov 2014 06:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jZIs8K7eoY0 for ; Wed, 5 Nov 2014 06:37:38 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6CE1A1B35 for ; Wed, 5 Nov 2014 06:37:38 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8C1B62057E for ; Wed, 5 Nov 2014 09:37:37 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 05 Nov 2014 09:37:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=t7tGvj7cMyXbXcmz/3iqZV 2Xc+4=; b=MD2qjiODLYxTRQV26RmSrb9xM4e/nfZtFsUrM0datnWNhmlDD9joOC 6O8JE6uEA3bWH+QWh0JGm8V4kv/cyQXTkCACOb4sJIWyw7aLubjpt+vRLa85LBa4 /qyM28Tn/XvCK7Sx/XLQ2g15TKdj174/v1GseQzcs8LO8AFmju9uw= X-Sasl-enc: P5WkjkMY2cMXlWqcclSy6tJyvLQOZerVDRrrctNxsgr6 1415198257 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 354B568019B; Wed, 5 Nov 2014 09:37:37 -0500 (EST) Message-ID: <545A3626.5070705@network-heretics.com> Date: Wed, 05 Nov 2014 09:37:26 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54597CFA.8090304@network-heretics.com> <54597E02.8080603@network-heretics.com> <397DB12C-C4B1-4387-8CBC-2C07E2D788EC@seantek.com> <545A2CC1.60802@gmx.de> In-Reply-To: <545A2CC1.60802@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Zz2Iw74Itj9bhg5l40Hk4m5epaY Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:37:40 -0000 On 11/05/2014 08:57 AM, Julian Reschke wrote: > > "network address information is not durable, persistent, unique, or > registrable" > > Hmm, no. It's just a different kind of registry with properties > different from the URN registration process. Network address information is not durable, persistent, or unique. IP address blocks can be reassigned and will necessarily change over time; DNS registrations can be taken away or reassigned without consent of the party that assigned names based on them. > Furthermore, I keep hearing of people who want to make URNs > network-resolvable, in which case they become URLs as well, no? No, because names are not inherently locators. That, and URN resolution doesn't depend on namespaces like DNS names or IP addresses that have inherently ephemeral associations with reality, and care has been taken to make sure that URN namespaces will only be delegated to parties that value persistence and will assign and maintain namespace-specific identifiers with due care. > >> Sean >> >> PS Relative resolution for the URIs above (news, cid, tel, mailto) >> also does not make sense. I agree with Larry that scheme-independent >> relative resolution still has technical value. It is useful for a >> broad range of URIs, just not for all of them. Maybe it would be a >> good idea for new URI scheme registrations to state whether relative >> resolution has practical value. (The *mechanism* for relative >> resolution remains scheme-independent—an URI scheme shouldn’t invent >> a new kind of reference parsing algorithm, such as one that runs on . >> or : instead of / .) > > +1 on that too. Except that insisting that URNs behave exactly like every other URI, while it might seem good in isolation, ends up forcing different behavior for use of modifiers among different URN namespaces. The problem is that the rules for URIs were really designed for hierarchical URLs and are too constraining. > > Optimally, the URI registration process document would point out that > relative resolution is going to yield surprising results if you don't > stick to the hierarchical model (and that registrants should make a > conscious decision about that when defining a new scheme). > > And, surprise > (); > >> New schemes SHOULD reuse the common URI components of [RFC3986] for >> the definition of hierarchical naming schemes. If there is a strong >> reason for a scheme not to use the hierarchical syntax, then the new >> scheme definition SHOULD follow the syntax of previously registered >> schemes. >> >> Schemes that are not intended for use with relative URIs SHOULD avoid >> use of the forward slash "/" character, which is used for >> hierarchical delimiters, and the complete path segments "." and ".." >> (dot-segments). urn: is not a new URI scheme. Keith From nobody Wed Nov 5 06:53:03 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937C11A86F3 for ; Wed, 5 Nov 2014 06:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pFGibr2p7JX for ; Wed, 5 Nov 2014 06:52:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DE91A6FCD for ; Wed, 5 Nov 2014 06:52:59 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MJSuF-1XjY2s3n1X-0033Bx; Wed, 05 Nov 2014 15:52:58 +0100 Message-ID: <545A39C6.5070302@gmx.de> Date: Wed, 05 Nov 2014 15:52:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54597CFA.8090304@network-heretics.com> <54597E02.8080603@network-heretics.com> <397DB12C-C4B1-4387-8CBC-2C07E2D788EC@seantek.com> <545A2CC1.60802@gmx.de> <545A3626.5070705@network-heretics.com> In-Reply-To: <545A3626.5070705@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:nU5TvV1fkEL2W9sYN3doi1HZBSQMAQ8EzLMqJZ8B/+mb16phxOj pVBQYuS/Tt0flmrTSjxQoaNBxP8cf24c9ClvR9tnL4emH8isumkhuB/IvoyIF36ZrcqPwyt 7/z+pzYNO68bg4U6Le8tAPshpa9FWcRYKgCDb4dTJrOFTCnFw9zhCg6zU82WktJ7h4DK30o h0DzXf5Lkf3w92aujL9ww== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UaIQkINS9g-VVDe6pqvD29-Hfuk Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:53:01 -0000 On 2014-11-05 15:37, Keith Moore wrote: > On 11/05/2014 08:57 AM, Julian Reschke wrote: >> >> "network address information is not durable, persistent, unique, or >> registrable" >> >> Hmm, no. It's just a different kind of registry with properties >> different from the URN registration process. > > Network address information is not durable, persistent, or unique. IP > address blocks can be reassigned and will necessarily change over time; > DNS registrations can be taken away or reassigned without consent of the > party that assigned names based on them. The authority part of a URI doesn't even need to use IP adresses or DNS. > ... >> Optimally, the URI registration process document would point out that >> relative resolution is going to yield surprising results if you don't >> stick to the hierarchical model (and that registrants should make a >> conscious decision about that when defining a new scheme). >> >> And, surprise >> (); >> >> >>> New schemes SHOULD reuse the common URI components of [RFC3986] for >>> the definition of hierarchical naming schemes. If there is a strong >>> reason for a scheme not to use the hierarchical syntax, then the new >>> scheme definition SHOULD follow the syntax of previously registered >>> schemes. >>> >>> Schemes that are not intended for use with relative URIs SHOULD avoid >>> use of the forward slash "/" character, which is used for >>> hierarchical delimiters, and the complete path segments "." and ".." >>> (dot-segments). > > urn: is not a new URI scheme. > ... I didn't claim it was. I was just citing the draft because it has good advice here, and maybe it should affect what *this* WG defines for new NIDs. Best regards, Julian From nobody Wed Nov 5 07:59:32 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EAA1A89AE for ; Wed, 5 Nov 2014 07:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEEhyU4qG1ox for ; Wed, 5 Nov 2014 07:59:29 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1471A899A for ; Wed, 5 Nov 2014 07:59:29 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2F22820672 for ; Wed, 5 Nov 2014 10:59:29 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 05 Nov 2014 10:59:29 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=YNkwEGrd+HTFxmTChROZ3H 4Ewp4=; b=VV4Chp0EJewoEWjEeU/GGYk76Z81wbeNfy87b51puT7vYP3A+Tbl9w D2Gp29qgvktKF+7QLn5UXrNaBJyAmJd7BN4vR1SCkSDHTtVGR9Ve7DMXuB+Gqxda HwZc4/A4VdrWyp8LvsXb4hChfxseuWJ5DujgH92XhkA2RLIgmbQ+c= X-Sasl-enc: F5FEv3ykshygv61OxRspywxzZKrGgQvAuTT3GsoXA2wE 1415203168 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id B71F6680101; Wed, 5 Nov 2014 10:59:28 -0500 (EST) Message-ID: <545A4955.6030000@network-heretics.com> Date: Wed, 05 Nov 2014 10:59:17 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Julian Reschke , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54597CFA.8090304@network-heretics.com> <54597E02.8080603@network-heretics.com> <397DB12C-C4B1-4387-8CBC-2C07E2D788EC@seantek.com> <545A2CC1.60802@gmx.de> <545A3626.5070705@network-heretics.com> <545A39C6.5070302@gmx.de> In-Reply-To: <545A39C6.5070302@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/JOtPZiXT3NyxpAZNKKB8ZRnNQCk Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:59:32 -0000 On 11/05/2014 09:52 AM, Julian Reschke wrote: > On 2014-11-05 15:37, Keith Moore wrote: >> On 11/05/2014 08:57 AM, Julian Reschke wrote: >>> >>> "network address information is not durable, persistent, unique, or >>> registrable" >>> >>> Hmm, no. It's just a different kind of registry with properties >>> different from the URN registration process. >> >> Network address information is not durable, persistent, or unique. IP >> address blocks can be reassigned and will necessarily change over time; >> DNS registrations can be taken away or reassigned without consent of the >> party that assigned names based on them. > > The authority part of a URI doesn't even need to use IP adresses or DNS. True enough. I never said that people can't create other URIs that have similar properties to URNs. > >> ... >>> Optimally, the URI registration process document would point out that >>> relative resolution is going to yield surprising results if you don't >>> stick to the hierarchical model (and that registrants should make a >>> conscious decision about that when defining a new scheme). >>> >>> And, surprise >>> (); >>> >>> >>> >>>> New schemes SHOULD reuse the common URI components of [RFC3986] for >>>> the definition of hierarchical naming schemes. If there is a >>>> strong >>>> reason for a scheme not to use the hierarchical syntax, then the >>>> new >>>> scheme definition SHOULD follow the syntax of previously registered >>>> schemes. >>>> >>>> Schemes that are not intended for use with relative URIs SHOULD >>>> avoid >>>> use of the forward slash "/" character, which is used for >>>> hierarchical delimiters, and the complete path segments "." and >>>> ".." >>>> (dot-segments). >> >> urn: is not a new URI scheme. >> ... > > I didn't claim it was. I was just citing the draft because it has good > advice here, and maybe it should affect what *this* WG defines for new > NIDs. > NIDs aren't URI schemes. Keith From nobody Wed Nov 5 08:09:46 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CE01A89A6 for ; Wed, 5 Nov 2014 08:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LlIfq66OuJN for ; Wed, 5 Nov 2014 08:09:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D832A1A8978 for ; Wed, 5 Nov 2014 08:09:40 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LjrDd-1YJRxh1Gkj-00bvkv; Wed, 05 Nov 2014 17:09:36 +0100 Message-ID: <545A4BBA.8070709@gmx.de> Date: Wed, 05 Nov 2014 17:09:30 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54597CFA.8090304@network-heretics.com> <54597E02.8080603@network-heretics.com> <397DB12C-C4B1-4387-8CBC-2C07E2D788EC@seantek.com> <545A2CC1.60802@gmx.de> <545A3626.5070705@network-heretics.com> <545A39C6.5070302@gmx.de> <545A4955.6030000@network-heretics.com> In-Reply-To: <545A4955.6030000@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:nGyFS30wtxDJw9dXGj34vRHfn9oe+6JQsG87MdY/TZZy7O+Rqhn lrDa6/6SfWAq/s54JQl/c7FxHqwJKw+1p4Ut58yWHiYSDqBwczEsPqFYLPiqaLR/yDH3L3J r+AIMuMCHDFg37rd/PurMzG83Skw00fzIBOeTg+wby9BPcVJvJX1R2bz2M/VxtLW1QcsjQ3 6pkkZLts4K4wO7eMYVdJA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/VfH1tlP36pzsqRLV_gmCpMj6Eok Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 16:09:43 -0000 On 2014-11-05 16:59, Keith Moore wrote: > ... >> I didn't claim it was. I was just citing the draft because it has good >> advice here, and maybe it should affect what *this* WG defines for new >> NIDs. >> > NIDs aren't URI schemes. > ... I known that, and you know that I do. May point being: if there was consensus that the advice in the URI scheme registration draft is good then it would make a lot of sense to think about whether we can draw some conclusions for registrations of new NIDs. Best regards, Julian From nobody Wed Nov 5 08:18:16 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4355A1A8966 for ; Wed, 5 Nov 2014 08:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryoycd1mhOYf for ; Wed, 5 Nov 2014 08:18:03 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE391A8974 for ; Wed, 5 Nov 2014 08:18:01 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 03064203D8 for ; Wed, 5 Nov 2014 11:18:00 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 05 Nov 2014 11:18:01 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=R/hE47jZGjRtoYlLBU9Otb YTsig=; b=ovGeRtdiHIJKwWmoyq14NZ4HiHFeCP+ikwEmZqQetfI0hSPQveXciK m/vdj9c3qrtsQ31vuflNOLtIzvOUrzKrQ8fvClMNKaIxacE6yKKv22NrWmHx9ak0 xJCAdNRV10T+5iy6ccT2rhf/Vhyq3BG4RiwX5SM90euT5SnhXNXX8= X-Sasl-enc: NsKQuUjMPZIbEGu6Vk4igsbV5icUVSCAWqbNxq+LRy9w 1415204280 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 9D080C00006; Wed, 5 Nov 2014 11:18:00 -0500 (EST) Message-ID: <545A4DAD.7030802@network-heretics.com> Date: Wed, 05 Nov 2014 11:17:49 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54597CFA.8090304@network-heretics.com> <54597E02.8080603@network-heretics.com> <397DB12C-C4B1-4387-8CBC-2C07E2D788EC@seantek.com> <545A2CC1.60802@gmx.de> <545A3626.5070705@network-heretics.com> <545A39C6.5070302@gmx.de> <545A4955.6030000@network-heretics.com> <545A4BBA.8070709@gmx.de> In-Reply-To: <545A4BBA.8070709@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/3aDjmuaGz_XXCGYAoKbSLHm2L2E Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 16:18:07 -0000 On 11/05/2014 11:09 AM, Julian Reschke wrote: > I known that, and you know that I do. > > May point being: if there was consensus that the advice in the URI > scheme registration draft is good then it would make a lot of sense to > think about whether we can draw some conclusions for registrations of > new NIDs. Disagree, because they were considering a completely different case. Keith From nobody Wed Nov 5 08:22:00 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFB11A8974 for ; Wed, 5 Nov 2014 08:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkJSAJoZ79we for ; Wed, 5 Nov 2014 08:21:57 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B7A1A895D for ; Wed, 5 Nov 2014 08:21:57 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M6zvN-1Y0i3C13Bd-00wmJJ; Wed, 05 Nov 2014 17:21:55 +0100 Message-ID: <545A4E9D.7000203@gmx.de> Date: Wed, 05 Nov 2014 17:21:49 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <54403493.5080808@andyet.net> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54597CFA.8090304@network-heretics.com> <54597E02.8080603@network-heretics.com> <397DB12C-C4B1-4387-8CBC-2C07E2D788EC@seantek.com> <545A2CC1.60802@gmx.de> <545A3626.5070705@network-heretics.com> <545A39C6.5070302@gmx.de> <545A4955.6030000@network-heretics.com> <545A4BBA.8070709@gmx.de> <545A4DAD.7030802@network-heretics.com> In-Reply-To: <545A4DAD.7030802@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Qr47Sl027P8p9hzg6RmMdjjr00zuF+hcYUXugf79e1bF0Eglf37 c+yIM5ki5VuPpyYixpVGq6g+390a9PYxp+3KlNAZuLeMk0P+BXqXh3HX1pqtgQwHdjPttjR HS52IZRMjvZ31iNhFQ5ojnkwixxLBEPJG8mQKh3673PoCq4+iMWi5yZ/JYUClTGC4ftDMLG u7QMnYqzRv971RqvfIOfg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/GXagejNgeMynJ6pMPLzUN3N1V-E Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 16:21:59 -0000 On 2014-11-05 17:17, Keith Moore wrote: > On 11/05/2014 11:09 AM, Julian Reschke wrote: >> I known that, and you know that I do. >> >> May point being: if there was consensus that the advice in the URI >> scheme registration draft is good then it would make a lot of sense to >> think about whether we can draw some conclusions for registrations of >> new NIDs. > > Disagree, because they were considering a completely different case. > > Keith > ... I understand the use case as defining identifiers that will work in a predictable way when used as base URI for relative reference resolution. Do you disagree that this is the use case? Best regards, Julian From nobody Wed Nov 5 08:24:10 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1051B1A8974 for ; Wed, 5 Nov 2014 08:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NW66sN3Ix9JX for ; Wed, 5 Nov 2014 08:24:07 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5931A037F for ; Wed, 5 Nov 2014 08:24:07 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8FC7A203B6 for ; Wed, 5 Nov 2014 11:24:06 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 05 Nov 2014 11:24:06 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=uLTz3AC0QhrMbjgH5ffjHF riUfU=; b=plbmrKWNr9JPvrf6tNpAFHVA7/W74GTucSTS5D/UKZqOArqZhEIUds JHNf2j9S3f+hICW8HIKsteze3c7beueXtGb3Dh3hVnMo0zZ1nPJdyzOBm+tTkLOt nNU1BClBl4uCloTdWgbzSJSgRvuo+qGWGzNhFNDGSI9gQe2CeuKMg= X-Sasl-enc: zBGmS0MCg0o1ekcuE1FiOB1BK/ry6e1788ak0lUFyGB7 1415204646 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 39432C00006; Wed, 5 Nov 2014 11:24:06 -0500 (EST) Message-ID: <545A4F1B.9080409@network-heretics.com> Date: Wed, 05 Nov 2014 11:23:55 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@n etwork-heretics.com> <5452CFDA.9000203@it.aoyama.ac.jp> <5452D0B5.8060008@network-heretics.com> <54597CFA.8090304@network-heretics.com> <54597E02.8080603@network-heretics.com> <397DB12C-C4B1-4387-8CBC-2C07E2D788EC@seantek.com> <545A2CC1.60802@gmx.de> <545A3626.5070705@network-heretics.com> <545A39C6.5070302@gmx.de> <545A4955.6030000@network-heretics.com> <545A4BBA.8070709@gmx.de> <545A4DAD.7030802@network-heretics.com> <545A4E9D.7000203@gmx.de> In-Reply-To: <545A4E9D.7000203@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Y7E0J-IX88ZF8leSpLKed7aKj3c Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 16:24:08 -0000 On 11/05/2014 11:21 AM, Julian Reschke wrote: > I understand the use case as defining identifiers that will work in a > predictable way when used as base URI for relative reference resolution. > > Do you disagree that this is the use case? I do. URNs should never be used as base URIs for relative reference resolution. Keith From nobody Thu Nov 6 05:51:42 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD831A6F13 for ; Thu, 6 Nov 2014 05:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7lvqr2XZAcE for ; Thu, 6 Nov 2014 05:51:36 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57F11A6F0D for ; Thu, 6 Nov 2014 05:51:34 -0800 (PST) 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 sA6DpYtI002191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 6 Nov 2014 15:51:38 +0200 Message-ID: <545B7CDF.1010202@helsinki.fi> Date: Thu, 06 Nov 2014 15:51:27 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> <5452A155.2000302@gmx.de> In-Reply-To: <5452A155.2000302@gmx.de> Content-Type: multipart/alternative; boundary="------------070705070605080509090902" Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bqsgDEgKQtZjm255RWPo0PaNPyI Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 13:51:40 -0000 This is a multi-part message in MIME format. --------------070705070605080509090902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello Julian; all, On 30.10.2014 22:36, Julian Reschke wrote: > > It would be helpful if there was more than hand-waving; a *concrete* > list of things you think are broken, please. I don't mind the "small stuff" in RFC 3986 too much. What matters is that when the principles of the URI Generic syntax are applied for identification of things, we should always get identifiers which are persistent and unique and that it is always clear exactly what is being identified. It would also be nice if traditional identifier systems were accommodated and the process of identifier assignment were a properly managed process (whatever that means). Since the proof is in the pudding, let's take a look at the results we get with RFC 3986. I concentrate on identification of names, and start with mailto:. What does URI mailto:julian.reschke@gmx.de identify? There are a few options: 1. Person (Julian Reschke); 2. Public identity of a person who chooses to call himself Julian Reschke in public; 3. Mail box of 1); 4. All of 1-3, or 1-2, 2-3 or 1 and 3; or 5. Nothing. Julian, what is your own take on this? If we select 1-2 or 4 we need to consider if the mailto: identifier of a person is unique. Alas, it is not - a person may have several email addresses (I have three, for instance), and over time an email address may "belong" to different people. So mailto: identifiers are neither persistent nor unique and therefore should not be regarded as proper identifiers. Cool URI proponents may say that although mailto:julian.reschke@gmx.de is a URI, it should not be used as a cool URIs. That may be the case, but then the set of all URIs would be divided into identifiers and non-identifiers in a way which is not explained properly in RFC 3986 or supporting documentation like W3C document Cool URIs for the semantic Web (http://www.w3.org/TR/cooluris/). If such division is formalized, IMO IETF takes a step back towards the old URL - URN approach in which it was always clear whether a string was a name or just a locator. The Cool URIs for the semantic Web -document recommends two different approaches for identification of people. The key thing is to avoid confusing the person to his/her homepage. The resulting identifiers may look like this: http://www.example.com/about#alice or this: http://www.example.com/id/alice so careful design of the Web site is essential. Example (one that still works) of this approach from the W3C document: > http://id.ecs.soton.ac.uk/person/1650 > URI for Wendy Hall, the person > http://www.ecs.soton.ac.uk/people/wh > HTML page about Wendy Hall > http://rdf.ecs.soton.ac.uk/person/1650 > RDF about Wendy Hall > There is another example providing two cool URIs for Chris Bizer, but unfortunately these URIs have already become un-cool because redirect from his previous to newer alma mater does not work any more. Copies of the original Web pages can be found from the Internet Archive so the links in the W3C document can be fixed if there is a need to do so. I think there is; if even cool URIs in W3C guidelines documents die in a few years time it undermines the faith in coolness of URIs in general. I don't want to discuss here whether an URI like http://id.ecs.soton.ac.uk/person/1650 is a good (read: unique and persistent) identifier for a person. But IMO it is a problem that Dame professor Wendy Hall has already two standard identifiers and one de facto identifier, all of which could be used as URIs: http://orcid.org/0000-0003-1634-6930#sthash.Uxnc5LLd.dpu ResearcherID A-6432-2009 ORCID 0000-0003-1634-6930 (https://orcid.org/0000-0003-1634-6930) ISNI 0000 0000 8405 0259 As an aside, metadata record in the ISNI database is a result of merger between two professor Wendy Halls, one a (famous) computer scientist, another a specialist in obstetrics. No system is perfect! From my community's point of view, it is definitely a problem that W3C recommended identifier approach ignores existing identifiers for public identities (and persons), and introduces yet another identifier system which encompasses personal names and basically everything else that the Web can cover one way or another. This kind of parallel identifier system may create a lot of confusion if applied carelessly. IMO the likelihood of a poor implementation of the W3C approach is high, since cool URIs are usually managed at grass roots level. Such approach does not foster persistence, and indeed the short lifetime of links and reference rot are major problems to the semantic Web. Since there are no strict rules for cool URI assignment, it is not clear why one URI is better than another and how to choose the one URI from among the many possible ones. From persistence and exhaustiveness points of view, a work related Southampton university URI is not likely to be a better identifier for Wendy Hall than e.g. http://en.wikipedia.org/wiki/Wendy_Hall since the Wikipedia URI will be more persistent than anything personal or work related. And of course the archived version of Wikipedia page, available at: https://web.archive.org/web/*/http://en.wikipedia.org/wiki/Wendy_Hall is in turn likely to be more persistent than any URL in the living Web, including Wikipedia pages. http://orcid.org/0000-0003-1634-6930#sthash.Uxnc5LLd.dpuf How would information sciences community give URIs to names? One possibility is to use URI based on ORCID (or ISNI) to retrieve a metadata record which provides links to relevant web pages, such as Wendy Hall's Wikipedia page, work / private home pages and so on. In this model the identifier would be unique and persistent, and it is crystal clear what has been identified (since that has been specified in ISNI / ORCID standards and community guidelines). URN fosters the use of existing standard identifiers such as ISNI and ORCID. This is one reason why the information sciences community prefers them over the current, rather loosely managed embodiment of cool URIs. One more thing: I am not requesting any changes to the RFC 3986 and related W3C documents. Things will or will not change based on the practical experiences of semantic web implementers and users. If it ain't broke, don't fix it - if cool URIs eventually become cool enough, they may be a sufficient solution for at least some Web user communities. All the best, Juha > > > Best regards, Julian > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 --------------070705070605080509090902 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hello Julian; all,

On 30.10.2014 22:36, Julian Reschke wrote:


It would be helpful if there was more than hand-waving; a *concrete* list of things you think are broken, please.

I don't mind the "small stuff" in RFC 3986 too much. What matters is that when the principles of the URI Generic syntax are applied for identification of things, we should always get identifiers which are persistent and unique and that it is always clear exactly what is being identified. It would also be nice if traditional identifier systems were accommodated and the process of identifier assignment were a properly managed process (whatever that means).

Since the proof is in the pudding, let's take a look at the results we get with RFC 3986. I concentrate on identification of names, and start with mailto:.

What does URI mailto:julian.reschke@gmx.de identify? There are a few options:

1. Person (Julian Reschke);
2. Public identity of a person who chooses to call himself Julian Reschke in public;
3. Mail box of 1);
4. All of 1-3, or 1-2, 2-3 or 1 and 3; or
5. Nothing.

Julian, what is your own take on this?

If we select 1-2 or 4 we need to consider if the mailto: identifier of  a person is unique. Alas, it is not - a person may have several email addresses (I have three, for instance), and over time an email address may "belong" to different people. So mailto: identifiers are neither persistent nor unique and therefore should not be regarded as proper identifiers. 

Cool URI proponents may say that although mailto:julian.reschke@gmx.de is a URI, it should not be used as a cool URIs. That may be the case, but then the set of all URIs would be divided into identifiers and non-identifiers in a way which is not explained properly in RFC 3986 or supporting documentation like W3C document Cool URIs for the semantic Web (http://www.w3.org/TR/cooluris/). If such division is formalized, IMO IETF takes a step back towards the old URL - URN approach in which it was always clear whether a string was a name or just a locator. 

The Cool URIs for the semantic Web -document recommends two different approaches for identification of people. The key thing is to avoid confusing the person to his/her homepage. The resulting identifiers may look like this:

http://www.example.com/about#alice

or this:

http://www.example.com/id/alice

so careful design of the Web site is essential. Example (one that still works) of this approach from the W3C document:

http://id.ecs.soton.ac.uk/person/1650
URI for Wendy Hall, the person
http://www.ecs.soton.ac.uk/people/wh
HTML page about Wendy Hall
http://rdf.ecs.soton.ac.uk/person/1650
RDF about Wendy Hall

There is another example providing two cool URIs for Chris Bizer, but unfortunately these URIs have already become un-cool because redirect from his previous to newer alma mater does not work  any more. Copies of the original Web pages can be found from the Internet Archive so the links in the W3C document can be fixed if there is a need to do so. I think there is; if even cool URIs in W3C guidelines documents die in a few years time it undermines the faith in coolness of URIs in general.  

I don't want to discuss here whether an URI like http://id.ecs.soton.ac.uk/person/1650 is a good (read: unique and persistent) identifier for a person. But IMO it is a problem that Dame professor Wendy Hall has already two standard identifiers and one de facto identifier, all of which could be used as URIs:

ResearcherID A-6432-2009
ORCID 0000-0003-1634-6930 (https://orcid.org/0000-0003-1634-6930)
ISNI 0000 0000 8405 0259

As an aside, metadata record in the ISNI database is a result of merger between two professor Wendy Halls, one a (famous) computer scientist, another a specialist in obstetrics. No system is perfect!

From my community's point of view, it is definitely a problem that W3C recommended identifier approach ignores existing identifiers for public identities (and persons), and introduces yet another identifier system which encompasses personal names and basically everything else that the Web can cover one way or another. This kind of parallel identifier system may create a lot of confusion if applied carelessly.  

IMO the likelihood of a poor implementation of the W3C approach is high, since cool URIs are usually managed at grass roots level. Such approach does not foster persistence, and indeed the short lifetime of links and reference rot are major problems to the semantic Web.

Since there are no strict rules for cool URI assignment, it is not clear why one URI is better than another and how to choose the one URI from among the many possible ones. From persistence and exhaustiveness points of view, a work related Southampton university URI is not likely to be a better identifier for Wendy Hall than e.g.  

http://en.wikipedia.org/wiki/Wendy_Hall

since the Wikipedia URI will be more persistent than anything personal or work related. And of course the archived version of Wikipedia page, available at:

https://web.archive.org/web/*/http://en.wikipedia.org/wiki/Wendy_Hall

is in turn likely to be more persistent than any URL in the living Web, including Wikipedia pages.

How would information sciences community give URIs to names? One possibility is to use URI based on ORCID (or ISNI) to retrieve a metadata record which provides links to relevant web pages, such as Wendy Hall's Wikipedia page, work / private home pages and so on. In this model the identifier would be unique and persistent, and it is crystal clear what has been identified (since that has been specified in ISNI / ORCID standards and community guidelines).

URN fosters the use of existing standard identifiers such as ISNI and ORCID. This is one reason why the information sciences community prefers them over the current, rather loosely managed embodiment of cool URIs.

One more thing: I am not requesting any changes to the RFC 3986 and related W3C documents. Things will or will not change based on the practical experiences of semantic web implementers and users. If it ain't broke, don't fix it - if cool URIs eventually become cool enough, they may be a sufficient solution for at least some Web user  communities. 

All the best,
 
Juha


Best regards, Julian

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn 


-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University
 Tel. +358 9 191 44293
 Mobile +358 50 3827678
--------------070705070605080509090902-- From nobody Thu Nov 6 06:13:26 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5212A1A1B0E for ; Thu, 6 Nov 2014 06:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH1YsWp7q_Cv for ; Thu, 6 Nov 2014 06:13:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29F61A6F2F for ; Thu, 6 Nov 2014 06:13:04 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MgcTf-1XQkaf2nRP-00Nyfc; Thu, 06 Nov 2014 15:13:02 +0100 Message-ID: <545B81EC.2060306@gmx.de> Date: Thu, 06 Nov 2014 15:13:00 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> <5452A155.2000302@gmx.de> <545B7CDF.1010202@helsinki.fi> In-Reply-To: <545B7CDF.1010202@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2pJInJwYf9AHRAIbbsjM7AORM7M6YmXaZJqMs3k6EdocdvuNXkL vIABmU3rjjO1OeJKoi9nbGxVU9bXpMniserc1WlAnmtgMbE5NKzRVKsaaQZK+Xb2HnNSsxN Eyl2OSBqpGr6ikP+EV7i1Gzh4FR5kridx5ug0SZeyqY4No6yGL6ORYk4Wef61+NTZoPfRN1 fONcUrDb+bb7F/4KOQZxQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/93VsyCxT5XiUwhXPY7u1TtQVwvw Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 14:13:24 -0000 On 2014-11-06 14:51, Juha Hakala wrote: > Hello Julian; all, > > On 30.10.2014 22:36, Julian Reschke wrote: > >> >> It would be helpful if there was more than hand-waving; a *concrete* >> list of things you think are broken, please. > > I don't mind the "small stuff" in RFC 3986 too much. What matters is > that when the principles of the URI Generic syntax are applied for > identification of things, we should always get identifiers which are > persistent and unique and that it is always clear exactly what is being > identified. It would also be nice if traditional identifier systems were > accommodated and the process of identifier assignment were a properly > managed process (whatever that means). > > Since the proof is in the pudding, let's take a look at the results we > get with RFC 3986. I concentrate on identification of names, and start > with mailto:. > > What does URI mailto:julian.reschke@gmx.de identify? There are a few > options: > > 1. Person (Julian Reschke); > 2. Public identity of a person who chooses to call himself Julian > Reschke in public; > 3. Mail box of 1); > 4. All of 1-3, or 1-2, 2-3 or 1 and 3; or > 5. Nothing. > > Julian, what is your own take on this? > ... My take on this is that you're now fully in "resource semantics" mode; something very smart people have been discussing since we have URIs (it's BTW the reason why the W3C TAG was established). I don't plan to participate in that discussion; can we concentrate on the syntax and the operations defined by RFC 3986? Best regards, Julian From nobody Thu Nov 6 06:48:05 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F751A88D4 for ; Thu, 6 Nov 2014 06:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYAbt61UFUhx for ; Thu, 6 Nov 2014 06:48:01 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557991A1B38 for ; Thu, 6 Nov 2014 06:48:01 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 83EC2200D9 for ; Thu, 6 Nov 2014 09:48:00 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 06 Nov 2014 09:48:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=QZj06SiyVb9vjIzYu7xVFP CMLMc=; b=SdJWu6T9Ke1654Whp9Zb5iYPfQn45VviHbnpC+cOFQbaulrzBvurIS dMG6qqrFB0fUQLpslZiSXpQUATHxFq4EtCNE7y7lmC0g61AVXxZDB7XQjKN1dp3k hDgD5YLNv3ni1SFbHZzeOrjj1zSkbcJStOQhhtTp1V4H0qxFVzUws= X-Sasl-enc: hyop2QMQoeoe8X4fZxckLm1UxXsOHrBwUyZIT93AJ41F 1415285280 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 29EB3C0000A; Thu, 6 Nov 2014 09:48:00 -0500 (EST) Message-ID: <545B8A15.6010003@network-heretics.com> Date: Thu, 06 Nov 2014 09:47:49 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> <5452A155.2000302@gmx.de> <545B7CDF.1010202@helsinki.fi> <545B81EC.2060306@gmx.de> In-Reply-To: <545B81EC.2060306@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/w-YkKk4j0-0eqvcr_i3zKMkxyHg Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 14:48:03 -0000 On 11/06/2014 09:13 AM, Julian Reschke wrote: > I don't plan to participate in that discussion; can we concentrate on > the syntax and the operations defined by RFC 3986? Can we concentrate instead on the syntax for URNs, since that's the topic of this group, and we've been forbidden to talk about what's wrong with RFC 3986? Keith From nobody Thu Nov 6 06:56:28 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D56E1A88F1 for ; Thu, 6 Nov 2014 06:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drfD7v8kMd0l for ; Thu, 6 Nov 2014 06:56:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828681A88EC for ; Thu, 6 Nov 2014 06:56:25 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Ljqgb-1YIyLc0ZWz-00brVg; Thu, 06 Nov 2014 15:56:21 +0100 Message-ID: <545B8C11.7010104@gmx.de> Date: Thu, 06 Nov 2014 15:56:17 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Keith Moore , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> <5452A155.2000302@gmx.de> <545B7CDF.1010202@helsinki.fi> <545B81EC.2060306@gmx.de> <545B8A15.6010003@network-heretics.com> In-Reply-To: <545B8A15.6010003@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:K4Nxv5ggvgHgOfh00h03KAxrwfWKZxSquWguyYB98/54eRmKJad q++BDoK1wF+1d/8c7h7nhZUI7Q70NlD4GAXF0ec5eT/TBtbWqfmdqD5i9TRU0qz9O2W2cWJ f1msdCi+DTsKlevJOVqKqpesSLhi8QY7dwQIfue1436EiBEUpTxHsJQjnuPd1jpln4Itd7y LH6tqLjN8TzgVeshfiJ2Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/J-xtL_U7hlkZntNTz-T0W_opHV8 Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 14:56:27 -0000 On 2014-11-06 15:47, Keith Moore wrote: > On 11/06/2014 09:13 AM, Julian Reschke wrote: >> I don't plan to participate in that discussion; can we concentrate on >> the syntax and the operations defined by RFC 3986? > > Can we concentrate instead on the syntax for URNs, since that's the > topic of this group, and we've been forbidden to talk about what's wrong > with RFC 3986? That's what should be discussed here, right. Keith: if you want to follow up on that other topic, I recommend using the URI mailing list (). Best regards, Julian From nobody Thu Nov 6 12:37:19 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0E01A1BB0 for ; Thu, 6 Nov 2014 12:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.051 X-Spam-Level: X-Spam-Status: No, score=-4.051 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05pVvouG-Pnt for ; Thu, 6 Nov 2014 12:37:15 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id B14641A2119 for ; Thu, 6 Nov 2014 12:37:14 -0800 (PST) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 9BDD08AD3C for ; Thu, 6 Nov 2014 21:37:13 +0100 (CET) From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: Re: [urn] next steps Thread-Index: Ac/55+7SdlBUORWOTGeZHOV10fAZjQ== Date: Thu, 6 Nov 2014 20:37:13 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC60984@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.94] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/dRaakSZuGn5mBb88KDwd0h4TEp8 Subject: Re: [urn] next steps X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 20:37:17 -0000 Juha, On 04.11.2014, Juha wrote: > Some tentative answers below. >=20 > On 3.11.2014 19:10, Svensson, Lars wrote: > > Peter, all, > > > >> Having finally come around to read 2141bis-08, it certainly brings me > towards a spec I can live with. There are some things I have issues with > (particularly the relation between q-components and resolvers), but I'm n= ot > concerned enough about them that I'd try to stop it from becoming a > specification. > >> > >> Comments (please read them in the light of the above): > >> 1) =A71 states that "a string that conforms to the URN syntax is not n= ecessarily > a valid URN [...]." Is there a way to find out if something just looks li= ke a URN or > if it actually is one? If so, I think we should add some text explaining = that. >=20 > URNs must conform both to the general requirements set by URI syntax > and constraints specified in the namespace registration request (if > any). Within URN:ISBN namespace only those URNs are valid in which NSS > is conformant to either ISBN-10 or ISBN-13 (or some future version of > the ISBN standard). >=20 > If the namespace registration request specifies the NSS syntax in > sufficient detail it is possible to determine if the URN is valid. But > there are many namespaces including URN:NBN in which there is no way to > determine whether the NSS is well formed or not. OK. And trying to write some text to explain that, I realise that we haven'= t specified what a "valid URN" is. Is that a URN that has been registered o= r just one that adheres to a specific syntax? > >> 2) My reading of =A73 is that p-component is not part of the NSS. Is t= hat > correct? If so, the URN comparison becomes a bit counter-intuitive since = the p- > component is used to determine comparison and it would be easier to state > that for comparison, only the schema, the NID and the NSS are relevant. >=20 > Agreed. Alas, I have to admit that I don't understand the role of > p-component in the URN syntax / URN comparison. I wonder if this > uncertainty concerning the role of p element is just one aspect of a > more general question: what path actually means in the URN context. I am > tempted to say that it is allowed in theory in order to maintain > conformance to RFC 3986, but any namespace which plans to allow its > usage should consider that decision carefully. I am pretty sure that ISO > identifiers shall not use it, but URN:NBN may be a different story. I have seen some examples of strings starting with urn: that have slashes i= n them (IIRC it was the attempt to make a URN out of a DOI). While the inte= nt probably was good, they currently cannot be URNs. If 2141bis allows slas= hes they could be (iff the namespace is updated accordingly). That said, I'= m not sure it's a good idea since it could imply that relative URI referenc= es somehow could work. > >> 5) =A73.3 (this is my main concern): the third paragraph says "For exa= mple, it > is possible that the q-component might be used in requests to URN resolut= ion > services." I still think that the components of a URN should apply to the > identified resources and not be hijacked to pass information to other ser= vices > (e. g. resolvers). Information related to resolution services should be p= art of > 2483bis. >=20 > Based on the practical experiences we know that resolution services > required / available will change over time. I don't think that carving > resolution services (and service parameters) in stone (standards track > RFC) is a good idea, since we have to be able to add (at least in the > context of ISO bibliographic identifiers and systems using them) new > services & service parameters easily but in a controlled manner. I fully agree with that. What I think can / could / should be done is to sp= ecify some core things in 2483bis and to make the specification extensible = (which can be done in other RFCs) and to keep an IANA registry of services = and parameters. > Whether the components apply to the identified resource strictly or > loosely is determined by the URI syntax. F-component, assuming that it > bears resemblance to fragment, has to be closely linked to the > identified resource which in this case has to be a single manifestation > of a work. The relation between the identified resource and the result > of the resolution process is less strict (but it still exists) if the q > component is applied. I see no problem in applying the q component for > e.g. retrieving descriptive / administrative / etc. metadata about the > identified resource. I fear that introducing terminology such as "applies closely" or "applies l= oosely" will be more confusing than clarifying. Keith has argued that '"#" = and "?" for URNs should be handled=20 exactly like they are for the most common URLs - by being interpreted in=20 the context of the resources themselves' and I tend to agree with that. (Pl= ease keep in mind that I'm still prepared to accept 2141bis-8). We could wr= ite something along the lines that if we have a string urn:example:123:456:= abc?some=3Dq-component¶meters=3Dhere, the URN ends at the last characte= r before the '?' and that the part after the '?' is intended to be sent to = a resolution service. I consider it an important engineering principle to s= eparate concerns. > Usage of q component for passing requests to resolution services is > likely to happen even if URNBIS cannot agree on if and how the q > component should be used. Information sciences community must make its > URN resolvers more versatile, and q component seems to be the simplest > means for this. Other persistent identifiers (ARK and Handle) are > already using query for passing resolution requests. Yes. The question is if it's part of the identifier. If we say that URNs ar= e identifiers, we need to be specific regarding the role of all components. > If IETF version of > URN syntax does not provide the functionality my community urgently > needs, then one option we must consider is to develop our own, enriched > version of the URN syntax. Unlike URNBIS, we would approach this > challenge mainly from practical point of view. Whether our version would > be 100 % compliant with whatever it is that some people think URI syntax > requires /allows would not be the topmost priority for us. And to be > honest, we don't care too much if there is something wrong with RFC > 3986, as long as the real / imaginary issues do not prevent URNBIS from > achieving useful results. Would it be OK for you if we move all resolution-related features of the UR= N specification to 2483bis? Best, Lars=20 From nobody Thu Nov 6 23:58:10 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF961ACF05 for ; Thu, 6 Nov 2014 23:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_fpAm00VDVS for ; Thu, 6 Nov 2014 23:58:05 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B011A0258 for ; Thu, 6 Nov 2014 23:58:03 -0800 (PST) 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 sA77w79P021695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 7 Nov 2014 09:58:08 +0200 Message-ID: <545C7B88.8080701@helsinki.fi> Date: Fri, 07 Nov 2014 09:58:00 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EFFAC60984@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC60984@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/_MBfmTxDmUIG3ECG57MCtab4SCQ Subject: Re: [urn] next steps X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 07:58:09 -0000 Hello Lars, On 6.11.2014 22:37, Svensson, Lars wrote: > Juha, > > On 04.11.2014, Juha wrote: > >> >> If the namespace registration request specifies the NSS syntax in >> sufficient detail it is possible to determine if the URN is valid. But >> there are many namespaces including URN:NBN in which there is no way to >> determine whether the NSS is well formed or not. > OK. And trying to write some text to explain that, I realise that we haven't specified what a "valid URN" is. Is that a URN that has been registered or just one that adheres to a specific syntax? Valid URN is one which 1. Meets the syntax requirements in RCF 2141(bis), 2. Uses a registered NID, 3. Is well formed according to the administrative / semantic / syntactic requirements of its namespace. For instance URN like "URN:ISNI:0000-0000-3176-4784" does not fulfill the requirement 2, since there is no namespace registration yet for the International Standard Name Identifier. URN:DOI:10.1000/182 fails on two points: there is no namespace registration for DOI, and there is invalid character in NSS. However, both of these URNs could be actionable in the web in spite of not being valid. If the identifier assigned to the resource is invalid or has been canceled (for instance, books sometimes have invalid ISBNs assigned to them by the publisher) the URN based on such identifier must be invalid as well, although it may nevertheless be actionable in the Web. Invalid ISBN is always catalogued, alongside the correct one. > I have seen some examples of strings starting with urn: that have slashes in them (IIRC it was the attempt to make a URN out of a DOI). While the intent probably was good, they currently cannot be URNs. If 2141bis allows slashes they could be (iff the namespace is updated accordingly). That said, I'm not sure it's a good idea since it could imply that relative URI references somehow could work. Alas, even the people with best intentions do not always know what they are doing ;-). > What I think can / could / should be done is to specify some core things in 2483bis and to make the specification extensible (which can be done in other RFCs) and to keep an IANA registry of services and parameters. The plan has been that 2483bis specifies just the mechanism via which the list of services and service parameters is maintained. But - for the sake of backwards interoperability - the document could also provide an initial list of these services (including the ones from RFC 2483, plus perhaps some more) and service parameters. For instance I2C and I2Cs must have such parameters, since URC never materialized and the preferred metadata format has to be included in the request (whether we can / should specify a default value is an open issue; I think Dublin Core might serve such purpose well). > >> Whether the components apply to the identified resource strictly or >> loosely is determined by the URI syntax. F-component, assuming that it >> bears resemblance to fragment, has to be closely linked to the >> identified resource which in this case has to be a single manifestation >> of a work. The relation between the identified resource and the result >> of the resolution process is less strict (but it still exists) if the q >> component is applied. I see no problem in applying the q component for >> e.g. retrieving descriptive / administrative / etc. metadata about the >> identified resource. > I fear that introducing terminology such as "applies closely" or "applies loosely" will be more confusing than clarifying. Keith has argued that '"#" and "?" for URNs should be handled > exactly like they are for the most common URLs - by being interpreted in > the context of the resources themselves' and I tend to agree with that. (Please keep in mind that I'm still prepared to accept 2141bis-8). We could write something along the lines that if we have a string urn:example:123:456:abc?some=q-component¶meters=here, the URN ends at the last character before the '?' and that the part after the '?' is intended to be sent to a resolution service. I consider it an important engineering principle to separate concerns. It is hard to see how "#" could be handled differently in URNs than in other URIs. We can't convince the browser developers to change the behaviour of their applications just for URNs. "?" behaviour is a mixed bag to start with. What resolvers do with them will be specific to the URN context, but such actions are not out of bounds from URI syntax point of view. > >> Usage of q component for passing requests to resolution services is >> likely to happen even if URNBIS cannot agree on if and how the q >> component should be used. Information sciences community must make its >> URN resolvers more versatile, and q component seems to be the simplest >> means for this. Other persistent identifiers (ARK and Handle) are >> already using query for passing resolution requests. > Yes. The question is if it's part of the identifier. If we say that URNs are identifiers, we need to be specific regarding the role of all components. My take on this has been that fragment and query cannot be part if the NSS. The same applies to f and q components. If we leave this question open in RFC 2141bis, then all ISO identifiers at least will not approve f or q components to be added to the NSS. An NSS like 978-952-242-275-0#chapter2 would violate the ISBN community rules. But if we say that NSS consists of the ISBN only and the f component can be added to it any time after the URN has been minted, we solve a lot of administrative and other problems. > >> If IETF version of >> URN syntax does not provide the functionality my community urgently >> needs, then one option we must consider is to develop our own, enriched >> version of the URN syntax. Unlike URNBIS, we would approach this >> challenge mainly from practical point of view. Whether our version would >> be 100 % compliant with whatever it is that some people think URI syntax >> requires /allows would not be the topmost priority for us. And to be >> honest, we don't care too much if there is something wrong with RFC >> 3986, as long as the real / imaginary issues do not prevent URNBIS from >> achieving useful results. > Would it be OK for you if we move all resolution-related features of the URN specification to 2483bis? Perhaps. As far as I am concerned, RFC 2141bis is OK in its current form and should not be modified any more without a good reason. We have spent enough time and effort on this project already. Best regards, Juha > > Best, > > Lars > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Fri Nov 7 05:48:09 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6271A1B8B for ; Fri, 7 Nov 2014 05:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdIA9TRyoQXK for ; Fri, 7 Nov 2014 05:48:04 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C131A1A1B84 for ; Fri, 7 Nov 2014 05:48:03 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 044D32047E for ; Fri, 7 Nov 2014 08:48:02 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 07 Nov 2014 08:48:03 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=nxUDs57bRGGkl8wEmL/u8z 8iHxw=; b=FbOuIXxWGxVLOuBwCN05OReBSyEWUgY8tJD+s6Ga5zOMWpHwXRfC2W nIqV1MoyCZutKBrJSB497r7rRbdKKB/MedOleAIW2XNkPgtk0udjWTvrvQ6AMqDu ZK+im8lpuHa31bLF1x2IU30V1FYw6i1SxU27FfxyYEwBREJU7BUzk= X-Sasl-enc: iXNX83HSXYcsmjPSElgmWLRL/oNpDduPdoZyUL6TTKky 1415368082 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 9E356C00012; Fri, 7 Nov 2014 08:48:02 -0500 (EST) Message-ID: <545CCD87.80609@network-heretics.com> Date: Fri, 07 Nov 2014 08:47:51 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EFFAC60984@dnbf-ex1.AD.DDB.DE> <545C7B88.8080701@helsinki.fi> In-Reply-To: <545C7B88.8080701@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tqb8-k4YbpTxFFoBFmQxS4uRrAs Subject: Re: [urn] next steps X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 13:48:06 -0000 On 11/07/2014 02:58 AM, Juha Hakala wrote: > Hello Lars, > > On 6.11.2014 22:37, Svensson, Lars wrote: >> Juha, >> >> On 04.11.2014, Juha wrote: >> >>> >>> If the namespace registration request specifies the NSS syntax in >>> sufficient detail it is possible to determine if the URN is valid. But >>> there are many namespaces including URN:NBN in which there is no way to >>> determine whether the NSS is well formed or not. >> OK. And trying to write some text to explain that, I realise that we >> haven't specified what a "valid URN" is. Is that a URN that has been >> registered or just one that adheres to a specific syntax? > Valid URN is one which > > 1. Meets the syntax requirements in RCF 2141(bis), > 2. Uses a registered NID, > 3. Is well formed according to the administrative / semantic / > syntactic requirements of its namespace. I would claim that it needs to also actually be registered by that namespace, at least for those namespaces that register names. (i.e. not UUIDs but nearly everything else) We don't want people thinking that any syntactically valid string that begins with urn: is a valid URN and using that as an excuse to bypass registration requirements that ensure uniqueness. Keith From nobody Sun Nov 9 14:46:51 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FEE1A8752 for ; Sun, 9 Nov 2014 14:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh15O1y6Yvsv for ; Sun, 9 Nov 2014 14:46:48 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7A01A700A for ; Sun, 9 Nov 2014 14:46:47 -0800 (PST) Received: from [172.20.10.3] (unknown [70.210.133.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8B6E5509B8; Sun, 9 Nov 2014 17:46:36 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_BED29863-786C-4CA9-948A-3236A6C61686"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <051E4A54-131C-4EE0-B0B1-A88FA78B6FD3@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Sun, 9 Nov 2014 12:45:20 -1000 References: <24637769D123E644A105A0AF0E1F92EFFAC60984@dnbf-ex1.AD.DDB.DE> <545C7B88.8080701@helsinki.fi> <545CCD87.80609@network-heretics.com> To: Keith Moore , urn@ietf.org In-Reply-To: <545CCD87.80609@network-heretics.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/9tmw-HDeA3-RiosgDJnddh8ftMk Subject: Re: [urn] next steps X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 22:46:50 -0000 --Apple-Mail=_BED29863-786C-4CA9-948A-3236A6C61686 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 7, 2014, at 5:47 AM, Keith Moore = wrote: > On 11/07/2014 02:58 AM, Juha Hakala wrote: >> Hello Lars, >>=20 >> On 6.11.2014 22:37, Svensson, Lars wrote: >>> Juha, >>>=20 >>> On 04.11.2014, Juha wrote: >>>=20 >>>>=20 >>>> If the namespace registration request specifies the NSS syntax in >>>> sufficient detail it is possible to determine if the URN is valid. = But >>>> there are many namespaces including URN:NBN in which there is no = way to >>>> determine whether the NSS is well formed or not. >>> OK. And trying to write some text to explain that, I realise that we = haven't specified what a "valid URN" is. Is that a URN that has been = registered or just one that adheres to a specific syntax? >> Valid URN is one which >>=20 >> 1. Meets the syntax requirements in RCF 2141(bis), >> 2. Uses a registered NID, >> 3. Is well formed according to the administrative / semantic / = syntactic requirements of its namespace. >=20 > I would claim that it needs to also actually be registered by that = namespace, at least for those namespaces that register names. (i.e. not = UUIDs but nearly everything else) We don't want people thinking that = any syntactically valid string that begins with urn: is a valid URN and = using that as an excuse to bypass registration requirements that ensure = uniqueness. That is why (in [this post][]) I used the term =93registrable=94 rather = than =93registered=94. It is not necessary for an elaborate registry to = be created and unfailingly maintained; it is only necessary that the = names be assigned using a process that ensures uniqueness, and that = those unique names can be registered if someone wants to maintain such a = registry. The registry makes the names discoverable, but the registry is = not a bedrock requirement for a valid URN namespace. UUIDs can be = generated and assigned randomly, yet the IDs are registrable, and that = works for URN purposes. [this post]: = http://mailarchive.ietf.org/arch/msg/urn/1xNZg-0JzRe-BGRROEQ6eyarXKc Cheers, Sean= --Apple-Mail=_BED29863-786C-4CA9-948A-3236A6C61686 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTEwOTIyNDYyOFowIwYJKoZIhvcNAQkEMRYEFBHVinX2CrUPOPfulMQQzU5C kZfPMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAMY+ypVzwx/La2iKEQxqYwm8ELWan1M4PCYveBBWyj0jbYzXg7oV7ZaiTLWAd1g3TXlAQNMPN t/Xa7XPcOxPs8QhXFkEaO6QngaM23NEWi5RH1wwDeRSFCnSF4om+/yjgAgtXu9ceYR2EPKRgC6qe tb7R4/pYbvmMKEUOWGC4TApEYU+psXvO3IYZaoJ8SZrrF72IVzNxFJQsDsJMqTqloa0evcmY1N6F dXwXDmIhT/R81hTUQBXmz6VRIctWl+V9H78U2GzYPgumqIaaeq5EElXzOkZfe33iCnF6Tk5gQmYZ QlFsdghQRoBY5Vs+9febupx7OlDB5dC2fpNiun1wWwAAAAAAAA== --Apple-Mail=_BED29863-786C-4CA9-948A-3236A6C61686-- From nobody Sun Nov 9 16:35:03 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F098E1A6FB9 for ; Thu, 6 Nov 2014 06:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm-BVffpcQfz for ; Thu, 6 Nov 2014 06:03:58 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id B5DBF1A6FB0 for ; Thu, 6 Nov 2014 06:03:58 -0800 (PST) Received: from [192.168.1.26] (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id CC09115A068E; Thu, 6 Nov 2014 15:03:57 +0100 (CET) Message-ID: <545B7FCC.2060301@greenbytes.de> Date: Thu, 06 Nov 2014 15:03:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> <5452A155.2000302@gmx.de> <545B7CDF.1010202@helsinki.fi> In-Reply-To: <545B7CDF.1010202@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/KtkA4K_0ijBXIijZq8KGJ7W7wxM X-Mailman-Approved-At: Sun, 09 Nov 2014 16:35:02 -0800 Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 14:04:01 -0000 On 2014-11-06 14:51, Juha Hakala wrote: > Hello Julian; all, > > On 30.10.2014 22:36, Julian Reschke wrote: > >> >> It would be helpful if there was more than hand-waving; a *concrete* >> list of things you think are broken, please. > > I don't mind the "small stuff" in RFC 3986 too much. What matters is > that when the principles of the URI Generic syntax are applied for > identification of things, we should always get identifiers which are > persistent and unique and that it is always clear exactly what is being > identified. It would also be nice if traditional identifier systems were > accommodated and the process of identifier assignment were a properly > managed process (whatever that means). > > Since the proof is in the pudding, let's take a look at the results we > get with RFC 3986. I concentrate on identification of names, and start > with mailto:. > > What does URI mailto:julian.reschke@gmx.de identify? There are a few > options: > > 1. Person (Julian Reschke); > 2. Public identity of a person who chooses to call himself Julian > Reschke in public; > 3. Mail box of 1); > 4. All of 1-3, or 1-2, 2-3 or 1 and 3; or > 5. Nothing. > > Julian, what is your own take on this? > ... My take on this is that you're now fully in "resource semantics" mode; something very smart people have been discussing since we have URIs (it's BTW the reason why the W3C TAG was established). I don't plan to participate in that discussion; can we concentrate on the syntax and the operations defined by RFC 3986? Best regards, Julian From nobody Sun Nov 9 18:12:41 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7649C1A8881 for ; Sun, 9 Nov 2014 18:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Nq1Jf70RIcP for ; Sun, 9 Nov 2014 18:12:38 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB851A887C for ; Sun, 9 Nov 2014 18:12:38 -0800 (PST) Received: from dhcp-b3ac.meeting.ietf.org (unknown [31.133.179.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 09CAD22E1FA for ; Sun, 9 Nov 2014 21:12:36 -0500 (EST) From: Sean Leonard Content-Type: multipart/alternative; boundary="Apple-Mail=_7B603B03-B594-453A-9517-83B828F6D0A2" Message-Id: <26436CF1-C05B-4F50-BAA5-207F1B3D9EC8@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Sun, 9 Nov 2014 16:12:34 -1000 References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> <5452A155.2000302@gmx.de> <545B7CDF.1010202@helsinki.fi> To: urn@ietf.org In-Reply-To: <545B7CDF.1010202@helsinki.fi> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/xsS2kjX9nrUQwMIqBsrDPlW9dy0 Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 02:12:40 -0000 --Apple-Mail=_7B603B03-B594-453A-9517-83B828F6D0A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 6, 2014, at 3:51 AM, Juha Hakala wrote: >=20 > What does URI mailto:julian.reschke@gmx.de identify? There are a few = options:=20 mailto: may not be the best example. Yes, it is an identifier=85but it = really is meant to be a launch code for composing an e-mail in an e-mail = client. RFC 6068 says: The 'mailto' URI scheme is used to identify resources that are reached using Internet mail. In its simplest form, a 'mailto' URI contains an Internet mail address. [=85] A 'mailto' URI designates an "Internet resource", which is the mailbox specified in the address. When additional header fields are supplied, the resource designated is the same address but with an additional profile for accessing the resource. While there are Internet resources that can only be accessed via electronic mail, the 'mailto' URI is not intended as a way of retrieving such objects automatically. The operation of how any URI scheme is resolved is not mandated by the URI specifications. [=85] The 'mailto' URI has unusual semantics because resolving such a URI does not cause an immediate interaction with a server. Instead, the client creates a message to the designated address with the various header fields set as default. The user can edit the message, send the message unedited, or choose not to send the message. RFC 2368 says more-or-less the same thing. If you want to designate a way to access a mailbox, you use imap: or = pop: URIs. If you want to designate an e-mail address, just the e-mail address = will do the trick. If you want to cause an URI processing software system to launch e-mail = software to send e-mail to an e-mail address, you use mailto:. And you = can specify headers and such. I guess the point is that mailto: doesn=92t really identify anything=97at = least not your 1, 2, 3, or 4. It *consumes* identifiers as part of its = function to send e-mail. Arguably, it identifies a not-yet-created = e-mail message with some fields filled in. By analogy, = http://example.com/foo doesn=92t identify a domain name, or a path. It = consumes those identifiers as part of its function to do something else = (in this case, actually identify a complete resource accessible over = HTTP, as well as cause the resource to be retrieved, when the URI is = dereferenced). Perhaps this helps to clarify the distinction between what a URN = identifies, what a URN does when resolved, and what identifiers a URN = consumes as part of its function? Sean --Apple-Mail=_7B603B03-B594-453A-9517-83B828F6D0A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On Nov = 6, 2014, at 3:51 AM, Juha Hakala <juha.hakala@helsinki.fi> = wrote:

=20 =20

What does URI mailto:julian.reschke@gmx.de = identify? There are a few options:

mailto: may not = be the best example. Yes, it is an identifier=85but it really is meant = to be a launch code for composing an e-mail in an e-mail = client.

RFC 6068 says:
   The 'mailto' URI =
scheme is used to identify resources that are
   reached using Internet mail.  In its simplest form, a 'mailto' URI
   contains an Internet mail address.  [=85]


  =
 A 'mailto' URI designates an "Internet resource", which is the
   mailbox specified in the address.  When additional header fields are
   supplied, the resource designated is the same address but with an
   additional profile for accessing the resource.  While there are
   Internet resources that can only be accessed via electronic mail, the
   'mailto' URI is not intended as a way of retrieving such objects
   automatically.

   The operation of how any URI scheme is resolved is not mandated by
   the URI specifications.  [=85]
   The 'mailto' URI has unusual semantics because resolving such a URI
   does not cause an immediate interaction with a server.  Instead, the
   client creates a message to the designated address with the various
   header fields set as default.  The user can edit the message, send
   the message unedited, or choose not to send the message.

RFC 2368 says more-or-less the same = thing.

If you want to designate a way to access = a mailbox, you use imap: or pop: URIs.

If you = want to designate an e-mail address, just the e-mail address <julian.reschke@gmx.de> will = do the trick.

If you want to cause an URI = processing software system to launch e-mail software to send e-mail to = an e-mail address, you use mailto:. And you can specify headers and = such.

I guess the point is that mailto: doesn=92t= really identify anything=97at least not your 1, 2, 3, or 4. It = *consumes* identifiers as part of its function to send e-mail. Arguably, = it identifies a not-yet-created e-mail message with some fields filled = in. By analogy, http://example.com/foo doesn=92t = identify a domain name, or a path. It consumes those identifiers as part = of its function to do something else (in this case, actually identify a = complete resource accessible over HTTP, as well as cause the resource to = be retrieved, when the URI is = dereferenced).

Perhaps this helps to clarify = the distinction between what a URN identifies, what a URN does when = resolved, and what identifiers a URN consumes as part of its = function?

Sean

= --Apple-Mail=_7B603B03-B594-453A-9517-83B828F6D0A2-- From nobody Sun Nov 9 18:32:15 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523DD1A8897 for ; Sun, 9 Nov 2014 18:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcrZKXBLV6fe for ; Sun, 9 Nov 2014 18:32:11 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4321A8892 for ; Sun, 9 Nov 2014 18:32:11 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xnem2-0002MT-PM for urn@ietf.org; Sun, 09 Nov 2014 21:32:10 -0500 Date: Sun, 09 Nov 2014 21:32:10 -0500 From: John C Klensin To: urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/GK-fDKGHvJ_sxEyKAbPoQUpbJ_4 Subject: [urn] Clarification of p-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 02:32:13 -0000 Hi. I've just read all of the postings since I tuned out and went on travel around 24 October. I am trying to remain optimistic, but it seems to me that we are cycling through the same arguments, with people taking what amount to "either agree with my point of view or we will have no agreement at all" positions. If what is wanted is paralysis in this WG, eventually shutting it down, and movement of the work into one or more places that won't care about the Grand Unified Theory of URIs (or even URNs), we seem to be right on track. In particular, I hope I'm being consistent with Peter and the draft here, but when I say "p-component", I'm not using a funny term for 3966 "path". Instead, I'm talking about a path component, i.e., a piece of syntax that, for URNs, follows urn:nid:nss/ Allowing a "/", followed by a string, there would allow DOIs to work and be valid. It would also allow qualification on the basic URN string that would be treated "as part of" the URN for multiple purposes, including comparisons. It seems to me that those are desirable things to have, whether a particular NID allows them (or requires them) or not. It also seems perfectly rational to me (and, fwiw, consistent with 3986 syntax restrictions) for some NIDs to allow the things and others to not do so. The reason for allowing p-components at all is, for me, precisely to allow something that is separate from the NSS (or the pre-"/" part of the NSS) that sufficiently strongly affects the rest of the URN to be considered an essential part of that URN for comparison purposes. People have made strong arguments that things that look like queries or fragments cannot provide that function. As far as I can tell, that definition of a p-component works perfectly well with 3986 URI syntax. I don't think the question of whether it matches someone's idea of URI semantics, especially semantics that are closely tied to URLs, is helpful. If the presence of that slash causes generic URI parsing systems that incorporate enough semantics to try to resolve relative references to try to do that, syntactically, to URN base references, I think that would constitute a silly state, but not a silly state that a URN spec needs to go out of its way to prevent or prohibit. On the other hand, it seems to me that the URN spec need not have specific rules about how relative references are interpreted: they are just invalid for URNs because they are meaningless. Finally, as to whether the p-component is part of the NSS (something defined in 2141 that did not then permit a "/") or follows it is a bit of definitional wizardry that, IMO, this WG can work out in whatever way seems convenient. Neither definition violates 3989 syntax rules; either could be described in 2141bis in a way that would be a compatible extension from 2141. My intuition at the moment says "after the NSS, separated by that "/" character), but I don't feel really strongly about it. We now return you to the usual repetitive, non-convergent, arguments :-( john From nobody Mon Nov 10 05:34:33 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945901A8AC1 for ; Mon, 10 Nov 2014 05:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_HERE=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n2lD4wklu9d for ; Mon, 10 Nov 2014 05:34:28 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CD11A8AC0 for ; Mon, 10 Nov 2014 05:34:26 -0800 (PST) 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 sAADYVBc017398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 10 Nov 2014 15:34:31 +0200 Message-ID: <5460BEDF.3020708@helsinki.fi> Date: Mon, 10 Nov 2014 15:34:23 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> <5452A155.2000302@gmx.de> <545B7CDF.1010202@helsinki.fi> <26436CF1-C05B-4F50-BAA5-207F1B3D9EC8@seantek.com> In-Reply-To: <26436CF1-C05B-4F50-BAA5-207F1B3D9EC8@seantek.com> Content-Type: multipart/alternative; boundary="------------040802070709080202090202" Archived-At: http://mailarchive.ietf.org/arch/msg/urn/YKG4TPviGX06vP88q2rt4v6w-YA Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 13:34:32 -0000 This is a multi-part message in MIME format. --------------040802070709080202090202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello, On 10.11.2014 4:12, Sean Leonard wrote: > On Nov 6, 2014, at 3:51 AM, Juha Hakala > wrote: > >> >> What does URI mailto:julian.reschke@gmx.de identify? There are a few >> options: > > mailto: may not be the best example. Yes, it is an identifier…but it > really is meant to be a launch code for composing an e-mail in an > e-mail client. I used mailto: as an example since its role in identification is discussed in the WWW architecture document (http://www.w3.org/TR/webarch/#identification): > To say that the URI "mailto:nadia@example.com" identifies both an > Internet mailbox and Nadia, the person, introduces a URI collision. > However, we can use the URI to indirectly identify Nadia. Identifiers > are commonly used in this way. > > Suppose that |nadia@example.com| is Nadia's email address. The > organizers of a conference Nadia attends might use > "mailto:nadia@example.com" to refer indirectly to her (e.g., by using > the URI as a database key in their database of conference > participants). This does not introduce a URI collision. > I find it interesting that WWW architecture document uses a trivial example like this. The problems information sciences community (and, eventually, the Web too) must solve are more complicated. For instance, there are about 20.000 Dr. Wang's who are currently active researchers, and it is necessary to identify them all to give merit to whom it belongs, taking into account that 40 years from now there will be 10.000 new Dr. Wang's. This cannot be done by using email addresses or personal home pages as identifiers. An email address can have a supporting role (it is used in such way in ORCID system) but it should not be used as an identifier, indirect or otherwise. Julian said: > My take on this is that you're now fully in "resource semantics" mode; > something very smart people have been discussing since we have URIs > (it's BTW the reason why the W3C TAG was established). URNBIS avoids the semantics problem since in the URN system resource semantics (for instance: what can be identified, and how) is specified separately in each namespace in documents like the ISBN manual (which settles things for urn:isbn). To put this in other words, URNBIS has no mandate to say that according to this or that URI principle the current practice of ISBN assignment is wrong and has to be modified if ISBNs are to be used as URNs. Indeed, W3C TAG has spent a lot of time trying to deal with resource semantics in the Web/URI context, but based on http://www.w3.org/2001/tag/group/track/issues/ it seems that there is still a lot of work to be done (persistence of identifiers -task is still open, nine years after it was established). And given the magnitude of the problem in the URI context I don't believe there will ever be a solution that would make all the Web users happy. > > I don't plan to participate in that discussion; can we concentrate on > the syntax and the operations defined by RFC 3986? Unfortunately URNBIS gets into trouble when conclusions regarding the URI/URN syntax are drawn from the URI semantics. For instance, the URL of somebody's homepage could "identify" both the person and the homepage. So there is a recommendation that the home page URL is used to identify the home page, and the home page URL + fragment is used to identify the person. To give a fragment a role like this is OK from the RFC 3986 point of view, but not acceptable for most standard identifiers which do not allow adding URI fragments to NSS. (And the information sciences community certainly does not and will not identify people with their home page URLs, with or without fragments.) The latest RFC 2141bis solves this problem (and other syntax issues I am aware of) in a way which works for me. Sean; concerning this: > > I guess the point is that mailto: doesn’t really identify anything—at > least not your 1, 2, 3, or 4. It *consumes* identifiers as part of its > function to send e-mail. Arguably, it identifies a not-yet-created > e-mail message with some fields filled in. By analogy, > http://example.com/foo doesn’t identify a domain name, or a path. It > consumes those identifiers as part of its function to do something > else (in this case, actually identify a complete resource accessible > over HTTP, as well as cause the resource to be retrieved, when the URI > is dereferenced). IMO sensible people can and will have different views on what mailto: identifies (if anything). It is unlikely that any resource semantics guidelines in Web architecture documents will fully eliminate this problem. On the other hand, there is a simple solution for this problem in the URN system: do not approve mailto: namespace, since a) email addresses are neither unique nor persistent, and b) it is not obvious what they identify. Juha > > Perhaps this helps to clarify the distinction between what a URN > identifies, what a URN does when resolved, and what identifiers a URN > consumes as part of its function? > > Sean > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 --------------040802070709080202090202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hello,

On 10.11.2014 4:12, Sean Leonard wrote:
On Nov 6, 2014, at 3:51 AM, Juha Hakala <juha.hakala@helsinki.fi> wrote:


What does URI mailto:julian.reschke@gmx.de identify? There are a few options:

mailto: may not be the best example. Yes, it is an identifier…but it really is meant to be a launch code for composing an e-mail in an e-mail client.

I used mailto: as an example since its role in identification is discussed in the WWW architecture document (http://www.w3.org/TR/webarch/#identification):

To say that the URI "mailto:nadia@example.com" identifies both an Internet mailbox and Nadia, the person, introduces a URI collision. However, we can use the URI to indirectly identify Nadia. Identifiers are commonly used in this way.

Suppose that nadia@example.com is Nadia's email address. The organizers of a conference Nadia attends might use "mailto:nadia@example.com" to refer indirectly to her (e.g., by using the URI as a database key in their database of conference participants). This does not introduce a URI collision.


I find it interesting that WWW architecture document uses a trivial example like this. The problems information sciences community (and, eventually, the Web too) must solve are more complicated. For instance, there are about 20.000 Dr. Wang's who are currently active researchers, and it is necessary to identify them all to give merit to whom it belongs, taking into account that 40 years from now there will be 10.000 new Dr. Wang's. This cannot be done by using email addresses or personal home pages as identifiers. An email address can have a supporting role (it is used in such way in ORCID system) but it should not be used as an identifier, indirect or otherwise.
 
Julian said:

My take on this is that you're now fully in "resource semantics" mode; something very smart people have been discussing since we have URIs (it's BTW the reason why the W3C TAG was established).

URNBIS avoids the semantics problem since in the URN system resource semantics (for instance: what can be identified, and how) is specified separately in each namespace in documents like the ISBN manual (which settles things for urn:isbn). To put this in other words, URNBIS has no mandate to say that according to this or that URI principle the current practice of ISBN assignment is wrong and has to be modified if ISBNs are to be used as URNs.

Indeed, W3C TAG has spent a lot of time trying to deal with resource semantics in the Web/URI context, but based on

http://www.w3.org/2001/tag/group/track/issues/

it seems that there is still a lot of work to be done (persistence of identifiers -task is still open, nine years after it was established).  And given the magnitude of the problem in the URI context I don't believe there will ever be a solution that would make all the Web users happy.


I don't plan to participate in that discussion; can we concentrate on the syntax and the operations defined by RFC 3986?
 
Unfortunately URNBIS gets into trouble when conclusions regarding the URI/URN syntax are drawn from the URI semantics. For instance, the URL of somebody's homepage could "identify" both the person and the homepage. So there is a recommendation that the home page URL is used to identify the home page, and the home page URL + fragment is used to identify the person.  To give a fragment a role like this is OK from the RFC 3986 point of view, but not acceptable for most standard identifiers which do not allow adding URI fragments to NSS. (And the information sciences community certainly does not and will not identify people with their home page URLs, with or without fragments.) The latest RFC 2141bis solves this problem (and other syntax issues I am aware of) in a way which works for me.  

Sean; concerning this:


I guess the point is that mailto: doesn’t really identify anything—at least not your 1, 2, 3, or 4. It *consumes* identifiers as part of its function to send e-mail. Arguably, it identifies a not-yet-created e-mail message with some fields filled in. By analogy, http://example.com/foo doesn’t identify a domain name, or a path. It consumes those identifiers as part of its function to do something else (in this case, actually identify a complete resource accessible over HTTP, as well as cause the resource to be retrieved, when the URI is dereferenced).


IMO sensible people can and will have different views on what mailto: identifies (if anything). It is unlikely that any resource semantics guidelines in Web architecture documents will fully eliminate this problem. On the other hand, there is a simple solution for this problem in the URN system: do not approve mailto: namespace, since a) email addresses are neither unique nor persistent, and b) it is not obvious what they identify.

Juha
 

Perhaps this helps to clarify the distinction between what a URN identifies, what a URN does when resolved, and what identifiers a URN consumes as part of its function?

Sean



_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn



-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University
 Tel. +358 9 191 44293
 Mobile +358 50 3827678
--------------040802070709080202090202-- From nobody Tue Nov 11 14:57:09 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DB91A1BCC for ; Tue, 11 Nov 2014 14:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZpIRjc_mTlG for ; Tue, 11 Nov 2014 14:57:07 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24C61A1B71 for ; Tue, 11 Nov 2014 14:57:06 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3177720BBA for ; Tue, 11 Nov 2014 17:57:05 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 11 Nov 2014 17:57:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=aGFpojmyc+SC3Kpshq50Kb HCnxc=; b=sNHSer/a4DZD3TRtx5xlPdRAY86kBkMR6Bc+KLvmpKlOSRcKWXCZUa fZhszD9orMiiI8l9e3zwnb7X4tZBf48Oz4LFQwi0rYxpeqj9Ed0k8CNuz1Q1cLD6 z4eF4yTqLieIC2s45u8bxBxphE3Z9VHI+3xX8B+TAxZKnP/YXRBt8= X-Sasl-enc: fuDLsdq1EYz/zQQh3ZqRxqsX9x7bVZjNXnmGqHi0F4IN 1415746624 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 81C1EC0000A; Tue, 11 Nov 2014 17:57:04 -0500 (EST) Message-ID: <54629434.6040307@network-heretics.com> Date: Tue, 11 Nov 2014 17:56:52 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: <54403493.5080808@andyet.net> <201410172154.s9HLsUgm014843@hobgoblin.ariadne.com> <544213BD.7010605@gmx.de> <168FB94003AA4217329EC43A@JcK-HP8200.jck.com> <544226BD.2090309@gmx.de> <110A5DACBF4AC2C3C2DF90E8@JcK-HP8200.jck.com> <544244A5.1000301@gmx.de> <5443195C.8010105@andyet.net> <544371A3.4010409@gmx.de> <54451F2E.3060909@gmx.de> <201410211622.s9LGMuug019355@hobgoblin.ariadne.com> <5446A8AE.9050601@gmx.de> <54529D53.2020003@network-heretics.com> <5452A155.2000302@gmx.de> <545B7CDF.1010202@helsinki.fi> <26436CF1-C05B-4F50-BAA5-207F1B3D9EC8@seantek.com> In-Reply-To: <26436CF1-C05B-4F50-BAA5-207F1B3D9EC8@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/teMQL9e4wLZ6zq5obqd9a3UIfcM Subject: Re: [urn] syntax and registration: a proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 22:57:08 -0000 On 11/09/2014 09:12 PM, Sean Leonard wrote: > I guess the point is that mailto: doesn’t really identify anything Well, you can use it as a way to identify something. Just because the historical behavior associated with mailto: in a browser is to launch an email compose window when clicked, doesn't mean that's what mailto: means. But I don't see what any of this has to do with URNs, because mailto: URIs aren't URNs. Keith From nobody Mon Nov 17 11:09:57 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2C01A8939 for ; Mon, 17 Nov 2014 11:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4-SuryZ-0O0 for ; Mon, 17 Nov 2014 11:09:48 -0800 (PST) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D981A8932 for ; Mon, 17 Nov 2014 11:09:46 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id g10so6554134pdj.41 for ; Mon, 17 Nov 2014 11:09:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=bm/1S98XXIyuEXReN5Zp+SU877M4MmSFrRCYU/7xDHM=; b=Db8I6Q4smu8/+ZCFrRiwalZ5f8PZZfui3coS7KPSAr9dwK1Hr8CiAIEgylRDXQltE0 JHWxgA5Rr/OuUim5bJVHKlhl4XChq/9Z5mLGgkRtcHBp04kPmt3qDfp+SZnruRtP6LAk DRY6Xta/UZO6pEKVWPeX0Oc8iCtgOImz/vr3M3ggzFEtqJft0gTMUiMvEacSW+68Sqsl GpCWrXtO57l2u5TP3U3FA0ArzJZYV370EjIRX4cXOgZlYstf80uA62TUKbHVT0GYBitL Xb3oAXIUoNyOTFaJXkP1bSwP1qfpXfMQqMvXzLTmo+PPQZ7sJoJy683GQoge7X7N4wiq T7pw== X-Gm-Message-State: ALoCoQkjJXiZ5wrhCLjn68jeWtJIOJZr1sW4yWzJkQp3vqxaiFKW9ozR1ZOmp2DeNktNBAXCuTB0 MIME-Version: 1.0 X-Received: by 10.66.65.203 with SMTP id z11mr3705625pas.152.1416251385096; Mon, 17 Nov 2014 11:09:45 -0800 (PST) Received: by 10.66.194.13 with HTTP; Mon, 17 Nov 2014 11:09:45 -0800 (PST) X-Originating-IP: [192.149.252.11] Date: Mon, 17 Nov 2014 09:09:45 -1000 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/sv_xznxmc48FQs81VXP4W1Si8z8 Subject: [urn] Focus on 2141bis X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 19:09:52 -0000 All, Now that we have a single draft to drive our working group direction, I'd like everybody to focus on it: http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-08 If you specific questions or issues/comments on the text of that document, please post them to this list. If there is specific wording you would like to see changed, please submit your changes in the form of OLD Ipsum lorum latin borem... NEW Spiffy new text... -andy, co-chair From nobody Mon Nov 17 11:13:34 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C2F1A895A for ; Mon, 17 Nov 2014 11:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_aRodxxTzLf for ; Mon, 17 Nov 2014 11:13:17 -0800 (PST) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AF61A893F for ; Mon, 17 Nov 2014 11:13:16 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id fp1so4394516pdb.14 for ; Mon, 17 Nov 2014 11:13:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=bHvKhLYwouGWVTSgdnLlK4cIzz4NpGkdPEX0tKP/bzQ=; b=eF64JTqSTc0e2AJWNxgq9pC8Czh/EsMTkYycX/wIgFoGdoyLEeLlF7aSbsL0Z5azyx rhN+cd/kYt9BX2ZMOnLICSEwTOITxYoMMjm5tPMT1dDLY9/hGxuhR0f6XnedpOby+HSF wvQS2LbDdDMiwoUZa8tEm0HvdkiAILy8TxJcl/EDLI8oahGFP26Il6ralbFZRAfF3hjp 3iqBsrX9xt1DgkmyHmjgzBESUc8KgN7wjiov8dr54qC307O9c8IuXJwu/vATQFnWdTau b5FAIlayl9CQswJWZFUe8YRP71M+nKeGfoZDEawC+DXcijnt6YMDe/BlmjlCjSL8m+17 PJuQ== X-Gm-Message-State: ALoCoQnTrTUb7akbYoxPBwpvW79U2DrOT9znRnSuINvQn4qWNju0SSw8s/dm/CVaVkTV8JaRfd9B MIME-Version: 1.0 X-Received: by 10.68.68.227 with SMTP id z3mr10539744pbt.3.1416251596112; Mon, 17 Nov 2014 11:13:16 -0800 (PST) Received: by 10.66.194.13 with HTTP; Mon, 17 Nov 2014 11:13:16 -0800 (PST) X-Originating-IP: [192.149.252.11] Date: Mon, 17 Nov 2014 09:13:16 -1000 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/VH5ufpyNrth6VevfmXSOxQHCxIM Subject: [urn] 2141bis Section 7.1 question X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 19:13:27 -0000 In 2141bis Section 7.1, the fourth bullet reads like this: 4. The scope of the namespace (public vs. private, global vs. local to a particular organization, nation, or industry). For example, a namespace claiming to deal in "national identification numbers" ought to have a global scope and address all identity number structures, whereas a URN scheme for a particular national identification number system would need to handle only the structure for that nation's identity numbers. The example is driving me crazy at it seems to be using the same situation but suggesting two different outcomes. Am I just not reading that correctly? -andy From nobody Mon Nov 17 11:16:34 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2491A8940 for ; Mon, 17 Nov 2014 11:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FX-RQY5LZcB for ; Mon, 17 Nov 2014 11:16:32 -0800 (PST) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2347A1A8968 for ; Mon, 17 Nov 2014 11:16:23 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id eu11so2004078pac.39 for ; Mon, 17 Nov 2014 11:16:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=cm174AKWJzVPlgE2hSnBFLW0/nRgrkkgcVqnP5WKJfA=; b=DNbXM6Mj7oQfEb6EcANivX4WKSMtF8koFqAszGUIBprmRsjdPzFcPHxLNMfK0wwZ7n nrEG0uCb19GV8IkivkBgvFwWeOfBzhBPq0pbwDWw9E8/C+fSci2kMP8Cbp5HwdEzLumx mdSWCVi47g2MqYATamCewzTvV7arLmLtNt6Ja1hm52T7Oes+A54wa8SIk+VudRnsGGJ9 hB8U5RUGib05TxLCzAO7095/MqSjUP5/W7c5HkIvzlytI4HKuA5fZRG9aKtkbO5SjTfd J14c8/Fx23C26Tbl1uyNRRgYjlZe4avWSYf3YYbrecy8bZwdpxAirMgBryqSAYQSWSJB b3Wg== X-Gm-Message-State: ALoCoQnqXqfj5UVVkb5OzAHJZitv5eWLEdl+mhmX9gIp3b3K3HOSOLmAqnhE0MbV5qEaMCriK3Ua MIME-Version: 1.0 X-Received: by 10.68.68.227 with SMTP id z3mr10557683pbt.3.1416251782821; Mon, 17 Nov 2014 11:16:22 -0800 (PST) Received: by 10.66.194.13 with HTTP; Mon, 17 Nov 2014 11:16:22 -0800 (PST) X-Originating-IP: [192.149.252.11] Date: Mon, 17 Nov 2014 09:16:22 -1000 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/XjmHkp12XErhXLXAZ5SVfqm2MYE Subject: [urn] 2141bis Section 6 Conformance consensus X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 19:16:33 -0000 All, Since there was a great deal of discussion around URI conformance and specifically the relative resolution process, I'd like to ask the group if they have any issues with Section 6 of 2141bis. So, have you read the draft, in particular section 6? And if so, do you have any changes you'd like to see to the text? If so, why? -andy, co-chair From nobody Mon Nov 17 11:25:21 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAF51A8A46 for ; Mon, 17 Nov 2014 11:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTrQ7kWRjWAK for ; Mon, 17 Nov 2014 11:25:18 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BAA51A8A42 for ; Mon, 17 Nov 2014 11:25:14 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so22781579pab.18 for ; Mon, 17 Nov 2014 11:25:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=/X0NIu3IImrc7VvgEYYFac1YTS74Xv6r42GLFtYlPno=; b=VArqXr9/EIvWJilaxjOSLjG3+hMfgcFbFeivGig0sWQDSmZElJdQ3LKG/wj48bqTHP zkiwC1w5+SE3ys3h8/Ts2ntvLWmRnkILJk39zKnr5Up/xXz78iZLe7Y64hKTlHlY6q9q 7+UbaUdK8IUxi+nHBHs/X759LMGyvbdsp6xwDJV0jV2AeKEKaRHN8uGd6dPhHA4DU89b Cg7HPmHfXKwndb0N1lsNGsBtBs6AsXmMwIJbnORy8NfWPmY77klj91K1jtqREsOZeSA3 FXZ8ReAx+N93hyzvKcfDLW2iF2ZC+KRosg3sOGCst8TmfsMF5O+S+pqB+nbvt+5BCjLS KObg== X-Gm-Message-State: ALoCoQmrxkqJU7zOvDdf4yhtplfBxID46alqxElPDgzheBIHAd54YaO16TIfwZ5WNwr0EbuKg71w MIME-Version: 1.0 X-Received: by 10.70.43.78 with SMTP id u14mr3763301pdl.166.1416252314101; Mon, 17 Nov 2014 11:25:14 -0800 (PST) Received: by 10.66.194.13 with HTTP; Mon, 17 Nov 2014 11:25:14 -0800 (PST) X-Originating-IP: [192.149.252.11] Date: Mon, 17 Nov 2014 09:25:14 -1000 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/rUt1cKNxNL-EkFA-M_WSzxKXsD8 Subject: [urn] 2141bis section 3.3 per NID and future specification consensus X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 19:25:20 -0000 All, Section 3.3 of 2141bis states that p-components, q-components, and f-components are to be defined further by future specifications and NID registrations. Given that there was discussion regarding per-NID vs. all-URNs definitions, are there any questions and/or objections to the language in section 3.3? -andy, co-chair From nobody Mon Nov 17 11:28:28 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414DE1A8A65 for ; Mon, 17 Nov 2014 11:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htWRyNYWIICD for ; Mon, 17 Nov 2014 11:28:25 -0800 (PST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996441A8A5E for ; Mon, 17 Nov 2014 11:28:23 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so839587pdb.32 for ; Mon, 17 Nov 2014 11:28:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=L2Lo583cboAV1G2JsODAI1M77AI0XyztVPFpCVuHBRc=; b=HlKZ7mZRKQte3S9PLo0aotPMg5fImwDEn8rxbWJQ3Detkw9MJ3a/NtQbQxuOI+Ux6Y i9/hlAM83nkfgyeokenFexAYWQLJThHEKvc+lJUck0C9vLIu8h0bCnlWNXv0v+AeC0mL P9p83XqMIrzOgs0IbpAukJ77V7w5BlqRhR2v28IfBRkKNt42aPCH6dfB/NtD48ELNDk1 6Oncv0vAIEGFiai4DLLXuknhZ5+1m9ZuuLnG6IVy8nRZ4oFuf9aRZdG9F+iT0Qcg3X2n 7wZPvbmGkOW98jRtk4ObfIzv/nQz2Ux33yNOWNx80gHmpq3xqUGkCFIU6aMQIzLEfGyf /7ZA== X-Gm-Message-State: ALoCoQlRr9vj66g1rxdpwPV2f5UBt59PEOYmW2zm9rJUOiK0/SeH+G7m1LC3hBEaEEtGH/gG+cbH MIME-Version: 1.0 X-Received: by 10.66.182.130 with SMTP id ee2mr32011768pac.22.1416252503346; Mon, 17 Nov 2014 11:28:23 -0800 (PST) Received: by 10.66.194.13 with HTTP; Mon, 17 Nov 2014 11:28:23 -0800 (PST) X-Originating-IP: [192.149.252.11] Date: Mon, 17 Nov 2014 09:28:23 -1000 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/dETf31WfijQiWnFnqMAKlsImxD4 Subject: [urn] 2141bis equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 19:28:27 -0000 All, I'm inviting feedback on the equivalence rules of section 3.3 and section 4 of 2141bis. It states that p-components are to be used for equivalence testing where as q- and f- components are not. Additionally, the NSS may also have separate rules per NID with regards to equivalency. Are there any questions, comments, or objections to these rules? If so, why? -andy, co-chair From nobody Mon Nov 17 11:28:58 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727361A8A65 for ; Mon, 17 Nov 2014 11:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihsCPZHJBcFs for ; Mon, 17 Nov 2014 11:28:54 -0800 (PST) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B999B1A8A68 for ; Mon, 17 Nov 2014 11:28:54 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id y10so2423340pdj.7 for ; Mon, 17 Nov 2014 11:28:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=giZzNLRMyDAck6N7NbvjGCXYchml8Zcce2HQoK/IRcQ=; b=HYpTuxPmcd6/CGdXGdtxApEfBGuoKgwh/Ll/JKlVNhfzcLiUMqXjd6kvyxZIubdbGh 9/rrxZsUV1HoambGbvLjfxp+4iclmF+NU1F+Q42wTsqpk8n6npb7ykTflOQ419WhDmKj LK55gicW0E0Lq4u9pVarWkx015eLf4aQUks5Fzd01kfAnzSla1CCUnS4gxIJ6q8ReTCh oCP0WG7SV3CX2G66+Rjv705Emm0SORKwfrHGzhEt8cr2fl3+3ZJ0+Vnv4dInpnHsu8Mp +Rn9MlnCsWCLo/wPR7UQ8eUgfCFEXN6kHoly39tOzjCRBuOwf7vd0CqGg1d/8mXhug4N EvPA== X-Gm-Message-State: ALoCoQl2JKeRdMF3Kcp8ZkMYBj+lZDd5GUcyQ1RE1qBZbrkaoBizwVICIsokqMKqtjnm3z8eMv0b MIME-Version: 1.0 X-Received: by 10.66.65.233 with SMTP id a9mr31273120pat.107.1416252534392; Mon, 17 Nov 2014 11:28:54 -0800 (PST) Received: by 10.66.194.13 with HTTP; Mon, 17 Nov 2014 11:28:54 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: References: Date: Mon, 17 Nov 2014 09:28:54 -1000 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/iioNANDl0xhyAwSt759Ak-VQJ1c Subject: Re: [urn] Focus on 2141bis X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 19:28:56 -0000 And I forgot, please start a separate thread for each issue. On Mon, Nov 17, 2014 at 9:09 AM, Andrew Newton wrote: > All, > > Now that we have a single draft to drive our working group direction, > I'd like everybody to focus on it: > > http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-08 > > If you specific questions or issues/comments on the text of that > document, please post them to this list. > > If there is specific wording you would like to see changed, please > submit your changes in the form of > > OLD > > Ipsum lorum latin borem... > > NEW > > Spiffy new text... > > -andy, > co-chair From nobody Mon Nov 17 21:39:40 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113B61AD0CF for ; Mon, 17 Nov 2014 21:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-qzHVVINu01 for ; Mon, 17 Nov 2014 21:39:36 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0068F1AD0CE for ; Mon, 17 Nov 2014 21:39:34 -0800 (PST) Received: from [172.17.4.127] (hupnet-fw.fe.helsinki.fi [128.214.173.46]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id sAI5dd44003931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Nov 2014 07:39:39 +0200 Message-ID: <546ADB93.6010502@helsinki.fi> Date: Tue, 18 Nov 2014 07:39:31 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/-1RITMHYyqifmAzt20ISLx8LIdQ Subject: Re: [urn] 2141bis Section 7.1 question X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 05:39:39 -0000 Hello, Comments and suggested new text below. On 17.11.2014 21:13, Andrew Newton wrote: > In 2141bis Section 7.1, the fourth bullet reads like this: > > 4. The scope of the namespace (public vs. private, global vs. local > to a particular organization, nation, or industry). For example, > a namespace claiming to deal in "national identification numbers" > ought to have a global scope and address all identity number > structures, whereas a URN scheme for a particular national > identification number system would need to handle only the > structure for that nation's identity numbers. > > The example is driving me crazy at it seems to be using the same > situation but suggesting two different outcomes. Am I just not reading > that correctly? The difference between "all national identification numbers" and "a particular national identification number" is somewhat subtle, and the example itself perhaps not an ideal one since a single namespace for all national identification numbers is unlikely. The point could be driven home in another way. IMO it might be better to use an existing URN namespace or at least an existing identifier. 4. The scope of the namespace (public vs. private, global vs. local to a particular organization, nation, or industry). For example, a namespace based on an international standard such as ISBN ought to have a global scope and address all ISBNs no matter where they have been assigned, whereas a URN scheme for a particular publisher's product numbering system would need to handle only the structure for that publisher's product identifier. Instead of ISBN it is possible to use as examples ISNI (International Standard Name Identifier) and ResearcherID (http://www.researcherid.com/), which is a publisher driven ID for researchers. Juha > > -andy > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Mon Nov 17 22:17:07 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371971A0102 for ; Mon, 17 Nov 2014 22:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcY3qjeKT5h5 for ; Mon, 17 Nov 2014 22:17:03 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE72D1A0079 for ; Mon, 17 Nov 2014 22:17:02 -0800 (PST) Received: from [172.17.4.127] (hupnet-fw.fe.helsinki.fi [128.214.173.46]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id sAI6H7fD018155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Nov 2014 08:17:08 +0200 Message-ID: <546AE45B.1040901@helsinki.fi> Date: Tue, 18 Nov 2014 08:16:59 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FtDSdVxCHTP1z7r4Y0I3eagtsro Subject: Re: [urn] 2141bis equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 06:17:05 -0000 Hello, A few comments. In 4.1, instead of saying: > URN namespaces MAY define additional rules for equivalence, such as > case-insensitivity of the NSS (or parts thereof). we might provide a stricter formulation like this: If required by the syntax and semantics of the identifier, a URN namespace MUST define additional rules for equivalence, such as case-insensitivity of the NSS (or parts thereof), or listing of characters which should be ignored when equivalence is determined (like hyphens in ISBN strings). There should be step 5 in the determination of equivalence: 5. namespace specific rules for equivalence, if any Some namespaces provide means (check sums) which may be used for determining if the identifier string is valid or not. Checking the NSS validity should be included in the equivalence analysis if possible. In 4.2, examples with f-, q- and p-components could be useful. Juha On 17.11.2014 21:28, Andrew Newton wrote: > All, > > I'm inviting feedback on the equivalence rules of section 3.3 and > section 4 of 2141bis. It states that p-components are to be used for > equivalence testing where as q- and f- components are not. > Additionally, the NSS may also have separate rules per NID with > regards to equivalency. Are there any questions, comments, or > objections to these rules? If so, why? > > -andy, > co-chair > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Mon Nov 17 23:22:12 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F301AD33B for ; Mon, 17 Nov 2014 23:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTTvYWeahIT4 for ; Mon, 17 Nov 2014 23:22:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C201A1A23 for ; Mon, 17 Nov 2014 23:22:08 -0800 (PST) Received: from [192.168.2.160] ([84.187.33.211]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LyEJp-1Y4wuH0mkH-015VgX; Tue, 18 Nov 2014 08:22:04 +0100 Message-ID: <546AF38B.40306@gmx.de> Date: Tue, 18 Nov 2014 08:21:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andrew Newton , "urn@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KPWxDuXGmFuo8Uv1EKY3FueE9q4R2ypBILP2rlku5rkQF5lxYvF djdiiliEIhZ5guL2dal4mYWSHCyhNeyFJad+Vv6y7MPBTJ0v8vSADbQt6FN0ratOi/zbD0a GEIdtbWsLlmVy/zIyboxunIp21fDTsof8frYKe2oa6q0tOhn9KAFgB3Caq1h5zJoXGf0iv3 wZtoNYt3eLgYT1DT22G4Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/YGLgWOtvE_dFwjBZ9vo0uN-69PQ Subject: Re: [urn] 2141bis Section 6 Conformance consensus X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 07:22:10 -0000 On 2014-11-17 20:16, Andrew Newton wrote: > All, > > Since there was a great deal of discussion around URI conformance and > specifically the relative resolution process, I'd like to ask the > group if they have any issues with Section 6 of 2141bis. So, have you > read the draft, in particular section 6? And if so, do you have any > changes you'd like to see to the text? If so, why? > > -andy, > co-chair Is this a question about ? In which case: > 5. URI Conformance > > > Because a URN is, syntactically, a URI under the "urn" scheme, in > theory a URN can be placed in any protocol slot that allows for a URI > (e.g., an XML namespace name [XML-NAMES]). However, this does not > imply that, semantically, it makes sense in practice to place a URN maybe s/makes sense/always makes sense/ > in a given URI protocol slot; in particular, because a URN does not > specify the location of a resource, it is not appropriate to place a > URN in a URI protocol slot that points to a resource (examples > include the 'href' and 'src' attributes and the element in > HTML, as well as the 'xml:base' attribute in XML [XML-BASE]). It's not clear to me why it would be wrong to use a URN in a/@href. > Despite the fact that URNs are not hierarchical and are not > appropriate for use as a base URI (see Section 5.1 of [RFC3986]), the > relative resolution algorithm specified in Section 5.2 of [RFC3986] > still applies to the "urn" URI scheme; implementers need to be aware, > however, that running the algorithm against URNs can lead to results > that are unexpected or not useful. +1 > ... Best regards, Julian From nobody Tue Nov 18 01:28:44 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE151A0155 for ; Tue, 18 Nov 2014 01:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Koch07jf2ei5 for ; Tue, 18 Nov 2014 01:28:40 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 014C91A012D for ; Tue, 18 Nov 2014 01:28:39 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 1207232E0B2; Tue, 18 Nov 2014 18:27:54 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 6d35_966d_6865719c_9e2c_4e84_9efe_92a335ec8d8b; Tue, 18 Nov 2014 18:27:53 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 34FD3BF8FE; Tue, 18 Nov 2014 18:27:53 +0900 (JST) Message-ID: <546B1118.4070404@it.aoyama.ac.jp> Date: Tue, 18 Nov 2014 18:27:52 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <546AE45B.1040901@helsinki.fi> In-Reply-To: <546AE45B.1040901@helsinki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/i20d6HfkAVKhcbvXq8kz40cwMjc Subject: Re: [urn] 2141bis equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 09:28:42 -0000 Hello Juha, others, On 2014/11/18 15:16, Juha Hakala wrote: > Hello, > > A few comments. > > In 4.1, instead of saying: >> URN namespaces MAY define additional rules for equivalence, such as >> case-insensitivity of the NSS (or parts thereof). > we might provide a stricter formulation like this: > > If required by the syntax and semantics of the identifier, a URN > namespace MUST > define additional rules for equivalence, such as > case-insensitivity of the NSS (or parts thereof), or listing of > characters which > should be ignored when equivalence is determined (like hyphens in ISBN > strings). The alternative would be to define the syntax of an NSS so that such equivalences are eliminated by definition. For ISBNs, this could e.g. be done by just disallowing the hyphens, or in general defining that the NSS is all lower-case instead of requiring case-insensitivity. I think we should at least leave this choice to the creators of URN namespaces, and we should probably recommend to eliminate equivalences by restricting syntax rather than mandate that each scheme MUST define equivalences. > There should be step 5 in the determination of equivalence: > > 5. namespace specific rules for equivalence, if any This would exclude implementations that know about URNs in general, but not about (all) specific URN namespaces. Creating an implementation that knows about all specific URN namespaces is very difficult, if not to say impossible: New namespaces get defined, and the equivalences are defined in prose, not in an executable way. > Some namespaces provide means (check sums) which may be used for > determining if the identifier string is valid or not. > > Checking the NSS validity should be included in the equivalence analysis > if possible. How exactly should this work? We can distinguish three cases. Comparing valid URNs with valid ones, valid ones with invalid ones, and invalid ones with invalid ones. As for comparing valid URNs among themselves, checking for invalidity shouldn't affect the result. When comparing a valid and an invalid URN, I'd assume that they would turn out to be non-equivalent without needing to check for validity, which would be the result I'd expect anyway. Or would you want that they turn out to be equivalent if one of them e.g. just has a wrong checksum, but is otherwise the same? That would leave two non-equivalent identifiers. Comparing two identical but non-equivalent identifiers will result in them being judged equivalent even without validity checks. That's just GIGO (garbage in, garbage out) and shouldn't concern us too much. Given the above considerations, my guess would be that we can live very well without involving validity checks in equivalence analysis. But maybe if you can explain how you thought it should work, that might help. Regards, Martin. > In 4.2, examples with f-, q- and p-components could be useful. > > Juha > > On 17.11.2014 21:28, Andrew Newton wrote: >> All, >> >> I'm inviting feedback on the equivalence rules of section 3.3 and >> section 4 of 2141bis. It states that p-components are to be used for >> equivalence testing where as q- and f- components are not. >> Additionally, the NSS may also have separate rules per NID with >> regards to equivalency. Are there any questions, comments, or >> objections to these rules? If so, why? >> >> -andy, >> co-chair >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Tue Nov 18 03:15:08 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ACE1A01FA for ; Tue, 18 Nov 2014 03:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.295 X-Spam-Level: X-Spam-Status: No, score=-3.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwl-UWCDJucP for ; Tue, 18 Nov 2014 03:15:01 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467BE1A01F0 for ; Tue, 18 Nov 2014 03:14:59 -0800 (PST) Received: from [192.168.11.203] (guest.minedu.fi [193.167.10.69]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id sAIBF3ud015711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Nov 2014 13:15:04 +0200 Message-ID: <546B2A2F.8090809@helsinki.fi> Date: Tue, 18 Nov 2014 13:14:55 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , urn@ietf.org References: <546AE45B.1040901@helsinki.fi> <546B1118.4070404@it.aoyama.ac.jp> In-Reply-To: <546B1118.4070404@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bIGcHA4zZIVSOISW_pw2NRgg2bA Subject: Re: [urn] 2141bis equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 11:15:06 -0000 Hello Martin, On 18.11.2014 11:27, "Martin J. Dürst" wrote: > Hello Juha, others, > > > The alternative would be to define the syntax of an NSS so that such > equivalences are eliminated by definition. For ISBNs, this could e.g. > be done by just disallowing the hyphens, or in general defining that > the NSS is all lower-case instead of requiring case-insensitivity. The current ISBN namespace registration allows the use of hyphens, and there are a lot of URN:ISBNs out there which already have them. Disallowing hyphens in a revised registration request would cause problems for current implementers. ISBNs are commonly expressed both with and without hyphens. URN system has to accommodate that, and that can be done by creating namespace specific rules for lexical equivalence which says that hyphens must be ignored. In the case of ISBN, the main challenge in determination of lexical equivalence is that publishers, when reprinting a book (which does not require a new ISBN), often replace ISBN-10 with lexically equivalent ISBN-13. > > I think we should at least leave this choice to the creators of URN > namespaces, and we should probably recommend to eliminate equivalences > by restricting syntax rather than mandate that each scheme MUST define > equivalences. IMO the best approach is the one that creates the smallest amount of turbulence. In the ISBN case it is the one which allows two ways of expressing ISBN strings (with or without hyphens). > >> There should be step 5 in the determination of equivalence: >> >> 5. namespace specific rules for equivalence, if any > > This would exclude implementations that know about URNs in general, > but not about (all) specific URN namespaces. Creating an > implementation that knows about all specific URN namespaces is very > difficult, if not to say impossible: New namespaces get defined, and > the equivalences are defined in prose, not in an executable way. It is unlikely that any application out there needs to deal with all URN namespaces with this level of specificity. A library system must know how to deal with URN:ISBNs and other bibliographic identifiers, but that is trivial since these applications already know how to deal with ISBNs etc. Even new URN namespaces will often be based on established identifiers, so there will be applications which are able to process these identifiers. Usually it is not difficult to determine equivalence especially in the URN context where the identifier strings are not heavily modified. With other persistent identifiers things may not be as straightforward - for instance, DOI system requires non-trivial changes to be made to the ISBN strings. > > >> Some namespaces provide means (check sums) which may be used for >> determining if the identifier string is valid or not. >> >> Checking the NSS validity should be included in the equivalence analysis >> if possible. > > How exactly should this work? > > We can distinguish three cases. Comparing valid URNs with valid ones, > valid ones with invalid ones, and invalid ones with invalid ones. The case I had in mind is the comparison between the valid (corrected) and invalid (original) ISBNs. Library metadata usually incorporates both variants. It is important to show that they are equivalent (identify the same resource) since both versions of the URN:ISBN may be actionable in the Web. For instance, the publisher may prefer to use the invalid identifier and libraries the correct one. > > As for comparing valid URNs among themselves, checking for invalidity > shouldn't affect the result. Yes. > > When comparing a valid and an invalid URN, I'd assume that they would > turn out to be non-equivalent without needing to check for validity, > which would be the result I'd expect anyway. Or would you want that > they turn out to be equivalent if one of them e.g. just has a wrong > checksum, but is otherwise the same? If the only difference is that one identifier has a wrong check sum and another the correct one, we may assume that the two are in fact equivalent and there is just a typo or miscalculated check sum in another one. If there are other differences between valid and invalid identifier, they cannot be regarded to be lexically equivalent. Library system would be aware of both ISBN versions since they are always included in the metadata describing the resource, tagged in appropriate way. Providing both (all) ISBN alternatives is important since both URN:ISBNs may be actionable, for instance the invalid one in the publisher's system and the valid one in the national library's repository. > > That would leave two non-equivalent identifiers. Comparing two > identical but non-equivalent identifiers will result in them being > judged equivalent even without validity checks. That's just GIGO > (garbage in, garbage out) and shouldn't concern us too much. Yes. > > Given the above considerations, my guess would be that we can live > very well without involving validity checks in equivalence analysis. > But maybe if you can explain how you thought it should work, that > might help. This is not a question of life and death for me :-). It is also possible to determine (using the namespace specific rules) if the NSS is valid, and - if it is not - cancel the rest of the lexical equivalence checking process because the result would not be reliable. I'm afraid this is unavoidable if there is no way of knowing / making an educated guess what the correct NSS would have been. All the best, Juha > > Regards, Martin. > > >> In 4.2, examples with f-, q- and p-components could be useful. >> >> Juha >> >> On 17.11.2014 21:28, Andrew Newton wrote: >>> All, >>> >>> I'm inviting feedback on the equivalence rules of section 3.3 and >>> section 4 of 2141bis. It states that p-components are to be used for >>> equivalence testing where as q- and f- components are not. >>> Additionally, the NSS may also have separate rules per NID with >>> regards to equivalency. Are there any questions, comments, or >>> objections to these rules? If so, why? >>> >>> -andy, >>> co-chair >>> >>> _______________________________________________ >>> urn mailing list >>> urn@ietf.org >>> https://www.ietf.org/mailman/listinfo/urn >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn >> From nobody Tue Nov 18 05:40:32 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5FF1A03E1 for ; Tue, 18 Nov 2014 05:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziQm1ym3X6Zr for ; Tue, 18 Nov 2014 05:40:25 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAE91A03D0 for ; Tue, 18 Nov 2014 05:40:25 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lj1so375737pab.5 for ; Tue, 18 Nov 2014 05:40:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uktHIwOJ7PoAUhLFXknLtee2jxPEytbx2QTaqLRM4ag=; b=fg5LzlGfRheAnf9oKnFLpWxGK8X+W83HfpfivO945kTLTpCY9LnstnNW4v5lG7odC3 NMaVRgsRPKwBPdW1lHLphoLCHD0JRW2FDmcT++iiycF60zKbhJip6gXqfhRTburczgzr GBk4xgDxEBbZycnIagtoi/Mjv+Ywr9XiFpUnRVmqc9aKEvV8O9l+T1hYovBzczQ4HL7Q pBNI7wdZz7HEwdz0mufnZUNumuCSExeCM7Kx3KX4Da/km2ak3+11mXYYnM6Kz8dcXwod ysKRZpAKJi37Cc3bMfpQEZnzSWMIo5g/zQ8YUndu9c2QrSz96FJPEPczxIvhQsuIoLhG BFXw== X-Gm-Message-State: ALoCoQluOA1mQv8ejW/KxX/WmIpLVej7GQId37ytrZnk7X7V3LLvR2fLPt/idpSWYV6AyFAiRLe8 MIME-Version: 1.0 X-Received: by 10.68.68.227 with SMTP id z3mr15945240pbt.3.1416318024634; Tue, 18 Nov 2014 05:40:24 -0800 (PST) Received: by 10.66.194.13 with HTTP; Tue, 18 Nov 2014 05:40:24 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: <546AF38B.40306@gmx.de> References: <546AF38B.40306@gmx.de> Date: Tue, 18 Nov 2014 08:40:24 -0500 Message-ID: From: Andrew Newton To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/C9JmBTv4XWu2U_Flqn3YZl6kBt8 Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis Section 6 Conformance consensus X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 13:40:30 -0000 On Tue, Nov 18, 2014 at 2:21 AM, Julian Reschke wrote: > Is this a question about > ? Yes, section 6. Sorry for the confusion. -andy From nobody Tue Nov 18 05:46:18 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518D61A039F for ; Tue, 18 Nov 2014 05:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0xfKovUOSOW for ; Tue, 18 Nov 2014 05:46:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F411A039D for ; Tue, 18 Nov 2014 05:46:14 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LxgHz-1Y10tE3wbr-017EAj; Tue, 18 Nov 2014 14:46:12 +0100 Message-ID: <546B4DA2.2050609@gmx.de> Date: Tue, 18 Nov 2014 14:46:10 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andrew Newton References: <546AF38B.40306@gmx.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:84JA0iCm161oIm1Dd/sX2v+4IoSjLJXLY8XraY6t5QdgDvp7SgI JL9/FWS6Bqp4kipdPBxC+r/UkTqB/uanMG7aIaFa9dN6U0yz40FvuCQPzjlYw2fc199m1QI Q3laiCqvtl2wmwmXCLMec6pBeeu5f/FvipFs5y/rkJ36rG9mrAl9iwPd88FNteF0GbrfmL4 rEncU1tJzUY0+pPoqA/4Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/urn/CFsB_AAjB55dEzJ9EOqnznXBWcc Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis Section 6 Conformance consensus X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 13:46:16 -0000 On 2014-11-18 14:40, Andrew Newton wrote: > On Tue, Nov 18, 2014 at 2:21 AM, Julian Reschke wrote: >> Is this a question about >> ? > > > Yes, section 6. Sorry for the confusion. > > -andy Five :-) From nobody Tue Nov 18 05:50:24 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69171A0451 for ; Tue, 18 Nov 2014 05:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdH6X8RZfZ2p for ; Tue, 18 Nov 2014 05:50:15 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BB71A040B for ; Tue, 18 Nov 2014 05:50:15 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lj1so399012pab.4 for ; Tue, 18 Nov 2014 05:50:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ds5W2wd0n3u56QYxtYiV3vZiUHH6S205FVI2qNSuE9Y=; b=D9wEntV0RYCQQDs7I9dt8t4FAQiaSJx5ncOTDBQZYtpA2q/7Kre49poLg73tDFpxAb BO9ubSH479E67Nqs0eJ1ljQfpdmhtBk9bFqRi1ksLBBLGGMo8Y/l8+JKWtGhuWqSSm6d d7hdISbP+ImKzwExN3j+TF8fOd2DlmUATQltGnkZJU4HGq176N88DpMyc3jYWx9CHX81 wgypxYocyC5/Eorb3ko6MO0MgmbDk4Fk/Hsqv36dJlEolGhK7a9yFTmX/M56Mh3RBJyR BYLRcHJjsR+muWCWe6nyjyb/4SecLpu5eO8nL41CE91Mc/ci5lDfRpq/xMWnfRtBk+lF APcA== X-Gm-Message-State: ALoCoQmwNpIxVYJpsB7zkz04lPN/CN9jr9JnOhfDVhpX3OZ/khKzPBwoNLp0G7CqTq0qn+33046v MIME-Version: 1.0 X-Received: by 10.66.235.135 with SMTP id um7mr37263874pac.94.1416318614828; Tue, 18 Nov 2014 05:50:14 -0800 (PST) Received: by 10.66.194.13 with HTTP; Tue, 18 Nov 2014 05:50:14 -0800 (PST) X-Originating-IP: [2001:500:4:15:1033:9475:400:6319] In-Reply-To: <546B1118.4070404@it.aoyama.ac.jp> References: <546AE45B.1040901@helsinki.fi> <546B1118.4070404@it.aoyama.ac.jp> Date: Tue, 18 Nov 2014 08:50:14 -0500 Message-ID: From: Andrew Newton To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/LpbqHw_jDFxjMzNubblDvcy1Eu0 Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 13:50:19 -0000 On Tue, Nov 18, 2014 at 4:27 AM, "Martin J. D=C3=BCrst" wrote: > The alternative would be to define the syntax of an NSS so that such > equivalences are eliminated by definition. For ISBNs, this could e.g. be > done by just disallowing the hyphens, or in general defining that the NSS= is > all lower-case instead of requiring case-insensitivity. > > I think we should at least leave this choice to the creators of URN > namespaces, and we should probably recommend to eliminate equivalences by > restricting syntax rather than mandate that each scheme MUST define > equivalences. Wouldn't this have backwards compatibility issues? > >> There should be step 5 in the determination of equivalence: >> >> 5. namespace specific rules for equivalence, if any > > > This would exclude implementations that know about URNs in general, but n= ot > about (all) specific URN namespaces. Creating an implementation that know= s > about all specific URN namespaces is very difficult, if not to say > impossible: New namespaces get defined, and the equivalences are defined = in > prose, not in an executable way. I agree. It seems impossible to create an implementation that is aware of all URN namespaces. Furthermore, do we care that two URNs from two different namespaces are equivalent? They may resolve to the same location, but they are two different names. So they aren't equivalent, right? -andy From nobody Tue Nov 18 05:50:53 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FDF1A03F9 for ; Tue, 18 Nov 2014 05:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXzCtC0KQan0 for ; Tue, 18 Nov 2014 05:50:47 -0800 (PST) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF12A1A03B3 for ; Tue, 18 Nov 2014 05:50:47 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id z10so6127164pdj.40 for ; Tue, 18 Nov 2014 05:50:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6ewoHTzIsCY0En6BnGimZb3nBgT3gPalZRT/mYYt6XE=; b=mgrxfr4PpkvTnemFTWuwE0ZaJNgt2zn8VQhDUHb0c0OmcGaM9ydhRS+AuykgUN0maG ilWOuMUaQbIv7JdxhDLJqc841tLUywND0u+1W8Wql0VeE92tvzE8mdLgfz8Smqd4Bdxe CNlCp08ECbFeU5k+TZ1ZIMdLq8Ue+68BRw0oSK5OZn9/hSxdGp7xr9eU6Lv4+Q1lkzj4 D1a2u5YVZ1MI4zORGlkDs4/oe9x9+sU7TMj0vwjsPMrZMXmeVzw8lIZi7gyCMWmjrvaj Nahu1xtdthLO+RU/Y1nJoNkaKMOBPWQ4duqQeW4YuCZgPV5K8Hah53R/9QYaXAdp0nqP 3/Kg== X-Gm-Message-State: ALoCoQnDMHef2lJcuq4h7DW562DEyGuj3R37wtLY/ZqOpiX4QxtsPf30c5B3vdXVzOqaoSd3313I MIME-Version: 1.0 X-Received: by 10.70.44.208 with SMTP id g16mr11915108pdm.130.1416318647512; Tue, 18 Nov 2014 05:50:47 -0800 (PST) Received: by 10.66.194.13 with HTTP; Tue, 18 Nov 2014 05:50:47 -0800 (PST) X-Originating-IP: [2001:500:4:15:1033:9475:400:6319] In-Reply-To: <546B4DA2.2050609@gmx.de> References: <546AF38B.40306@gmx.de> <546B4DA2.2050609@gmx.de> Date: Tue, 18 Nov 2014 08:50:47 -0500 Message-ID: From: Andrew Newton To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/hvcK3oDBny9RBWGhXXGH0uNKyfQ Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis Section 6 Conformance consensus X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 13:50:49 -0000 Coffee, now! On Tue, Nov 18, 2014 at 8:46 AM, Julian Reschke wrote: > On 2014-11-18 14:40, Andrew Newton wrote: >> >> On Tue, Nov 18, 2014 at 2:21 AM, Julian Reschke >> wrote: >>> >>> Is this a question about >>> >>> ? >> >> >> >> Yes, section 6. Sorry for the confusion. >> >> -andy > > > Five :-) > From nobody Wed Nov 19 02:28:31 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4819B1A1A0A for ; Wed, 19 Nov 2014 02:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJCnuJo5wsQp for ; Wed, 19 Nov 2014 02:28:27 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id BEAB91A0049 for ; Wed, 19 Nov 2014 02:28:26 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 1993132E57C; Wed, 19 Nov 2014 19:27:41 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4a68_53a5_c24caa57_ac14_4b30_865b_02833f9613a1; Wed, 19 Nov 2014 19:27:40 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 4558ABF511; Wed, 19 Nov 2014 19:27:40 +0900 (JST) Message-ID: <546C709B.8090503@it.aoyama.ac.jp> Date: Wed, 19 Nov 2014 19:27:39 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <546AE45B.1040901@helsinki.fi> <546B1118.4070404@it.aoyama.ac.jp> <546B2A2F.8090809@helsinki.fi> In-Reply-To: <546B2A2F.8090809@helsinki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/9ijQKoLmrXP-9X_2NtN6f7zfGjA Subject: Re: [urn] 2141bis equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 10:28:30 -0000 Hello Juha, On 2014/11/18 20:14, Juha Hakala wrote: > Hello Martin, > > On 18.11.2014 11:27, "Martin J. D=C3=BCrst" wrote: >> The alternative would be to define the syntax of an NSS so that such >> equivalences are eliminated by definition. For ISBNs, this could e.g. >> be done by just disallowing the hyphens, or in general defining that >> the NSS is all lower-case instead of requiring case-insensitivity. > > The current ISBN namespace registration allows the use of hyphens, and > there are a lot of URN:ISBNs out there which already have them. > Disallowing hyphens in a revised registration request would cause > problems for current implementers. > > ISBNs are commonly expressed both with and without hyphens. Of course. > URN system has to accommodate that, urn:isbn: already exists, and I definitely don't want to change its=20 definition, especially not in ways that are not backward-compatible=20 (i.e. declaring some ISBN URN that was valid before suddenly invalid). But if we take ISBNs just as an example for a future registration, then=20 I think it's a very valid idea to e.g. say that ISBNs can contain=20 hyphens, but these are removed when constructing an urn:isbn: URN. It=20 may not always be the best solution, but it would be strange to reject=20 such as solution from the get-go. > and that can be done by creating namespace > specific rules for lexical equivalence which says that hyphens must be > ignored. Yes, it can. But we should write our document so that the other choice=20 (eliminating gratuitous equivalences by restricting the permitted=20 syntax) is at least also permitted, if not preferred. > In the case of ISBN, the main challenge in determination of lexical > equivalence is that publishers, when reprinting a book (which does not > require a new ISBN), often replace ISBN-10 with lexically equivalent > ISBN-13. One solution would be to just keep urn:isbn: syntax at 10 digits. The=20 remaining 3 digits are the same all the time anyway. I'm not saying this=20 is the best solution, but it is one choice with some clear advantages. >> I think we should at least leave this choice to the creators of URN >> namespaces, and we should probably recommend to eliminate equivalences >> by restricting syntax rather than mandate that each scheme MUST define >> equivalences. > > IMO the best approach is the one that creates the smallest amount of > turbulence. In the ISBN case it is the one which allows two ways of > expressing ISBN strings (with or without hyphens). 'turbulence' is a very vague concept. In the case of ISBN URNs, my=20 interpretation of >>>> An ISBN is a ten-digit number (actually, the last digit can be the letter "X" as well, as described below) which is divided into four variable length parts usually separated by hyphens when printed. >>>> (from https://tools.ietf.org/html/rfc3187) is that hyphens are already=20 allowed at specific places, and therefore in this specific case, it's a=20 bad idea to try to backtrack and disallow them. >>> There should be step 5 in the determination of equivalence: >>> >>> 5. namespace specific rules for equivalence, if any >> >> This would exclude implementations that know about URNs in general, >> but not about (all) specific URN namespaces. Creating an >> implementation that knows about all specific URN namespaces is very >> difficult, if not to say impossible: New namespaces get defined, and >> the equivalences are defined in prose, not in an executable way. > > It is unlikely that any application out there needs to deal with all UR= N > namespaces with this level of specificity. A library system must know > how to deal with URN:ISBNs and other bibliographic identifiers, but tha= t > is trivial since these applications already know how to deal with ISBNs > etc. Then your above proposal of <<<< 5. namespace specific rules for equivalence, if any <<<< should be changed to something like >>>> 5. namespace specific rules for equivalence, for the (possibly empty)=20 set of namespaces that an application chooses to apply such rules >>>> The general "if any" to me at least means that any (i.e. all) rules that=20 exist should be applied. > Even new URN namespaces will often be based on established identifiers, > so there will be applications which are able to process these > identifiers. Usually it is not difficult to determine equivalence > especially in the URN context where the identifier strings are not > heavily modified. With other persistent identifiers things may not be a= s > straightforward - for instance, DOI system requires non-trivial changes > to be made to the ISBN strings. I'm not saying that any specific equivalence rules for any specific=20 namespaces are complicated. I'm saying that it's difficult to make sure=20 they are applied across the board, including new schemes. Even if an=20 application already has some equivalence rules somewhere, digging these=20 up, checking that they can be used for the URN syntax (which may be=20 different from the syntax of a bare identifier of the same kind), and so=20 on may involve quite some work. >>> Some namespaces provide means (check sums) which may be used for >>> determining if the identifier string is valid or not. >>> >>> Checking the NSS validity should be included in the equivalence analy= sis >>> if possible. >> >> How exactly should this work? >> >> We can distinguish three cases. Comparing valid URNs with valid ones, >> valid ones with invalid ones, and invalid ones with invalid ones. > > The case I had in mind is the comparison between the valid (corrected) > and invalid (original) ISBNs. Library metadata usually incorporates bot= h > variants. What do you mean by "incorporates"? My hope is that library metadata as=20 much as possible contains only valid data, and that software used for=20 inputting it checks inputs for validity. But maybe I'm having too high=20 expectations for library metadata, or I don't understand what you mean=20 by "incorporates". > It is important to show that they are equivalent (identify the > same resource) since both versions of the URN:ISBN may be actionable in > the Web. For instance, the publisher may prefer to use the invalid > identifier and libraries the correct one. I understand that mistakes happen, but why would a publisher prefer to=20 use something invalid? >> As for comparing valid URNs among themselves, checking for invalidity >> shouldn't affect the result. > > Yes. >> >> When comparing a valid and an invalid URN, I'd assume that they would >> turn out to be non-equivalent without needing to check for validity, >> which would be the result I'd expect anyway. Or would you want that >> they turn out to be equivalent if one of them e.g. just has a wrong >> checksum, but is otherwise the same? > > If the only difference is that one identifier has a wrong check sum and > another the correct one, we may assume that the two are in fact > equivalent and there is just a typo or miscalculated check sum in > another one. So if I have an ISBN of (987-)1-449-32188-9, who is going to tell me=20 what this is supposed to be, given that I have a choice of 14=20 alternatives at=20 http://www.isbn-check.de/checkisbn.pl?isbn=3D1-449-32188-9&submit=3Dtest&= lang=3Den=20 ? After all, we all know that checksums such as this one are a way to=20 catch some errors, but in no way allow us to fix the errors. In order to=20 be able to fix a single-digit error, we would need at least a two-digit=20 checksum. Or do you expect to also involve an actual book catalog, which might=20 help to reduce the choices somewhat? [Hint: If you check all the alternatives, rule out the ones that are not=20 actually assigned, and then look at the topics of the resulting books,=20 you might find out which book I referred to; it's somewhat related to=20 the topic at hand :-).] > If there are other differences between valid and invalid identifier, > they cannot be regarded to be lexically equivalent. Library system woul= d > be aware of both ISBN versions since they are always included in the > metadata describing the resource, tagged in appropriate way. Providing > both (all) ISBN alternatives is important since both URN:ISBNs may be > actionable, for instance the invalid one in the publisher's system and > the valid one in the national library's repository. >> That would leave two non-equivalent identifiers. Comparing two >> identical but non-equivalent identifiers will result in them being >> judged equivalent even without validity checks. [sorry, that should have read "Comparing two identical but non-valid=20 identifiers".] >> That's just GIGO >> (garbage in, garbage out) and shouldn't concern us too much. > > Yes. >> >> Given the above considerations, my guess would be that we can live >> very well without involving validity checks in equivalence analysis. >> But maybe if you can explain how you thought it should work, that >> might help. > > This is not a question of life and death for me :-). > > It is also possible to determine (using the namespace specific rules) i= f > the NSS is valid, and - if it is not - cancel the rest of the lexical > equivalence checking process because the result would not be reliable. > I'm afraid this is unavoidable if there is no way of knowing / making a= n > educated guess what the correct NSS would have been. My impression is that at least for ISBNs, knowing is impossible. Making=20 an educated guess may be possible for humans (see my example above), but=20 it should not be part of URNs per se. I'm not sure about others, but at=20 least in my book, the concept of permanent, carefully assigned=20 identifier and the concept of "educated guess" don't go very well togethe= r. Regards, Martin. > All the best, > > Juha >> >> Regards, Martin. >> >> >>> In 4.2, examples with f-, q- and p-components could be useful. >>> >>> Juha >>> >>> On 17.11.2014 21:28, Andrew Newton wrote: >>>> All, >>>> >>>> I'm inviting feedback on the equivalence rules of section 3.3 and >>>> section 4 of 2141bis. It states that p-components are to be used for >>>> equivalence testing where as q- and f- components are not. >>>> Additionally, the NSS may also have separate rules per NID with >>>> regards to equivalency. Are there any questions, comments, or >>>> objections to these rules? If so, why? >>>> >>>> -andy, >>>> co-chair >>>> >>>> _______________________________________________ >>>> urn mailing list >>>> urn@ietf.org >>>> https://www.ietf.org/mailman/listinfo/urn >>> >>> _______________________________________________ >>> urn mailing list >>> urn@ietf.org >>> https://www.ietf.org/mailman/listinfo/urn >>> > > From nobody Wed Nov 19 02:33:32 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0293F1A1BE7 for ; Wed, 19 Nov 2014 02:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8wXho88PbPW for ; Wed, 19 Nov 2014 02:33:29 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3161A1ACFD5 for ; Wed, 19 Nov 2014 02:33:28 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 20E1232E54E; Wed, 19 Nov 2014 19:32:44 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4a6c_b7f4_1c21acd9_367c_422a_be06_5585ee0818eb; Wed, 19 Nov 2014 19:32:43 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 34E60BF511; Wed, 19 Nov 2014 19:32:43 +0900 (JST) Message-ID: <546C71CA.2020607@it.aoyama.ac.jp> Date: Wed, 19 Nov 2014 19:32:42 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andrew Newton References: <546AE45B.1040901@helsinki.fi> <546B1118.4070404@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/9PVIYmyKKbcHMw8CHPdrH8lBp5M Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 10:33:31 -0000 On 2014/11/18 22:50, Andrew Newton wrote: > On Tue, Nov 18, 2014 at 4:27 AM, "Martin J. D=C3=BCrst" > wrote: >> The alternative would be to define the syntax of an NSS so that such >> equivalences are eliminated by definition. For ISBNs, this could e.g. = be >> done by just disallowing the hyphens, or in general defining that the = NSS is >> all lower-case instead of requiring case-insensitivity. >> >> I think we should at least leave this choice to the creators of URN >> namespaces, and we should probably recommend to eliminate equivalences= by >> restricting syntax rather than mandate that each scheme MUST define >> equivalences. > > Wouldn't this have backwards compatibility issues? I was assuming that this discussion is mostly about new namespaces. I=20 think we should make it clear that whatever we write in our document, it=20 applies to existing namespaces only as far as it doesn't make backwards=20 incompatible changes. >>> There should be step 5 in the determination of equivalence: >>> >>> 5. namespace specific rules for equivalence, if any >> >> >> This would exclude implementations that know about URNs in general, bu= t not >> about (all) specific URN namespaces. Creating an implementation that k= nows >> about all specific URN namespaces is very difficult, if not to say >> impossible: New namespaces get defined, and the equivalences are defin= ed in >> prose, not in an executable way. > > I agree. It seems impossible to create an implementation that is aware > of all URN namespaces. > > Furthermore, do we care that two URNs from two different namespaces > are equivalent? They may resolve to the same location, but they are > two different names. So they aren't equivalent, right? Yes. As identifiers, they are inherently not equivalent. I don't think=20 we need to put this in words; I think the text in section 6.1 of RFC=20 3986 should be enough. Regards, Martin. From nobody Wed Nov 19 02:35:26 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950411A014E for ; Wed, 19 Nov 2014 02:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8K8jPJlWhHG for ; Wed, 19 Nov 2014 02:35:23 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 27CFC1ACFD5 for ; Wed, 19 Nov 2014 02:35:23 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 8DBFA32E57C; Wed, 19 Nov 2014 19:34:38 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4a6c_b84f_d79ce443_62e5_4598_bed0_842b11328be7; Wed, 19 Nov 2014 19:34:37 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 782DCBF511; Wed, 19 Nov 2014 19:34:37 +0900 (JST) Message-ID: <546C723C.10805@it.aoyama.ac.jp> Date: Wed, 19 Nov 2014 19:34:36 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andrew Newton , Julian Reschke References: <546AF38B.40306@gmx.de> <546B4DA2.2050609@gmx.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UKfNcQfCViqtcs5fdLQaBseOzpk Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis Section 5 Conformance consensus (was: 2141bis Section 6 Conformance consensus) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 10:35:24 -0000 I just changed the subject to align it with the content :-). Regards, Martin. On 2014/11/18 22:50, Andrew Newton wrote: > Coffee, now! > > On Tue, Nov 18, 2014 at 8:46 AM, Julian Reschke wrote: >> On 2014-11-18 14:40, Andrew Newton wrote: >>> >>> On Tue, Nov 18, 2014 at 2:21 AM, Julian Reschke >>> wrote: >>>> >>>> Is this a question about >>>> >>>> ? >>> >>> >>> >>> Yes, section 6. Sorry for the confusion. >>> >>> -andy >> >> >> Five :-) >> > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Wed Nov 19 03:35:37 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513B11AD026 for ; Wed, 19 Nov 2014 03:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, LOTS_OF_MONEY=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAZNQf74u3FN for ; Wed, 19 Nov 2014 03:35:31 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA801AD057 for ; Wed, 19 Nov 2014 03:35:29 -0800 (PST) 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 sAJBZXgp031416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Nov 2014 13:35:33 +0200 Message-ID: <546C807D.4030007@helsinki.fi> Date: Wed, 19 Nov 2014 13:35:25 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , urn@ietf.org References: <546AE45B.1040901@helsinki.fi> <546B1118.4070404@it.aoyama.ac.jp> <546B2A2F.8090809@helsinki.fi> <546C709B.8090503@it.aoyama.ac.jp> In-Reply-To: <546C709B.8090503@it.aoyama.ac.jp> Content-Type: multipart/alternative; boundary="------------070808040308070603000507" Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bj5honj9IkXazHuzLLwzMnYbJA0 Subject: Re: [urn] 2141bis equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 11:35:36 -0000 This is a multi-part message in MIME format. --------------070808040308070603000507 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Martin, On 19.11.2014 12:27, "Martin J. Dürst" wrote: > Hello Juha, > > > urn:isbn: already exists, and I definitely don't want to change its > definition, especially not in ways that are not backward-compatible > (i.e. declaring some ISBN URN that was valid before suddenly invalid). Good. > > But if we take ISBNs just as an example for a future registration, > then I think it's a very valid idea to e.g. say that ISBNs can contain > hyphens, but these are removed when constructing an urn:isbn: URN. It > may not always be the best solution, but it would be strange to reject > such as solution from the get-go. IMO this is something which should be considered whenever a URN namespace is registered. The ISBN community could afford to be liberal since all applications which deal with ISBNs know that hyphens are to be ignored when ISBNs are processed. But some other communities may have valid reasons for providing additional guidelines for how to express their identifiers as URNs (that is, something that goes beyond the simple percent encoding). > >> and that can be done by creating namespace >> specific rules for lexical equivalence which says that hyphens must be >> ignored. > > Yes, it can. But we should write our document so that the other choice > (eliminating gratuitous equivalences by restricting the permitted > syntax) is at least also permitted, if not preferred. OK. > >> In the case of ISBN, the main challenge in determination of lexical >> equivalence is that publishers, when reprinting a book (which does not >> require a new ISBN), often replace ISBN-10 with lexically equivalent >> ISBN-13. > > One solution would be to just keep urn:isbn: syntax at 10 digits. The > remaining 3 digits are the same all the time anyway. I'm not saying > this is the best solution, but it is one choice with some clear > advantages. Alas, it is not as simple as that. ISBN-10 and ISBN-13 use different algorithms for check sum calculation. ISBN-13 is compatible with EAN system, so the check digit had to be a number. ISBN-10 allows X as well. If a check digit of ISBN-10 is not recalculated, it is likely that the ISBN-13 will not be valid. > > >>> I think we should at least leave this choice to the creators of URN >>> namespaces, and we should probably recommend to eliminate equivalences >>> by restricting syntax rather than mandate that each scheme MUST define >>> equivalences. >> >> IMO the best approach is the one that creates the smallest amount of >> turbulence. In the ISBN case it is the one which allows two ways of >> expressing ISBN strings (with or without hyphens). > > 'turbulence' is a very vague concept. In the case of ISBN URNs, my > interpretation of > > >>>> > An ISBN is a ten-digit number (actually, the last digit can be the > letter "X" as well, as described below) which is divided into four > variable length parts usually separated by hyphens when printed. > >>>> > > (from https://tools.ietf.org/html/rfc3187) is that hyphens are already > allowed at specific places, and therefore in this specific case, it's > a bad idea to try to backtrack and disallow them. + 1. > > > >> >> It is unlikely that any application out there needs to deal with all URN >> namespaces with this level of specificity. A library system must know >> how to deal with URN:ISBNs and other bibliographic identifiers, but that >> is trivial since these applications already know how to deal with ISBNs >> etc. > > Then your above proposal of > > <<<< > 5. namespace specific rules for equivalence, if any > <<<< > > should be changed to something like > > >>>> > 5. namespace specific rules for equivalence, for the (possibly empty) > set of namespaces that an application chooses to apply such rules OK. >> >> The case I had in mind is the comparison between the valid (corrected) >> and invalid (original) ISBNs. Library metadata usually incorporates both >> variants. > > What do you mean by "incorporates"? My hope is that library metadata > as much as possible contains only valid data, and that software used > for inputting it checks inputs for validity. But maybe I'm having too > high expectations for library metadata, or I don't understand what you > mean by "incorporates". You underestimate the complexity of library metadata ;-). It is important to provide canceled ISBN since that ISBN is often the one printed in the book. Valid and invalid / canceled ISBNs are tagged differently in MARC 21 records. In this example > *020* *##**$z*0835200028 :*$c*$10.00 > *020* *##**$a*0835200019*$q*pbk.*$c*$2.95/ > / > valid ISBN is the one in the second row, and the invalid one is the one on the top. Library systems can tell these ISBN variants apart. > > >> It is important to show that they are equivalent (identify the >> same resource) since both versions of the URN:ISBN may be actionable in >> the Web. For instance, the publisher may prefer to use the invalid >> identifier and libraries the correct one. > > I understand that mistakes happen, but why would a publisher prefer to > use something invalid? Because the invalid ISBN may be the one printed in the book. Unlike some systems in book shops, library systems usually check the validity of the ISBN and do not approve a number which is invalid. >> >> If the only difference is that one identifier has a wrong check sum and >> another the correct one, we may assume that the two are in fact >> equivalent and there is just a typo or miscalculated check sum in >> another one. > > So if I have an ISBN of (987-)1-449-32188-9, who is going to tell me > what this is supposed to be, given that I have a choice of 14 > alternatives at > http://www.isbn-check.de/checkisbn.pl?isbn=1-449-32188-9&submit=test&lang=en > ? The algorithm used for calculating ISBN check sums is simple. The correct check sum can be calculated even manually pretty fast, both for ISBN-10 and ISBN-13. National ISBN centers (often located in national libraries) have other means for spotting errors. Large publishers usually get chunks of ISBN numbers which they assign for books by themselves. When something goes wrong, the ISBN center can check what has happened. In your example there is nothing wrong, according to the catalogue of Der Deutschen Nationalbibliothek. The book just happens to have both ISBN-10 and ISBN-13, which have different check sum calculation algorithms. In the record retrieved by https://portal.dnb.de/opac.htm?method=simpleSearch&query=978-1-449-32188-9 neither ISBN has been tagged as invalid: they are in separate tag 020 $a occurrences in the metadata record. And according to the rules of the ISBN community, it is OK to give a book both ISBN-13 and ISBN-10 (or generate automatically one from the another). This is necessary during a transitory period since some organizations may still have outdated systems which cannot deal with ISBN-13. > > After all, we all know that checksums such as this one are a way to > catch some errors, but in no way allow us to fix the errors. In order > to be able to fix a single-digit error, we would need at least a > two-digit checksum. OK. > > Or do you expect to also involve an actual book catalog, which might > help to reduce the choices somewhat? > > [Hint: If you check all the alternatives, rule out the ones that are > not actually assigned, and then look at the topics of the resulting > books, you might find out which book I referred to; it's somewhat > related to the topic at hand :-).] Well, I found only one book: Bad data handbook by Reilly :-). > > >> >> It is also possible to determine (using the namespace specific rules) if >> the NSS is valid, and - if it is not - cancel the rest of the lexical >> equivalence checking process because the result would not be reliable. >> I'm afraid this is unavoidable if there is no way of knowing / making an >> educated guess what the correct NSS would have been. > > My impression is that at least for ISBNs, knowing is impossible. > Making an educated guess may be possible for humans (see my example > above), but it should not be part of URNs per se. I'm not sure about > others, but at least in my book, the concept of permanent, carefully > assigned identifier and the concept of "educated guess" don't go very > well together. So you agree that if the identifier is invalid (according to the check sum), it is usually OK to stop analysing the lexical equivalence, because the result would be meaningless in any case? The example you chose also indicates that it is important to know exactly which identifier assignment rules are being used by a community in question. Otherwise it is possible to make wrong conclusions. ISBN and other semantic identifiers make it easy for humans to spot certain kinds of errors (for instance, it is easy to see if there is a typo in the publisher code). Machines are rarely capable of this kind of analysis because they do not dig deep enough (for instance, they never compare the publisher name and the publisher code in ISBN). All the best, Juha > > Regards, Martin. > > >> All the best, >> >> Juha >>> >>> Regards, Martin. >>> >>> >>>> In 4.2, examples with f-, q- and p-components could be useful. >>>> >>>> Juha >>>> >>>> On 17.11.2014 21:28, Andrew Newton wrote: >>>>> All, >>>>> >>>>> I'm inviting feedback on the equivalence rules of section 3.3 and >>>>> section 4 of 2141bis. It states that p-components are to be used for >>>>> equivalence testing where as q- and f- components are not. >>>>> Additionally, the NSS may also have separate rules per NID with >>>>> regards to equivalency. Are there any questions, comments, or >>>>> objections to these rules? If so, why? >>>>> >>>>> -andy, >>>>> co-chair >>>>> >>>>> _______________________________________________ >>>>> urn mailing list >>>>> urn@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/urn >>>> >>>> _______________________________________________ >>>> urn mailing list >>>> urn@ietf.org >>>> https://www.ietf.org/mailman/listinfo/urn >>>> >> >> -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 --------------070808040308070603000507 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello Martin,

On 19.11.2014 12:27, "Martin J. Dürst" wrote:
Hello Juha,


urn:isbn: already exists, and I definitely don't want to change its definition, especially not in ways that are not backward-compatible (i.e. declaring some ISBN URN that was valid before suddenly invalid).

Good.

But if we take ISBNs just as an example for a future registration, then I think it's a very valid idea to e.g. say that ISBNs can contain hyphens, but these are removed when constructing an urn:isbn: URN. It may not always be the best solution, but it would be strange to reject such as solution from the get-go.

IMO this is something which should be considered whenever a URN namespace is registered. The ISBN community could afford to be liberal since all applications which deal with ISBNs know that hyphens are to be ignored when ISBNs are processed.  But some other communities may have valid reasons for providing additional guidelines for how to express their identifiers as URNs (that is, something that goes beyond the simple percent encoding).

and that can be done by creating namespace
specific rules for lexical equivalence which says that hyphens must be
ignored.

Yes, it can. But we should write our document so that the other choice (eliminating gratuitous equivalences by restricting the permitted syntax) is at least also permitted, if not preferred.

OK.

In the case of ISBN, the main challenge in determination of lexical
equivalence is that publishers, when reprinting a book (which does not
require a new ISBN), often replace ISBN-10 with lexically equivalent
ISBN-13.

One solution would be to just keep urn:isbn: syntax at 10 digits. The remaining 3 digits are the same all the time anyway. I'm not saying this is the best solution, but it is one choice with some clear advantages.

Alas, it is not as simple as that. ISBN-10 and ISBN-13 use different algorithms for check sum calculation. ISBN-13 is compatible with EAN system, so the check digit had to be a number. ISBN-10 allows X as well. If a check digit of ISBN-10 is not recalculated, it is likely that the ISBN-13 will not be valid. 


I think we should at least leave this choice to the creators of URN
namespaces, and we should probably recommend to eliminate equivalences
by restricting syntax rather than mandate that each scheme MUST define
equivalences.

IMO the best approach is the one that creates the smallest amount of
turbulence. In the ISBN case it is the one which allows two ways of
expressing ISBN strings (with or without hyphens).

'turbulence' is a very vague concept. In the case of ISBN URNs, my interpretation of

>>>>
   An ISBN is a ten-digit number (actually, the last digit can be the
   letter "X" as well, as described below) which is divided into four
   variable length parts usually separated by hyphens when printed.
>>>>

(from https://tools.ietf.org/html/rfc3187) is that hyphens are already allowed at specific places, and therefore in this specific case, it's a bad idea to try to backtrack and disallow them.

+ 1.




It is unlikely that any application out there needs to deal with all URN
namespaces with this level of specificity. A library system must know
how to deal with URN:ISBNs and other bibliographic identifiers, but that
is trivial since these applications already know how to deal with ISBNs
etc.

Then your above proposal of

<<<<
5. namespace specific rules for equivalence, if any
<<<<

should be changed to something like

>>>>
5. namespace specific rules for equivalence, for the (possibly empty) set of namespaces that an application chooses to apply such rules

OK.



The case I had in mind is the comparison between the valid (corrected)
and invalid (original) ISBNs. Library metadata usually incorporates both
variants.

What do you mean by "incorporates"? My hope is that library metadata as much as possible contains only valid data, and that software used for inputting it checks inputs for validity. But maybe I'm having too high expectations for library metadata, or I don't understand what you mean by "incorporates".

You underestimate the complexity of library metadata ;-).

It is important to provide canceled ISBN since that ISBN is often the one printed in the book.

Valid and invalid / canceled ISBNs are tagged differently in MARC 21 records. In this example

020 ##$z0835200028 :$c$10.00
020 ##$a0835200019$qpbk.$c$2.95
 
valid ISBN is the one in the second row, and the invalid one is the one on the top.  Library systems can tell these ISBN variants apart.



It is important to show that they are equivalent (identify the
same resource) since both versions of the URN:ISBN may be actionable in
the Web. For instance, the publisher may prefer to use the invalid
identifier and libraries the correct one.

I understand that mistakes happen, but why would a publisher prefer to use something invalid?

Because the invalid ISBN may be the one printed in the book.

Unlike some systems in book shops, library systems usually check the validity of the ISBN and do not approve a number which is invalid.


If the only difference is that one identifier has a wrong check sum and
another the correct one, we may assume that  the two are in fact
equivalent and there is just a typo or miscalculated check sum in
another one.

So if I have an ISBN of (987-)1-449-32188-9, who is going to tell me what this is supposed to be, given that I have a choice of 14 alternatives at http://www.isbn-check.de/checkisbn.pl?isbn=1-449-32188-9&submit=test&lang=en ?

The algorithm used for calculating ISBN check sums is simple. The correct check sum can be calculated even manually pretty fast, both for ISBN-10 and ISBN-13.

National ISBN centers (often located in national libraries) have other means for spotting errors. Large publishers usually get chunks of ISBN numbers which they assign for books by themselves. When something goes wrong, the ISBN center can check what has happened.

In your example there is nothing wrong, according to the catalogue of Der Deutschen Nationalbibliothek. The book just happens to have both ISBN-10 and ISBN-13, which have different check sum calculation algorithms. In the record retrieved by 

https://portal.dnb.de/opac.htm?method=simpleSearch&query=978-1-449-32188-9

neither ISBN has been tagged as invalid: they are in separate tag 020 $a occurrences in the metadata record. And according to the rules of the ISBN community, it is OK to give a book both ISBN-13 and ISBN-10 (or generate automatically one from the another). This is necessary during a transitory period since some organizations may still have outdated systems which cannot deal with ISBN-13.
 

After all, we all know that checksums such as this one are a way to catch some errors, but in no way allow us to fix the errors. In order to be able to fix a single-digit error, we would need at least a two-digit checksum.

OK.

Or do you expect to also involve an actual book catalog, which might help to reduce the choices somewhat?

[Hint: If you check all the alternatives, rule out the ones that are not actually assigned, and then look at the topics of the resulting books, you might find out which book I referred to; it's somewhat related to the topic at hand :-).]

Well, I found only one book: Bad data handbook by Reilly :-).




It is also possible to determine (using the namespace specific rules) if
the NSS is valid, and - if it is not - cancel the rest of the lexical
equivalence checking process because the result would not be reliable.
I'm afraid this is unavoidable if there is no way of knowing / making an
educated guess what the correct NSS would have been.

My impression is that at least for ISBNs, knowing is impossible. Making an educated guess may be possible for humans (see my example above), but it should not be part of URNs per se. I'm not sure about others, but at least in my book, the concept of permanent, carefully assigned identifier and the concept of "educated guess" don't go very well together.

So you agree that if the identifier is invalid (according to the check sum), it is usually OK to stop analysing the lexical equivalence, because the result would be meaningless in any case?

The example you chose also indicates that it is important to know exactly which identifier assignment rules are being used by a community in question. Otherwise it is possible to make wrong conclusions.

ISBN and other semantic identifiers make it easy for humans to spot certain kinds of errors (for instance, it is easy to see if there is a typo in the publisher code). Machines are rarely capable of this kind of analysis because they do not dig deep enough (for instance, they never compare the publisher name and the publisher code in ISBN).

All the best,

Juha
 

Regards,    Martin.


All the best,

Juha

Regards,   Martin.


In 4.2, examples with f-, q- and p-components could be useful.

Juha

On 17.11.2014 21:28, Andrew Newton wrote:
All,

I'm inviting feedback on the equivalence rules of section 3.3 and
section 4 of 2141bis. It states that p-components are to be used for
equivalence testing where as q- and f- components are not.
Additionally, the NSS may also have separate rules per NID with
regards to equivalency. Are there any questions, comments, or
objections to these rules? If so, why?

-andy,
co-chair

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn 





-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University
 Tel. +358 9 191 44293
 Mobile +358 50 3827678
--------------070808040308070603000507-- From nobody Thu Nov 20 06:33:47 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034EE1A19E7 for ; Thu, 20 Nov 2014 06:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVXqJHrqxSCC for ; Thu, 20 Nov 2014 06:33:44 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id DDA251A1A34 for ; Thu, 20 Nov 2014 06:33:43 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id sAKEXaEk004782; Thu, 20 Nov 2014 14:33:36 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id sAKEXaaR022210; Thu, 20 Nov 2014 14:33:36 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id sAKEXZJC018234; Thu, 20 Nov 2014 14:33:35 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id sAKEXZXl018230; Thu, 20 Nov 2014 14:33:35 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <546AF38B.40306@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 20 Nov 2014 14:33:35 +0000 In-Reply-To: <546AF38B.40306@gmx.de> (Julian Reschke's message of "Tue\, 18 Nov 2014 08\:21\:47 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/6K0zIC74ccEbB2Gakit7XR0IZig Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis Section 5 Conformance consensus X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 14:33:47 -0000 Julian Reschke writes: >> 5. URI Conformance >> >> >> Because a URN is, syntactically, a URI under the "urn" scheme, in >> theory a URN can be placed in any protocol slot that allows for a URI >> (e.g., an XML namespace name [XML-NAMES]). However, this does not >> imply that, semantically, it makes sense in practice to place a URN > > maybe s/makes sense/always makes sense/ Yes, this is very important. >> in a given URI protocol slot; in particular, because a URN does not >> specify the location of a resource, it is not appropriate to place a >> URN in a URI protocol slot that points to a resource (examples >> include the 'href' and 'src' attributes and the element in >> HTML, as well as the 'xml:base' attribute in XML [XML-BASE]). > > It's not clear to me why it would be wrong to use a URN in a/@href. In fact, it's clear to me that it will often make sense to use URNs in a/@href and even image/@src, and it will become increasingly common to do so, if implementation of registerProtocolHandler [1] becomes widespread. I note that 'urn' is already specified as a whitelisted (i.e. open to have a handler registered). Just as I expect the DOI folks to provide support for doi: URIs via a (misnamed, I agree) 'protocol' handler, so the ISBN folks could register a handler for 'urn' URIs, (and start a turf war, until the WebApps WG allows registration of handlers for specific URN namespaces). See the sub-thread starting with Mark Baker's mention of registerProtocolHandler [2] for further examples. ht [1] http://www.w3.org/TR/html5/webappapis.html#dom-navigator-registerprotocolhandler [2] http://www.ietf.org/mail-archive/web/urn/current/msg02232.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam]