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(_dot_)Kletnieks(_at_)vt(_dot_)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