Re: draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00 (Dale R. Worley) Wed, 17 December 2014 18:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F42371A7029 for <>; Wed, 17 Dec 2014 10:51:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_35=0.6, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lkv6aBsozmxE for <>; Wed, 17 Dec 2014 10:51:28 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DCBB1A702E for <>; Wed, 17 Dec 2014 10:51:25 -0800 (PST)
Received: from ([]) by with comcast id Uiqb1p0092TL4Rh01irQXM; Wed, 17 Dec 2014 18:51:24 +0000
Received: from ([]) by with comcast id UirP1p0051KKtkw01irPLD; Wed, 17 Dec 2014 18:51:24 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id sBHIpMQ7025415; Wed, 17 Dec 2014 13:51:22 -0500
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id sBHIpMWr025412; Wed, 17 Dec 2014 13:51:22 -0500
X-Authentication-Warning: worley set sender to using -f
To: Sean Leonard <>
Subject: Re: draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00
In-Reply-To: <> (
Date: Wed, 17 Dec 2014 13:51:22 -0500
Message-ID: <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1418842284; bh=R9hdxLkdYm1a+f0ko5YTn0fZj0s8TbFSFXk6MPLAKRI=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=KaSOmMG4Sjx/7GPHvezPnx2ia/8VKAzdXe7pX5E8VCuTsdrHqlDDbE4Ylxu3wiQqa ICUpjRvi5UDNvezxuu1qbdSYWnkeweKlUSO4gnM0Qj4Z43yYn0sSvXyG0dPH3zzI6U B6h0BWTE4Yc9muAr1aGUwgDF4RKesW+6EEVUSbpHNQHRiZoK1V3xHPLjrtd9QeSs8f C6VyjvH28okX1vB6MuQ6lCoIkbnSdZt5lsmq1DujKK1aNVrDZPdkBVxReHYR2o2FE6 6GqMaUqh2YmQaFy97mOPT3Zmds05ObRpkGzOa96queE3Tz3+/DQoV0Ahq6LJ20AXTz +Uuw9QwsS5qGA==
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Dec 2014 18:51:30 -0000

Sean Leonard <> writes:
> Thought about it. But urn:xmlns:foobar and urn:rdf:foobar are
> preferable to urn:SOMENID:xmlns:foobar and urn:SOMENID:rdf:foobar. The
> shorter the better--remember that we are competing with

I was considering not syntactically distinguishing XML namespaces and
RDF references, so both would be of the form urn:id:foobar.  ("id" is
available as a NID!)  That would be even shorter.

In regard to "remember that we are competing with", I know of no such "competition".  Can you
update the draft to explain why this is important?

> Furthermore, urn:xmlns and urn:rdf represent distinct namespaces. The
> (abstract) resources accessible via and relevant to urn:xmlns are
> different from urn:rdf, and additional utility is gained by having
> particular classes of resources made permanently accessible in those
> distinct namespaces.

I don't see any value for syntactically distinguishing which URNs are
XML namespace identifiers and which are RDF references, since the
contexts in which the two would be used are disjoint.  Can you update
the draft to explain why this is important?

For that matter, I don't see any value for ensuring the URNs are brief.
To my knowledge, humans rarely input or output URNs.  The draft says
"several URN namespace registrations have been proposed over the years,
where the primary (yet only occasionally stated) purpose is to create
short URIs for the registrant's XML namespaces".  But it seems to me
that generally NIDs are created to delegate the ability to create URNs
to some industry consortium, not to ensure that the consortium can
create brief URNs.  Can you update the draft to explain why this is

>> In regard to the registration of the URIs associated with URNs and the
>> resolution of the URNs into the associated URIs, let me propose that
>> this data be be retrievable from some suitable zone of the DNS along
>> the following lines:
> Thanks, it's a good idea.
> However, I was thinking that the URIs be accessible at the resource(s)
> at something starting with:

Whatever the resolution mechanism is, it's clear that the method of
accessing the resolution database is intrinsic to your proposal.  But
your proposal gives no details as to how to access the resolution
database, or how IANA would implement it.  The former is an intrinsic
part of the definition of the namespace.  The latter is a critical piece
of IANA infrastructure.  So you need to discuss these and ensure that
there is a robust conversation about these questions.

In regard to comparison with using "", the
latter has the advantage that *IANA* doesn't have to maintain resolution
information, the URL itself can be used to fetch resolution information,
and the server for the information can be maintained by someone else.