On Thu, Jul 25, 2002 at 05:22:03PM -0400, Keith Moore wrote: | > 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. | > | > 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. Ok. | > | 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. Ok. How about just YYYY iff YYYYMMDD would be YYYY0101 | > 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. Yes, but this is what the date does. It means what it did on the date specified. | 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. Exactly. I'm just after a simple thing; a DNS based identifier that isn't associated with a given protocol. How people use the identifier is up to them. On Thu, Jul 25, 2002 at 05:25:37PM -0400, Keith Moore wrote: | NIDs should really be opaque also, unless they're being used to grandfather | in some other URN-like namespace (such as ISBNs). You don't want these | things to have a meaning. Is this a concensus within the itef? *boggles* Ok, how about "dam", e.g., urn:dam:clarkevans.com,20020302;my-type dam ain't meaningful *grins* On Thu, Jul 25, 2002 at 05:25:53PM -0400, Valdis.Kletnieks@vt.edu wrote: | > On Thu, Jul 25, 2002 at 01:31:11PM -0700, Karl Auerbach wrote: | > | That's not a solid foundation for uniqueness. There are multiple DNS | > | spaces in use. One is almost completely dominant, but others do exist | > | > It's good enough. | | OK... why do we want to datestamp it in case it changes owners, but | it's "good enough" to discard the existence of alternate DNS roots? So do we need a mechanism to specify which DNS roots someone is using? Is this overkill? On Thu, Jul 25, 2002 at 02:36:05PM -0700, Ted Hardie wrote: | There are a lot of "does this match that" rat holes | here. as an example, are: | | pkg://clarkevans.com./ and pkg://clarkevans.com/ | | pkg://clarkevans.com/data-type and pkg://clarkevans.com/data-typ%BC Oh bother. Thanks. Yep, for the identifier to be useful it should only encode when absolutely necessary and it should be lower case if at all possible. | The URI mailing list may be a better home. Quite right. Sorry if my ignorance lead to the wrong list. Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software