Re: draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00

Sean Leonard <> Wed, 17 December 2014 08:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AE0441A1B51 for <>; Wed, 17 Dec 2014 00:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rc--q6mQ6LSH for <>; Wed, 17 Dec 2014 00:53:34 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 762AF1A6EF0 for <>; Wed, 17 Dec 2014 00:53:34 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F1F5C22E259; Wed, 17 Dec 2014 03:53:32 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00
From: Sean Leonard <>
In-Reply-To: <>
Date: Wed, 17 Dec 2014 00:53:31 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "Dale R. Worley" <>
X-Mailer: Apple Mail (2.1878.6)
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 08:53:40 -0000

On Nov 13, 2014, at 9:22 AM, Dale R. Worley <> wrote:

> I notice a strong similarity between these two drafts,
> draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00, as they
> propose two NIDs with the same syntax, registration procedures, and
> resolution properties.  The only difference is what the resulting URNs
> are intended to be used for.
> It would seem to me to provide simplicity and more functionality if
> the two drafts were combined to propose a single NID whose URNs could
> be used as either XML namespace identifiers or RDF node identifiers --
> or for identifying other things.

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 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.

> Combining the drafts would also avoid duplicate discussion of whether
> there was enough value in the purpose of the NID:  to provide short,
> memorable identifiers that do not depend on (or refer to) domain
> registrations.

I am okay with combining the drafts into one draft, to ease IETF publication burden. I am not comfortable with combining the two into one NID, however.

Shall I combine the drafts into one for the next draft posting, or wait on it in order to address the existing comments first in the separate drafts, before (possibly) combining the drafts?

> 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:

…since it’s still being maintained by IANA, and serving over HTTP Just Works(tm). The data could be in a basic structured format—in this case I recommend very basic XML, since the client is obviously going to support XML. (Sub-paths can also be used, such as for urn:xmlns:foobar:2014. In such a case, the data returned could just be a list of URIs separated by newlines in plain text.)

I know that URN resolvers are supposed to be “DNS-y” based on prior RFCs, but using HTTP for these particular URNs just makes sense.