Re: DNS based URI without any set access semantics?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]