Subject: Review and URN assignment for draft-seantek-xmlns-urn-00

From: Sean Leonard <[email-masked]>
Date: Mon, 10 Nov 2014 14:49:10 -1000

Sean Leonard requests review of draft-seantek-xmlns-urn-00, which registers the URN NID “xmlns”.

Regards,

Sean

*************

A new version of I-D, draft-seantek-xmlns-urn-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-xmlns-urn
Revision:	00
Title:		A Uniform Resource Name (URN) Namespace for XML Namespaces
Document date:	2014-11-10
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-seantek-xmlns-urn-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-xmlns-urn/
Htmlized:       http://tools.ietf.org/html/draft-seantek-xmlns-urn-00

Abstract:
  XML segregates elements into namespaces, which can be used to mix
  tags with different semantics in a composite XML document.  XML
  namespaces are identified by URIs.  This document defines a URN
  specifically for identifying XML namespaces.

The IETF Secretariat

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 11 Nov 2014 11:09:56 -0500

I'd like to see more discussion of why this NID is needed.  The draft
says:

   Experience suggests that 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.

That's true, but one can create URIs to name one's XML namespaces in
many ways already.  One can use "oid" URNs, or "tag" URIs, or build
HTTP URLs based on one's domain registration.

The draft continues:

   registrant's XML namespaces.  An XML namespace designer now has the
   option of choosing a short, memorable identifier ...

I assume that means "This draft provides an XML namespace designer
with the option...", even though the "now" in that sentence is
ambiguous -- does it refer to the time before adoption of the draft or
after?

It seems that mnemonicity is a goal.  But in practice, the nicely
mnemonic values will be taken fairly quickly and future registrants
will be restricted to non-mnemonic values -- unless some sort of
de-facto grouping convention comes to be used.

I've got some other issues with this draft, but they can be postponed
until we resolve why the NID is needed.  (They are very similar to my
issues with draft-seantek-rdf-urn-00.)

Dale

---

From: Sean Leonard <[email-masked]>
Date: Tue, 11 Nov 2014 10:18:03 -1000

Thank you for the feedback.

On Nov 11, 2014, at 6:09 AM, Dale R. Worley <[email-masked]> wrote:

> I'd like to see more discussion of why this NID is needed.

Ok.

>  The draft

That is correct. However, urn:oid (and for that matter, oid: ) and tag: URIs are not really used in practice. OIDs are compact but not particularly mnemonic. tag: URIs are mnemonic, but like http(s) URIs, they depend on the DNS infrastructure. tag: URIs only depend on the DNS infrastructure at a particular point in time…but that particular point in time is forever inscribed into the URI. For XML namespace purposes, that is a lot of unnecessary redundancy. Additionally, tag: URIs do not have any semantics or associations with XML namespace resources, so they can only be used to generate arbitrary strings. (From taguri.org, tag URIs satisfy School 1 but not School 2.)

Compare for “Foo Description Language Version 2":
http://www.acmecorp.com/xml/foodlv2
tag:acmecorp.com,2014:foodlv2
urn:xmlns:acme:foodlv2

The http URI has 35 characters. You can put resources there, if you want, but you have to keep paying for the domain name and web server into eternity.
The tag URI has 29 characters. You cannot put or associate resources there.
The xmlns URN has 22 characters. You can associate resources there, and it’s free as long as IANA is free (heh).

> ambiguous -- does it refer to the time before adoption of the draft or

Yes. After adoption of the draft.

> de-facto grouping convention comes to be used.

Meh, I am seriously not worried about that: that concern is overstated. People aren’t going to register things in urn:xmlns unless they are XML namespace URIs. It’s not really the right forum for vanity registrations. If folks are concerned about segregating a “private” sub-part of the namespace, there is a provision for that by using IANA Private Enterprise Numbers. The numbers are still low enough that they retain some mnemonic properties.

To the overall question of why this namespace is needed:
Since when is “why is this needed” a gating factor for URN assignments? For URI schemes, one is supposed to demonstrate some sort of broad utility for the Internet infrastructure. (But that can be easily overcome with a provisional registration.) For URNs, however, RFC 3406 states:

  ...the underlying
   namespace will provide benefit to *some subset of users* on the
   Internet.  That is, a formal NID proposal, if accepted, must be
   functional on and with the global Internet, not limited to users in
   communities or networks not connected to the Internet.  For example,
   a NID that is meant for naming of physics research is requested.  If
   that NID request required that the user use a proprietary network or
   service that was not at all open to the general Internet user, then
   it would make a poor request for a formal NID.  The intent is that,
   while the community of those who may actively use the names assigned
   within that NID may be small (but no less important), the potential
   use of names within that NID is open to any user on the Internet.

So to answer the question specifically: the namespace is beneficial to XML namespace designers who want to have short, mnemonic, unique, long-lived URIs, and to XML namespace users (that would be “everyone on the Internet”) who rely upon them. You can still use other URIs for XML namespaces, but this URN namespace is tailor-made to satisfy the needs of that subset of users.

Cheers,

Sean

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 12 Nov 2014 12:02:32 -0500

> From: Sean Leonard <[email-masked]>

> Yes. After adoption of the draft.

Does that mean, "We will edit the text to make that clear."?

