Subject: DNS container objects & virtual data types

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 21 Jan 2005 08:08:01 +0100

DNS container objects
=====================
Disregarding the discussion about overloading, misuse etc. I suggest
that DNS RRs objects that does not have defined semantics, which today
spells TXT and later will include XML and BINary as well, should merely
be regarded as "container objects".

Container objects' sole mission is to hold external representations of
objects associated with virtual DNS data types.

DNS virtual data types
======================
A "virtual" DNS data type is a data type that is identified by a unique DNS 
label-set, preferably in the form of a translated URI.  Virtual data types
- Have globally unique names
- Do not rely on a particular registry
- Are equally applicable to private and public data types
- Can be used instantly
- Operate at the same speed as intrinsic DNS data types

[arg,]unique-name[.arg]    container-type   external-representation

Due to the fact that virtual data types are compatible with the existing
DNS infrastructure, there is nothing to "solve" or overcome, except
maybe some mental hurdles.  It seems that three different external
representations should cover most real-world applications.

It is important to note that this scheme is by no means new, it is simply the
de-facto standard in a documented and to some extent refined format.

Anders R

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 21 Jan 2005 21:59:33 -0500

>DNS container objects
What about the problem of scalability? If everyone uses these "container 
objects" to describe data specific to their particular app, and the 
"container objects" show up under a limited number of RR types, then 
every app client is going to have to wade through every other app's 
"container objects" of that "container-type" to find the particular ones 
that they require. Surely this is far less efficient than having 
different RR types that apps can query specifically.

Also, how are "collisions" -- a container object whose external 
representation appears to belong to one app, even though it is actually 
belongs to a different app -- to be prevented, in the absence of some 
sort of central registry?

                                              - Kevin

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 22 Jan 2005 07:16:46 +0100

>different RR types that apps can query specifically.

This assumes that your queries are of the type *.domain.
Using more targeted selections you should only get your own stuff.
More to read:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00150.html

>sort of central registry?

It is good that you brought up this issue.  If you look what the CSV people
have done you will note that they in addition to redefining an "intrinsic" DNS
type (SRV), also have made the "unusual" words _client and _service 
become *reserved*.  I.e. the central registry did not prevent these guys from
screwing up at all!!!  The IETF has no law enforcement arm.

If you name your objects with URIs (translated) there is a good chance
that they will be app-specific as it does not make sense for other
developers to hijack your URI.  If they do it will only affect their own
community.  URIs have become the de-facto way of separating definitions
on the Internet so I don't think we have a problem.  What always is
a problem is to parse data created by another party (DNS admin).
Using XML objects this will be slightly simpler.   XML is though just
one of the options.  BINary is another.  Maybe a real STRing
(UTF-8) would fill out the selection if container objects?

A thing that also is much better catered for by virtual types is versioning.
Complex systems evolve and that often calls for a revised data object.
Using a virtual data type you give the revised type a new URI and
then apps may look for the highest version first and then go down
until there is a match.  Caching this info limits the need to do this
all the time.  SPF's solution to this problem is simply horrible.

The DNS type stuff is a *very* dated design.  It is about time to take
DNS into the 21st century!

believes at least
Anders

---

From: John Levine <[email-masked]>
Date: 22 Jan 2005 17:45:09 -0000

>It is good that you brought up this issue.  If you look what the CSV
>people have done you will note that they in addition to redefining an
>"intrinsic" DNS type (SRV), also have made the "unusual" words
>_client and _service become *reserved*.  I.e. the central registry
>did not prevent these guys from screwing up at all!!!  The IETF has
>no law enforcement arm.

Aw, come on.  If CSV heads down the standards track, we'll arrange to
register the names it uses, or maybe to switch to appropriate names
that are already registered if there are any.  I would have thought it
would be obvious that first you do the experiments, then you register
the names they use if the experiments look promising.  We think CSV is
swell, but nobody's used CSV enough to know if there are horrible
gotchas that we haven't discovered yet.

> A thing that also is much better catered for by virtual types is

I think it's a feature of DNS that versioning is hard.  The more
versions of something that simultaneously exist, the less likely it is
that implementations will interoperate reliably.

R's,
John