Re: URN UUID question

Joel Kalvesmaki <> Wed, 26 March 2014 14:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B8C961A0119 for <>; Wed, 26 Mar 2014 07:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id To8TunntB5pu for <>; Wed, 26 Mar 2014 07:27:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::232]) by (Postfix) with ESMTP id 6E9861A00E3 for <>; Wed, 26 Mar 2014 07:27:55 -0700 (PDT)
Received: by with SMTP id im17so2475650vcb.37 for <>; Wed, 26 Mar 2014 07:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qGS/x0lfmfHnfbVvHYiTcqLVSjupSQ7K7Xr7L8tXnRg=; b=qgyYYDCN3F+GscCDTHSOPVSoyy7sK+6KtrTJrYIx+SRsWfbiSS0dT5qIGLI5poe4Fw OXheCWRHlUVDXtBksh2yP/Tk+Bz5legBQmVOSFyj5YzXbY7gYfCsRug4xW+3HhO1WeAG HXddwbINiVYNUXWKoy/aCRW254dVM53Tp/clmtw85bUyQR+iIXszqKVw+X9bWsJG01Jt N+ZsTfV8julGU0OHBENNHcEvcEsoCbqLMahzYe6izQ/xKVIBZ1Mz7euj+jAyHILO5QXu gELbjpS+nmYoqAkpVgPtNOcuZvaGykA4jKEdQZd3sPXvj/vOT9ozoBQ1kvdwS05JFR8f E+xg==
MIME-Version: 1.0
X-Received: by with SMTP id iu1mr652165vdb.35.1395844073680; Wed, 26 Mar 2014 07:27:53 -0700 (PDT)
Received: by with HTTP; Wed, 26 Mar 2014 07:27:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 26 Mar 2014 10:27:53 -0400
Message-ID: <>
Subject: Re: URN UUID question
From: Joel Kalvesmaki <>
To: "Dale R. Worley" <>
Content-Type: multipart/alternative; boundary=bcaec547c6232c734504f5834660
Cc:,, Sandro Hawke <>
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, 26 Mar 2014 14:27:58 -0000

Thanks, Dale,

> From: Joel Kalvesmaki <>

> >
> > I would like people who do not own or have access to a domain name to be
> > able to mint names.
> The current tag scheme doesn't allow that, but it's fairly simple to
> get around that problem.  (Although it's difficult to imagine anyone
> who would use this system but not have an e-mail address.)  We need
> some person or enterprise that has a legitimate authorityName to
> delegate parts of its URI space to owners who do not have
> authorityNames.  So we could separate:
>,2014:delegations:person-A:[person A's string]
>,2014:delegations:person-B:[person B's string]
>,2014:delegations:person-C:[person C's string]
>,2014:delegations:person-D:[person D's string]
> We could probably set up an automatic delegation system much
> resembling how tag URIs are delegated by allowing each possessor of a
> telephone number a set of strings:
>,2014:delegations:17816479199,2014:[my string]
> would be automatically delegated to me because I possessed the use of
> that E.164 number on 2014-01-01.

My caveat on users' access to domain names wouldn't apply to email
addresses (I can safely assume users of this data model will have, at some
point, some email address), but your delegations idea is very interesting
to see.

> My concerns are akin to those that have motivated the architects of
> > Canonical Text Services[1][2][3] to develop the convention
> > "urn:cts:..." to provide names for ancient literary works, their
> > fragments, and their versions. their naming scheme stands
> > independent of server performance, etc. But it also can be easily
> > incorporated into registries that facilitate Semantic Web
> > applications.
> Good Lord, haven't they thought to properly register those schemes?  I
> don't see them listed in
> .

Sorry I can't speak to this, since I'm not using any CTS urns, and I wanted
to avoid creating a new urn scheme. I think what the architects have
published so far suggests that they still have work to do, esp. on defining
validity and developing rules for a registry (or explaining why no registry
would be needed).

Best wishes,

Joel Kalvesmaki