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
better to make it required; it encourages more responsible behavior.
you don't want people creating a new prefix for each new URN.
at least not if you ever hope to make these things resolvable.
| 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.
fine.
| 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.
the year is not precise enough as domain ownership doesn't change on
year boundaries, and domain ownership can change more than once in a
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.
you're trying to use the wrong tool, then. URNs are intended to to be
globally unique and to keep their bindings forever. making them human
meaningful degrades their ability to fulfill that function, because
the meaning of human languages changes over time.
the reason for using DNS is that they're globally unique (at a
particular time) and people already understand them and often
know how to get a DNS name. also with DNS names there is some
potential for using DNS to resolve URNs with those names - at
least those for which the domain name holder at the time the
URN was assigned is currently the holder of that domain name.
| 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.
sorry, no.
Keith