Re: URN UUID question

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 24 March 2014 09:48 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0721A017C for <urn-nid@ietfa.amsl.com>; Mon, 24 Mar 2014 02:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.798
X-Spam-Level: **
X-Spam-Status: No, score=2.798 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3QJuOyx4M29 for <urn-nid@ietfa.amsl.com>; Mon, 24 Mar 2014 02:48:36 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 457251A017B for <urn-nid@ietf.org>; Mon, 24 Mar 2014 02:48:36 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with SMTP id 8D70A32E536; Mon, 24 Mar 2014 18:48:34 +0900 (JST)
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 4fd8_144e_772f8318_b339_11e3_8531_001e6722eec2; Mon, 24 Mar 2014 18:48:34 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id C3883C00DA; Mon, 24 Mar 2014 18:48:33 +0900 (JST)
Message-ID: <532FFF6A.6080206@it.aoyama.ac.jp>
Date: Mon, 24 Mar 2014 18:48:26 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Joel Kalvesmaki <kalvesmaki@gmail.com>, "Dale R. Worley" <worley@ariadne.com>
Subject: Re: URN UUID question
References: <CALPpAZ_fLwK80dcM5ty5pp2pLiafpW36uvK2WoJdKpuaWX6PQw@mail.gmail.com> <201403192139.s2JLdchi012675@hobgoblin.ariadne.com> <CALPpAZ8oqUMg6Q+HZjhkyCDPGOnFYYrrrXY=Jxr8OJH2YU39FQ@mail.gmail.com>
In-Reply-To: <CALPpAZ8oqUMg6Q+HZjhkyCDPGOnFYYrrrXY=Jxr8OJH2YU39FQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/g9MDHj60c6_0POP58HZLzn6xYPk
Cc: urn-nid@ietf.org, timothy@hpl.hp.com, Sandro Hawke <sandro@w3.org>
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Mar 2014 09:48:38 -0000

On 2014/03/20 09:15, Joel Kalvesmaki wrote:

> I need unique, persistent names. The name needs to be a single IRI/URI to
> allow any version of any document to be named easily in any RDF
> declarations any third party might want to make.

> After reading the specs on the tag URN, I'm very impressed, and think that
> it will suit the XML model nicely. Tag URNs provide two extra bonuses I
> hadn't anticipated: human readability and decentralized unique agent
> identification.
>
> I do wish IRI forms of tag URNs had gotten off the ground, but maybe that
> will come some day?

Looking at https://tools.ietf.org/html/rfc4151, that indeed seems to be 
an unfortunate oversight.

Instead of
 >>>>
    In the interests of tractability to humans, tags SHOULD NOT be minted
    with percent-encoded parts.  However, the tag syntax does allow
    percent-encoded characters in the "pchar" elements (defined in RFC
    3986 [1]).
 >>>>

It should allow percent-encoded parts also in the authorityName part, 
and specify that in all cases, such percent-encoded parts must be 
created and interpreted using UTF-8. After all, that's what RFC 3986 
(which is heavily cited) says for authority names.

Sandro, Tim, is there a chance this can be fixed sooner or later?

Regards,   Martin.