> On Thu, Jul 25, 2002 at 01:35:08PM -0400, Keith Moore wrote:
> | ick. please don't embed URIs in URNs. that will just tempt people
> | to use the embedded URIs and not treat them as URNs.
>
> I'm not set at all on using URIsh syntax. I just thought
> it'd be the easiest approach.
>
> | I can see wanting to have a URN that's based on DNS, but there shouldn't
> | be any expectation that you can derive a URI from the URN just by
> | modifying the syntax. that defeats the whole purpose.
>
> Great. So, should this thingy be a URN NID? How about using
> reverse DNS, aka Java package names?
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.
my offhand proposal would be:
URN:dns:f.q.d.n:date:unique-suffix
f.q.d.n fully-qualified domain name
date date in the form YYYYMMDD (exactly 8 digits)
it can be any date that the DNS name was officially
registered to the party assigning the name.
it is recommended that the same date should be used
consistently for all URNs issued under that domain
by that domain holder. one way to do this is to
use the date of initial registration.
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'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.
Keith