Subject: DNS based URI without any set access semantics?

From: "Clark C . Evans" <[email-masked]>
Date: Thu, 25 Jul 2002 11:48:27 -0400

IETF Gurus,

I'm looking for a URN scheme that uses DNS for uniqueness (perhaps in 
conjunction with a date) but doesn't have any attached semantics.  I'm 
asking this beacuse XML has the "duck" problem.  It uses URIs for 
namespace names, but only the URI syntax (for uniqueness), thus you see 
lots of http:// namespace names but the author never intended to support 
the retrieval of content given the namespace name.   Anyway, this is icky.
What XML really wanted was a URN that is based on DNS.  As it turns out
YAML (http://yaml.org) has exactly the same situation, only we are in
a position to do this correctly.  So, I was thinking something like...

  dnsurn://clarkevans.com/2002/my-data-type#my-format

Thus, the scheme follows *exactly* the syntax of HTTP (to keep learning
curve down) only that the date is required immediately following the
domain name.  The advantage of this over http is that it doesn't look
like a duck... "dnsurn" is not "http".  A further advantage is that
someone can use everything to the right of the dnsurn: as a http: URL
if they wish by just replacing the scheme.

I'm completely dogged for time... if something like this is possible
how hard would it be?  I'm not looking forward to having the equivalent
of "XML namespaces considered harmful" threads on our YAML list and
thing something like this would serve to help not only YAML but also
XML...

Best,

Clark

---

From: Michael Mealling <[email-masked]>
Date: Thu, 25 Jul 2002 12:07:19 -0400

> thing something like this would serve to help not only YAML but also

It sounds like you want the 'duri' namespace currently going through the
process. It was written by Larry Masinter and is currently here:

http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-03.txt

The URN is of the form: urn:duri:<date>:<encoded-URI>

Examples:

urn:duri:2001:http://www.ietf.org

urn:tdb:20010814142327:file://this.example.com/c|/temp/test.txt

urn:tdb:2001:data:,The%2520US%2520president

etc...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: "Clark C . Evans" <[email-masked]>
Date: Thu, 25 Jul 2002 13:11:54 -0400

On Thu, Jul 25, 2002 at 12:07:19PM -0400, Michael Mealling wrote:
| > 
| >   dnsurn://clarkevans.com/2002/my-data-type#my-format
| > 
| > Thus, the scheme follows *exactly* the syntax of HTTP (to keep learning
| > curve down) only that the date is required immediately following the
| > domain name.  The advantage of this over http is that it doesn't look
| > like a duck... "dnsurn" is not "http". 
...

| The URN is of the form: urn:duri:<date>:<encoded-URI>
| 
| urn:duri:2001:http://www.ietf.org
| urn:tdb:20010814142327:file://this.example.com/c|/temp/test.txt
| urn:tdb:2001:data:,The%2520US%2520president

Hmm.  If the above proposal is too "close" to http, then formalizing
java "package" names as URI would be useful...

  package:com.clarkevans.MyDataType

The end goal is (a) to have a DNS based URN and (b) not have this
URN imply any sort of access mechanism (http,https,ftp,news,etc.)

Best,

--- 
Clark C. Evans                   Axista, Inc.
http://www.axista.com            800.926.5525
XCOLLA Collaborative Project Management Software

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Jul 2002 13:35:08 -0400

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 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.

Keith

---

From: "Clark C . Evans" <[email-masked]>
Date: Thu, 25 Jul 2002 12:28:52 -0400

On Thu, Jul 25, 2002 at 12:07:19PM -0400, Michael Mealling wrote:
| >
| >   dnsurn://clarkevans.com/2002/my-data-type#my-format
| >
|
| It sounds like you want the 'duri' namespace currently going through the
| process. It was written by Larry Masinter and is currently here:
|
| http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-03.txt
|
| The URN is of the form: urn:duri:<date>:<encoded-URI>

Thanks Michael.   This looks a bit too noisy for me; I'm just
looking for something that I can replace "http" with no other
changes to that the duck stops quacking.   This proposal is
very noisy and probably woudn't be adopted by XMLers or YAMLers.
Further, the / is reserved within URNs and thus would need to
be escaped no?

Also, the date is the least important part (this can be removed
from the proposal).  I'm just looking for something which allows
for absolute http uris (with fragments) to be used excepting "http"
is replaced by something else so that the unique identifier can
be used without bringing along the http semantics.  Lastly, since
http occurs within urn:duri:2002:http://yaml.org/somewhere, this
doesn't solve my "urn without semantics" issue since the http is
still there.

Hmms.

Clark

---

From: "Clark C . Evans" <[email-masked]>
Date: Thu, 25 Jul 2002 15:29:33 -0400

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?

   urn:dns:com.clarkevans:MyPackage

Where the first three components are always small caps.

Best,

Clark

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Jul 2002 15:40:07 -0400

> 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

---

From: Michael Mealling <[email-masked]>
Date: Thu, 25 Jul 2002 15:48:29 -0400

> Where the first three components are always small caps.

The problem is that URNs are required to be non-reasignable. So if 
the part between the second and third colons is based off of a domain-name
then you will have to timestamp it somehow.

-MM

---

From: "Clark C . Evans" <[email-masked]>
Date: Thu, 25 Jul 2002 16:34:37 -0400

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

---

From: "Clark C . Evans" <[email-masked]>
Date: Thu, 25 Jul 2002 16:36:22 -0400

On Thu, Jul 25, 2002 at 03:48:29PM -0400, Michael Mealling wrote:
| > 
| >    urn:dns:com.clarkevans:MyPackage
| > 
| > Where the first three components are always small caps.
| 
| The problem is that URNs are required to be non-reasignable. So if 
| the part between the second and third colons is based off of a domain-name
| then you will have to timestamp it somehow.

Ok, would this fly? 

    urn:dns:yaml.clarkevans.com,2002;MyPackage

Thank you both for humoring me.  YAML needs something clean
like this for its type identifiers.

Best,

Clark

---

From: Michael Mealling <[email-masked]>
Date: Thu, 25 Jul 2002 16:39:12 -0400

> like this for its type identifiers.

I would prefer the NID be something other than 'dns'. As it stands
it suggests that it in some way related to DNS when it really isn't
except for the firs section. But 'pkg' doesn't seem right either since
that suggests Java packages instead of what YAML wants to do with 'em.
Got any other suggestions?

-MM

---

From: "Clark C . Evans" <[email-masked]>
Date: Thu, 25 Jul 2002 17:08:45 -0400

On Thu, Jul 25, 2002 at 04:39:12PM -0400, Michael Mealling wrote:
| On Thu, Jul 25, 2002 at 04:36:22PM -0400, Clark C . Evans wrote:
| > Ok, would this fly? 
| > 
| >     urn:dns:yaml.clarkevans.com,2002;MyPackage
| > 
| > Thank you both for humoring me.  YAML needs something clean
| > like this for its type identifiers.
| 
| I would prefer the NID be something other than 'dns'. As it stands
| it suggests that it in some way related to DNS when it really isn't
| except for the firs section. But 'pkg' doesn't seem right either since
| that suggests Java packages instead of what YAML wants to do with 'em.
| Got any other suggestions?

Right on.  Hmm.  I suppose at the very worst we could use "yaml".
But something a bit more generic (so XML fellas can use it too)
would be preferable.

ideas:

  type
  domain 
  inet   (internet)
  zoom   (just for fun)
  dbi    (domain based identifier)
  dbn    (domain based name)
  nmsp   (namespace... although I don't like this as much)
  rdns   (reverse dns ... urn:rdns:com.clarkevans.yaml,2002;MyPackage)
  class  (object's class)
  dnscls (domain name system class )

Buggers.  This is tough.

Clark

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Jul 2002 17:22:03 -0400

> 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.

>   via strcmp, the f.q.d.n should be using only lower-case letters.

fine.

>   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.

> 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.

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.

> See above.  I hope the year suggestion works for you.

sorry, no.

Keith

---

From: "Clark C . Evans" <[email-masked]>
Date: Thu, 25 Jul 2002 18:28:24 -0400

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, [email-masked] 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

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Jul 2002 18:28:25 -0400

> Ok.  How about just YYYY iff YYYYMMDD would be YYYY0101

I don't like it;  it makes it harder to parse with NAPTR.

> Yes, but this is what the date does.  It means what it did 

no. the date is just there to disambiguate multiple uses of the same
dns name by different assignment authorities; it says nothing about
the resource at all, not even when the name was assigned.  if I had 
owned the name indecency.org on March 15 1995, and had subsequently 
given up ownership, I could still assign names using 

urn:dns:indecency.org:19950315:suffix

even if I no longer owned the name.

(though I can imagine that IPR lawyers would strongly object ...
which might be an argument in favor of encoding the name+date with
MD5, or it might be an argument in favor of shooting IPR lawyers...
or both.)

> identifier is up to them.

not if it's a URN; there are restrictions on how URNs are to be used.

> So do we need a mechanism to specify which DNS roots someone is using?

NO.  nothing stops people from reusing URNs; they're just violating
protocol if they do so and in turn violating the assumptions made by
people and software that rely on the properties of URNs.  similarly 
nothing stops people from setting up their own DNS roots, they're just 
violating the DNS protocol if they do so, and they're violating the 
assumptions that a tremendous amount of software and a huge community 
of users rely on.  

trying to define a protocol for people who insist on violating protocols 
is a fools' errand.

Keith

---

From: "Clark C . Evans" <[email-masked]>
Date: Thu, 25 Jul 2002 19:24:20 -0400

On Thu, Jul 25, 2002 at 06:28:25PM -0400, Keith Moore wrote:
| > | 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 don't like it;  it makes it harder to parse with NAPTR.

Ok.

| not if it's a URN; there are restrictions on how URNs are to be used.

Ok.  Perhaps I'm barking up the wrong tree

On Thu, Jul 25, 2002 at 03:45:16PM -0700, Ted Hardie wrote:
| > 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.
|
| And this is why you're seeing pushback.  Knowing what the tool is
| going to be used *for* gives you a shot at making a good tool.  Making
| a tool out of a certain substance without knowing how the tool will be
| used may very well produce sub-optimal results.  A glass hammer may be
| asthetically pleasing, but it probably won't be too good when you're
| ready to pound your nails.
|
| It sounds like you really do have a serious use case:  identifiers for
| YAML.  Writing up that use case may very well help you or others
| develop a good tool.  It might even be the case that the tool references
| the DNS.  But starting with "uses the DNS" doesn't seem like the
| right road to reaching "good tool".
|

Thanks.  Focus is good.  Let's stick to YAML's specific requirements,
sorry for attempting to generalize too soon.

YAML is a data serialization language.  It serializes, in a language
independent manner objects from various languages, including but not
limited to java, python, ruby, perl, COM, etc.  As part of an object's
serialization, it saves the component parts (data) as well as the 
object's type (class/package/etc.) in an text format.

Thus, I'm looking for a clean way to uniquely write "type" names 
across a great deal of languages with many internal ways that they
express their own object type names.  Ideally, this would allow a 
for each language's typing to be represented in a recognizable manner.
Also, there are some "types" which seem to be universal across languages,
such as integers, strings, etc.

Perhaps someting like a two-level mechanism would work...
  
  pkg:java:com.clarkevans.package.MyClass   # Java's reverse DNS package
  pkg:perl:Data::Denter                     # Perl's CPAN package
  pkg:python:yaml.loader                    # Python's package (not DNS)
  pkg:*:integer                             # language independent

Something like this would be even better than a simple DNS
hierarchy; although it would be more work as each language
would have to be defined with a specification of what sort
of sub-package is allowable.   It would be _alot_ of work,
but I think that this is a critical component of YAML (and any
cross-language system) so I'm willing to put forth the effort. 

Thoughts?

Thank you all (Michael/Ted/Keith) for helping me thus far.

Clark
Yo! Check out YAML, http://yaml.org 
Serialization for the masses

---

From: "Clark C . Evans" <[email-masked]>
Date: Fri, 26 Jul 2002 10:07:35 -0400

On Fri, Jul 26, 2002 at 12:44:01AM -0700, Bill Fenner wrote:
| How about the "tag" URI?  draft-kindberg-tag-uri-02.txt
| 
|    This document describes the "tag" Uniform Resource Identifier (URI)
|    scheme and the "tag" Uniform Resource Name (URN) namespace, for
|    identifiers that are unique across space and time. Tag URIs (also
|    known as "tags") are distinct from most other URIs in that they are
|    intended for uses that are independent of any particular method for
|    resource location or name resolution. A tag URI may be used purely as
|    an entity identifier.

Neat.  And it looks like it is making progress.
http://lists.w3.org/Archives/Public/uri/2002May/0010.html

This is definately what I was initially after, sorry for all
of the traffic.  I'm wondering if the language uri is worth
the effort to formalize; ponder.  

Thank you so much!

Clark

---

From: Bill Fenner <[email-masked]>
Date: Fri, 26 Jul 2002 00:44:01 -0700

How about the "tag" URI?  draft-kindberg-tag-uri-02.txt

   This document describes the "tag" Uniform Resource Identifier (URI)
   scheme and the "tag" Uniform Resource Name (URN) namespace, for
   identifiers that are unique across space and time. Tag URIs (also
   known as "tags") are distinct from most other URIs in that they are
   intended for uses that are independent of any particular method for
   resource location or name resolution. A tag URI may be used purely as
   an entity identifier.

  Bill