Re: URN UUID question

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Wed, 26 March 2014 02:36 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 0E4561A0088 for <urn-nid@ietfa.amsl.com>; Tue, 25 Mar 2014 19:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.899
X-Spam-Level:
X-Spam-Status: No, score=0.899 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, 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 GWvln-MOeOcZ for <urn-nid@ietfa.amsl.com>; Tue, 25 Mar 2014 19:36:06 -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 8CD1B1A006C for <urn-nid@ietf.org>; Tue, 25 Mar 2014 19:36:06 -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 71D8E32E54A; Wed, 26 Mar 2014 11:36:04 +0900 (JST)
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 071e_081e_607fe232_b48f_11e3_9b01_001e6722eec2; Wed, 26 Mar 2014 11:36:03 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id DE0DFBF544; Wed, 26 Mar 2014 11:36:03 +0900 (JST)
Message-ID: <53323D0D.1040105@it.aoyama.ac.jp>
Date: Wed, 26 Mar 2014 11:35:57 +0900
From: "\"Martin J. Dürst\"" <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: Sandro Hawke <sandro@w3.org>, 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> <532FFF6A.6080206@it.aoyama.ac.jp> <53301AA4.30402@w3.org>
In-Reply-To: <53301AA4.30402@w3.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/ZoqGzmPZt1tTkyftn3CL9Ebgngg
Cc: urn-nid@ietf.org, timothy@hpl.hp.com
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: Wed, 26 Mar 2014 02:36:09 -0000

Hello Sandro,

On 2014/03/24 20:44, Sandro Hawke wrote:
> On 03/24/2014 12:48 PM, "Martin J. Dürst" wrote:
>> 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.
>>
>
> Interesting.   I'm trying to remember the motivations here.
>
> Certainly unnecessary percent encoding is a problem because it causes
> confusion about whether two URIs are the same.   (If you have to ask
> that, they are not.   But people may not realize that.   Some people
> might think "tag:sandro@hawke.org,2014:A" and
> "tag:sandro@hawke.org,2014:%41" are the same, but they are not.)

Actually, they are not the same for XML namespaces and for RDF, but for 
http and for search engines, they are (pretty much) the same. Now tag: 
URIs are probably more used in RDF than in http, so your point is 
certainly important.


> On the authorityName, if it's a DNSName, presumably you'd use punycode,
> not percent encoding, right?

Well, if it's an IRI, just use the original characters :-).

> If it's an emailAddress, presumably you'd
> use punycode for the DNSname part of it.  I don't know what one's
> supposed to use for the part before the @ in an email address?      I
> haven't kept up on the email standards.    Is there consensus about that?

Please see https://tools.ietf.org/html/rfc6531 and 
https://tools.ietf.org/html/rfc6532. Essentially, UTF-8 is used in the 
mail protocol and format. For URIs, see 
http://tools.ietf.org/html/rfc6068. So again, just using the actual 
characters is the best thing to do.

>> Sandro, Tim, is there a chance this can be fixed sooner or later?
>>
>
> I'm not using or endorsing tag: URIs at all these days.   From my
> perspective, http or https URLs are better in very-nearly every
> situation.    But I wouldn't be opposed to someone else updating the tag
> URI spec.

Noted!

Regards,   Martin.