Re: [urn] gbs Name space identifier
worley@ariadne.com (Dale R. Worley) Thu, 17 October 2019 01:59 UTC
Return-Path: <worley@alum.mit.edu>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 8CD8B1201CE
for <urn@ietfa.amsl.com>; Wed, 16 Oct 2019 18:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.684
X-Spam-Level:
X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7,
SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665]
autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=comcastmailservice.net
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 Ib-OrfpLan-W for <urn@ietfa.amsl.com>;
Wed, 16 Oct 2019 18:59:37 -0700 (PDT)
Received: from resqmta-ch2-09v.sys.comcast.net
(resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 0FA7912011B
for <urn@ietf.org>; Wed, 16 Oct 2019 18:59:36 -0700 (PDT)
Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102])
by resqmta-ch2-09v.sys.comcast.net with ESMTP
id KtXLiWb7JkltDKv4iivFhg; Thu, 17 Oct 2019 01:59:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=comcastmailservice.net; s=20180828_2048; t=1571277576;
bh=vTtkUXreaA9PJfpJufSFLB0xzeCa/nNKk23qmSQT88Y=;
h=Received:Received:Received:Received:From:To:Subject:Date:
Message-ID;
b=QfFz46DGLMWaQrWXsuoKfcUSypX8NRXLjyMjo81PXnHLqGhVgx8OdN/Yqijw5iVpt
jTEu9LkrnrIhtHQSIsx76d8PilaPPJy7eghlY62Z9DqgxRUzJPW19Z+RauC8GlU+LS
duBuyrxc68y4AIWyA6ei4b1a4PL5tyXx6JcCQaoeO7FIimiOY6MBRg/WNP484L2n0H
6NB69nlDuYgGfkn7ypuDReiZAO9jd7aJ9IjAJvM7/QoXXvrphjEIo1+leZyRdzmna3
B3NBs3OY/7SXyeSdUpXWGKb+N0B7EN4wKf6qdpKzgxk4oqR7Jna+mbFT77Om/Hz2L1
JtwagfPO964Zg==
Received: from hobgoblin.ariadne.com
([IPv6:2601:192:4600:1e00:222:fbff:fe91:d396])
by resomta-ch2-06v.sys.comcast.net with ESMTPA
id Kv4fictS8anXQKv4gi2f7S; Thu, 17 Oct 2019 01:59:35 +0000
X-Xfinity-VMeta: sc=-100;st=legit
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 x9H1xXf8013651;
Wed, 16 Oct 2019 21:59:33 -0400
Received: (from worley@localhost)
by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x9H1xWRM013648;
Wed, 16 Oct 2019 21:59:32 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to
worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Philip R Brenan <philiprbrenan@gmail.com>
Cc: juha.hakala@helsinki.fi, urn@ietf.org, lars.svensson@web.de
In-Reply-To: <CALhwFRmk_XzXHdpQXCDCp95cUGEpd9tmLTi4yjg+AAtpNhPg9g@mail.gmail.com>
(philiprbrenan@gmail.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Wed, 16 Oct 2019 21:59:32 -0400
Message-ID: <87mue0m8sb.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/NYJ9Ekf0vpisbZNG_pmx0UYuf6Q>
Subject: Re: [urn] gbs Name space identifier
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>,
<mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>,
<mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 01:59:39 -0000
I see the new version as an enormous improvement. One aspect that you've made clear is that for any given <B> value, there can be only one <G> value (although you cannot compute <G> from <B> unless you happen to have a copy of the topic to hand). As has been noted, URNs are *names* while URLs are *locators*, and URNs do not require a resolution process to locate the named resource. However, I think there are some aspects of the exposition that should be improved: Under "Resolution", it says: Equivalence is determined by comparing (ignoring case) the <B> components of the two topics to be compared. If they are equal the two topics are considered to be equal. Otherwise they are considered to be unequal even if the underlying content is in fact identical. The characteristics of the MD5 sum ensure that only a small number of topics will be unnecessarily duplicated as a result of such false positive equivalences. I do not see how "the underlying content is in fact identical" without generating the same <G> and <B>. I suspect you mean that there can be two topics that have no *meaningful* difference but nonetheless have different <B> or <G>. Under "Security and Privacy", it says: The validity of the URN can be checked as follows: However, these actions can only be done if one possesses not just the URN but also the content it refers to. Usually "validity checking" names a procedure that only requires the URN as input. So it would help if you expanded this sentence. Perhaps, "The validity of the URN for a topic can be checked as follows:" Under "Inter-operability", it says: The case of the letters chosen is immaterial and can be safely ignored in all computations on the proposed URN as only the <B> component is used for comparisons. The case of letters can be ignored for comparing URNs, but when copying or transmitting URNs, case has to be preserved, because only lower-case letters are valid in the <B> part of the URN, and the case of the letters in the <G> part must match that of the text from which it was derived -- so if you send the URN to another process, you have to get the case right. So you want to narrow this statement. Perhaps, "For many computations, the case of the letters in the URN is immaterial and can be safely ignored..." Dale
- [urn] gbs Name space identifier Philip R Brenan
- Re: [urn] gbs Name space identifier Dale R. Worley
- Re: [urn] gbs Name space identifier lars.svensson
- Re: [urn] gbs Name space identifier Hakala, Juha E
- Re: [urn] gbs Name space identifier Philip R Brenan
- Re: [urn] gbs Name space identifier Hakala, Juha E
- Re: [urn] gbs Name space identifier Philip R Brenan
- Re: [urn] gbs Name space identifier Hakala, Juha E
- Re: [urn] gbs Name space identifier Philip R Brenan
- Re: [urn] gbs Name space identifier Dale R. Worley
- Re: [urn] gbs Name space identifier Dale R. Worley
- Re: [urn] gbs Name space identifier Philip R Brenan
- Re: [urn] gbs Name space identifier Dale R. Worley
- Re: [urn] gbs Name space identifier Philip R Brenan
- Re: [urn] gbs Name space identifier Dale R. Worley