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