> That is correct. However, urn:oid (and for that matter, oid: ) and
> tag: URIs are not really used in practice.

It's true that they're rarely used, but whose problem is that?  There
should be no reason that they *can't* be used.  The real problem (as
you say in text I deleted) is that they're not *mnemonic*.  As you
note below, the mnemonic feature is crucial for your proposal.

> So to answer the question specifically: the namespace is beneficial
> to XML namespace designers who want to have short, mnemonic, unique,
> long-lived URIs, and to XML namespace users (that would be “everyone
> on the Internet”) who rely upon them. You can still use other URIs
> for XML namespaces, but this URN namespace is tailor-made to satisfy
> the needs of that subset of users.

I'd like to see that written into the document as well, as that is the
real description of the purpose of the draft.

Is there truly a lot of demand for these, in particular the "short,
mnemonic" aspects?  I can't think that I would care myself, and I've
named XML namespaces.  (I used http: URLs based on the company's
domain.)

> tag:acmecorp.com,2014:foodlv2

I think to a degree the comparison is unfair.  Acme Corp. has the
domain name "acmecorp.com" because "acme.com" was taken.  Which means
that "urn:xmlns:acme" was likely to also have been taken, so Acme
Corp. will be using "urn:xmlns:acmecorp:..." or some such for their
URNs.  That lengthens the final example to
"urn:xmlns:acmecorp:foodlv2", which is still the shortest but is now
only 3 characters shorter than example 2.

Dale

---

From: Sean Leonard <[email-masked]>
Date: Wed, 12 Nov 2014 07:25:52 -1000

On Nov 12, 2014, at 7:02 AM, Dale R. Worley <[email-masked]> wrote:

> Does that mean, "We will edit the text to make that clear.”?

Yes.

> note below, the mnemonic feature is crucial for your proposal.

I agree that being memorable is a goal. However, it is not the only goal. At least one other key goal that the proposal describes is associating XML namespace semantics with the URI, namely by including a description of the namespace in the registry, and by operationally associating the URN with URIs that might have more information (such as schema definitions or syntax specifications).

A tag: can be used as an XML namespace, but if you pass tag: to an URI dereferencer, it’s not going to retrieve any representations. The idea is that if you pass urn:xmlns to a URN resolver, the URN resolver will be able to get relevant URIs by association.

> real description of the purpose of the draft.

Ok. Good point.

> named XML namespaces.  (I used http: URLs based on the company's

It gives more options.

One reason I wrote it was to deal with the brouhaha on [email-masked] about fragments (so-called “f-components”). XML namespaces don’t use fragments much, but RDF does. This proposal represents one attempt to deal with fragments in a systematic and URN + URI-compatible way.

(Note that ? is not a valid character in an XML Name, so the issue of so-called “q-components” is conveniently avoided.)

> only 3 characters shorter than example 2.

That is true…but the comparison may not necessarily be unfair.

The minimum HTTP URL would be:
http://acme.co/foodlv2

= 22 chars

actually, the REAL minimum URL would be:
http://x.acme/foodlv2

= 21 chars

thanks to ICANN’s new policy/cash cow of charging for TLDs. :)

the most minimum URNs would be:
urn:xmlns:acme:foodlv2

= 22 chars

or
urn:xmlns:foodlv2

= 17 chars

or (if you want to compress foodlv2, which you can because it’s in the acme-divided area)
urn:xmlns:acme:f

= 16 chars

The human mind wishes to fill in gaps and organize things into neat categories. Any of these could be acceptable. But the proposal has less to do with minimum characters, and more to do with avoiding encoding things that don’t matter to the task at hand.

An issue with HTTP URLs is that you’re sharing a namespace with the web server, and with the DNS infrastructure. I.e., http://acme.co/xml/foodlv2 requires reserving some directory for XML things instead of regular webpages; it also requires that you keep on paying for acme.co if you want the “association” semantics (as well as the uniqueness guarantees: the next owner of acme.co could devise another unrelated foodlv2 spec, and would never know that someone else came beforehand to define a prior one). And since it’s .co, it depends on the geopolitical situation with the nation of Colombia. (Compare with .ly, which was quite popular a couple of years back.) These are unnecessary dependencies for a one-off identifier.

If a random identifier is sufficient,
urn:uuid:9416c1d6-1c1c-4939-84c3-c730b0310418
will suit any namespace identifier purpose just fine. But the human mind is going to reject that in favor of something with a bit more internal and external meaning. (Internal = it has names like “acme” in it; External = you can dereference the URI to get useful things like syntax specifications or schema definitions.)

Sean

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 13 Nov 2014 15:41:32 -0500

> One reason I wrote it was to deal with the brouhaha on [email-masked]
> about fragments (so-called “f-components”). XML namespaces don’t use
> fragments much, but RDF does. This proposal represents one attempt
> to deal with fragments in a systematic and URN + URI-compatible way.

That sounds useful.  But given that the brouhaha exists, you need to
discuss more explicitly that you expect to use these URNs (1) with
fragment identifiers and/or (2) containing fragment identifiers -- and
the consequences thereof.  I don't think you have to solve the general
problem, but since the general problem hasn't been solved, you have to
show that you've thought through all the aspects that could arise in
your envisioned use cases.

(BTW, are fragment identifiers used with XML namespace identifiers?)

Dale