> 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