On Thu, Jul 25, 2002 at 03:40:07PM -0400, Keith Moore wrote:
| 1. it doesn't matter whether the components are reversed or not.
| 2. you do need a date, because domain names change hands.
| 3. it's not a good idea to embed any more human-meaningful content
| in a URN than necessary to get uniqueness.
Great!
| URN:dns:f.q.d.n:date:unique-suffix
How about...
urn:dns:f.q.d.n,year;unique-suffix
where ;unique-syntax is optional
| f.q.d.n fully-qualified domain name
Yes. And to make sure that these thingys can be compared
via strcmp, the f.q.d.n should be using only lower-case letters.
| date date in the form YYYYMMDD (exactly 8 digits)
I was thinking just a year as most registries renew once
a year. In particular, how about allowing a person to use
year YYYY if they are the valid domain name holder at
exactly midnight January 1st of that year.
| unique-suffix a suffix that is uniquely and permanently assigned to a
| particular resource. it's strongly recommended that this
| be a string of digits or other meaningless ascii characters
| rather than a human-meaningful string.
I see no problem with it being human readable. The point is
that there isn't a protocol associated with the URI, not that
it is a pain to remember. If it is a pain to remember, no one
will use it. In this case, why even use DNS? The problem is
that I need globally unique URIs that are easy to remember and
that don't imply a particular protocol, like http.
| I'm tempted to suggest that the f.q.d.n:iso-date portion be hashed with MD5
| and encoded in base64, just so that the URN doesn't pretend to have any
| semantics associated with it. but if we leave the DNS name intact then
| it's easier to build a resolver for it that uses DNS. that's also why
| I would like to see the date be an exact length - it's easier (though
| still ugly) to match date ranges in NAPTR records that way.
See above. I hope the year suggestion works for you.
Clark
--
Clark C. Evans Axista, Inc.
http://www.axista.com 800.926.5525
XCOLLA Collaborative Project Management Software