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

From: Sean Leonard <[email-masked]>
Date: Wed, 17 Dec 2014 00:53:31 -0800

On Nov 13, 2014, at 9:22 AM, Dale R. Worley <[email-masked]> 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 http://example.com/foobar. 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:
http://www.iana.org/assignments/urn-xmlns-names
http://www.iana.org/assignments/urn-rdf-names

…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 http://www.iana.org/assignments/urn-xmlns-names/foobar:2014 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.

Cheers,

Sean

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 17 Dec 2014 13:51:22 -0500

Sean Leonard <[email-masked]> 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
> http://example.com/foobar.

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
http://example.com/foobar", 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
important?

> Thanks, it's a good idea.
>

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 "http://example.com/foobar", 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.

Dale

---

From: Sean Leonard <[email-masked]>
Date: Fri, 19 Dec 2014 03:12:26 -0800

> available as a NID!)  That would be even shorter.

It would be shorter. But my observation is that namespaces make the most sense when they uniformly identify a certain class of things, because the common semantics of the things can be assumed, catalogued, and retrieved in a systematic (automated) way.

Consider a category NID like “oid”. In that case, urn:oid:* stands for all sorts of things but each and every thing has an OID and associated OID semantics: a number, optional secondary identifiers, (since ~2005) Unicode identifiers, and other information that is stored in databases such as www.oid-info.com (Description, Information, registration data).

A converse example might be an organization-delgated NID like “ietf”. In that case, urn:ietf:* might stand for all sorts of “things” (XML namespaces, parameter values, documents, etc.), but we know that all of those things are “IETF things” and therefore there is one place to get the definitions: from the IETF.

> update the draft to explain why this is important?’

Ok.

> the draft to explain why this is important?

Ok. (See above; I will elaborate in the next draft.)

> create brief URNs.  Can you update the draft to explain why this is

Ok. (See above. To continue the examples, the IETF has several OIDs at its disposal, so it could easily mint unique URNs in urn:oid:1.3.6.1.* or elsewhere. But whether it’s vanity or something else, the IETF wanted urn:ietf. Note that there is also a urn:iso [RFC5141] even though ISO also has urn:oid:1.* which is way up at the top of the tree. Vanity or something else? You be the judge!)

> there is a robust conversation about these questions.

Actually I would say that the resolution database is not intrinsic to the proposal. Such a database is extremely helpful (as www.oid-info.com is for OIDs) for implementers and designers, but it is not required. Both XML namespaces and RDF nodes have definitions that do not require an URI to be dereferenceable to particular resources: the only requirement is that the URI is unique. The fact that some URIs are retrievable helps when someone (typically an engineer, designer, or protocol analyst) is interrogating some unknown data item.

> and the server for the information can be maintained by someone else.

Or it could be maintained by IANA. Domains come and go, but IANA, like diamonds, is forever. :)

As pointed out above, it’s not really expected that the database is going to get billions of hits per hour. We are not talking about the DNS root servers here. We’re talking about a convenient way for analysts (i.e., software engineers) to look up data to figure out what urn:rdf:elephant means. Basically it’s on the order of the Private Enterprise Numbers “database”, which is just a flat text file delimited with newlines. <http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers>

Sean

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 19 Dec 2014 11:00:46 -0500

Sean Leonard <[email-masked]> writes:
> Actually I would say that the resolution database is not intrinsic to
> the proposal.

If the resolution database is not intrinsic to the proposal, I think you
should remove it from the NID registrations.  The reason for that is
that the resolution process is a major differentiator between this
proposal and a number of others.

Dale

---

From: Sean Leonard <[email-masked]>
Date: Fri, 19 Dec 2014 08:02:27 -0800

> proposal and a number of others.

Ok...in your opinion is this "major differentiator" an advantage, or a 
disadvantage, of the proposal(s)?

Sean