Subject: Re: New RR for DNS - GLOC

From: Jerry Scharf <[email-masked]>
Date: Tue, 29 Jun 1999 12:02:52 -0700 (PDT)

I think this kind of information is best done in TXT records. The format
is arbitrary (what are the rules from country to country for the form and
meaning) and it still requires that you look up some external database
and covert it to lat and lon to display on the map. IMO, with the external
lookup, this looks like it belongs in other places besides DNS.

Why not write a tool that took the inputs that you like and generate LOC
records, which have a universal and immediate use? If you want to store
the source of the data for the LOC in TXT records, that is certainly
possible. You can hide the LOC records from the user and free all the
applications from having to do the coversion.

jerry

---

From: Michael Mealling <[email-masked]>
Date: Tue, 29 Jun 1999 19:06:48 -0400 (EDT)

Jerry Scharf said this:
> meaning) 

This has recently been standardized in a new 2nd section for ISO 3166
that specifies country subdivisions as a 3 letter code that is unique
within each country code. The issue now is breaking it out of the
strangle hold that ISO has on it. There are several other candidate standards 
out there that can be extended for international geopolitical identification.

> and it still requires that you look up some external database

In many cases though the important information is not the lat/long but
the geopolitical location of the node. You might want to convert that
to lat/long to display on a map but displaying maps is simply one application.

> applications from having to do the coversion.

In order to do that you would require the user to attempt to standardize
the content of a TXT record so that he/she could tell their content
from other TXT records. We went through this with NAPTR and TXT just isn't
standardized enough to rely on. If the content can be standardized and 
it can fit in the packet size why not make it an RR? Or at the least
use the kitchen sink type (which I have no idea what the status is).

-MM

> Date: Tue, 29 Jun 1999 23:14:44 +0100
> From: "Matthew Dolan" <[email-masked]>
> To: OpenTransportDev <[email-masked]>
> Subject: Problems connecting
> 
> Hi all,
> 
> 
> When I use the below code, it doesn't connect up properly.
> 
> OSStatus ConnectUp(void)
> {
>  OSStatus err = kOTNoError;
>  long flags;
> 
>  gOTPPPEndpoint = NULL;
>  gIsOTPPPConnected = false;
> 
>  err = InitOpenTransport();
> 
>  if (!err)
>   gOTPPPEndpoint = OTOpenEndpoint(OTCreateConfiguration(kPPPControlName), 0,
> NULL, &err);
> 
>  OTInstallNotifier(gOTPPPEndpoint, OTPPPNotifier, NULL);
>  err = OTIoctl(gOTPPPEndpoint, I_OTGetMiscellaneousEvents, (void*)1);
> 
> 
>  OTSetAsynchronous(gOTPPPEndpoint);
> 
>  OTIoctl(gOTPPPEndpoint, I_OTConnect, NULL);
> }
> 
> It connects to the server but gets no further. Some connection stuff is
> still to be done but the above doesn't seen to do it.
> After running the above code, and then running an internet application the
> PPP connection dialog reappears and it finishes the job off (from Starting
> PPP I think).
> 
> What else should be done so that it connects up to the internet fully.
> Should a TEndpoint be specified? And if so, what should go in it. Is the
> OTSetAsync causing all the problems. I want the connection to happen in the
> background as such (i.e. no PPP connection dialog appearing).
> 
> 
> Please help because I have little OT knowledge and have found no decent help
> anywhere else. I haven't found any good sources of source code, so if you
> know of anyplaces please could you tell me where to look.
> 
> 
> Thanks all,
> 
> Matt
> [email-masked]
> 
> ------------------------------------------------------------------------
> eGroups Spotlight:
> "Egg and Egg Products" - There's more to eggs than eating them for
>  breakfast! If you are a producer or a user this group is for you.  
>  http://clickhere.egroups.com/click/114
> 
> 
> eGroups.com home: http://www.egroups.com/group/open-transport-dev
> http://www.egroups.com - Simplifying group communications
> 
> 
> 
> 

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Wed, 30 Jun 1999 13:30:07 -0400

> lookup, this looks like it belongs in other places besides DNS.

General question: my sense has been that putting stuff in TXT records
is OK if the intent is for humans to read it.

It is much more dubious to put stuff into TXT records when the
intention is to have programs parse them and extract
information. Reasons include:

1) strange things happen since TXT records can contain anything --
folks will start looking for them expecting them to contain certain
info...

2) Success would not necessarily be a good thing. If widescale
deployment takes place, things get more out of hand. Especially if
multiple different uses become popular. I.e, the point of having
different RR types is so that you get exactly the info you want, not a
bunch of extra stuff you have to filter out.

3) The main reason folks want to use TXT reasons is that they are easy
to deploy (i.e., deployed nameservers support them). Seems to me that
name servers could also be designed to allow the definition of
arbitrary RR formats (i.e, by having a simple langauge for describing
the format of new RRs). Heck, even allowing a binary format would work
-- one could have preprocessing tools that take a human readable
definition of RR contents and translate them into a generic format the
nameserver could input.  Folks could then create new RR types and
deploy them without requiring new nameserver software
implementations. This would make it simpler to experiment with new RR
types, which wouldn't be a bad thing.

Finally, last I checked, RR types were 16 bits long, and we've used
only a miniscule fraction of them. I don't think we need to be
particularly conservative in their usage. We should encourage use
where appropriate.

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Jun 1999 15:27:30 -0400

> folks will start looking for them expecting them to contain certain

In fact, the first time I ever heard of TXT records was with hesiod -
the Athena distributed registration database - and the meaning of the
record was encoded in the name used to find it - for example, hesiod
would store a (passwordless) unix password database as a sequence of
records with names like 1029.uid.passwd.foo.com and
mellon.username.passwd.foo.com (I am certain I have the exact naming
scheme wrong, but this is the general idea).

> bunch of extra stuff you have to filter out.

Very true.   It's easy to imagine a situation where two networked
password database systems that use TXT records could clash with one
another, for example, although this is probably more likely for other
applications.   At a minimum, if a scheme like this were to be used,
it would be necessary to set up a registry of application-specific
subdomain names.

> Seems to me that name servers could also be designed to allow the
> definition of arbitrary RR formats (i.e, by having a simple langauge
> for describing the format of new RRs).

This is probably true, in theory.

> Heck, even allowing a binary format would work -- one could have
> preprocessing tools that take a human readable definition of RR
> contents and translate them into a generic format the nameserver
> could input.

It is almost never useful to store things in a binary format like
this.  The time saved is not large, and the complexity it adds _is_
large, particularly if you have to have a standard that says how it
works.  I'd really hate to see another instantiation of ASN.1 in the
DNS, for example.

> particularly conservative in their usage. We should encourage use

Famous last words.   16 bits is a *tiny* address space.   It's really
easy to imagine 64k new applications coming out before the DNS is
otherwise obsolete, and this would force obsolescence upon it.

Personally, I think TXT records are a fine solution to the problem of
storing arbitrary new information into the DNS.  If we used RR types
in the way you describe, we'd need the IANA to apportion the address
space.  Why not just ask the IANA to register application-specific
subdomain names that can be used with TXT records, and refer to RFCs
documenting the use of such domain names?  If we require that this
sort of usage be accompanied by a standards document that's reached a
certain level, this shouldn't impose a very large burden on the IANA.

			       _MelloN_

---

From: Rob Austein <[email-masked]>
Date: Wed, 30 Jun 1999 16:30:48 -0400

I mostly agree with Thomas about the inadvisability of doing this sort
of thing via TXT RRs.

As Thomas says, TXT RRs are ok when they're intended solely for human
beings to read.

TXT RRs are also ok when they're in a portion of the DNS namespace
that has been set aside for a particular purpose, so that they cannot
be confused with "ordinary" records.  Eg, if I were to build an
OID-to-URL mapping database at OID.HACTRN.NET, I could use TXT RRs
with rigorous internal structure in that tree, since it's my tree and
the TXT RRs in it mean whatever I say they mean.  If I were expecting
this to become an Internet-wide service, it might make more sense to
define a new RR type anyway, but for small test cases or special
purpose hacks it may not be worth trying to standardize a new RR type.

TXT RRs are -not- a good idea when (a) they're mixed into the "main"
naming tree and (b) depend on any kind of uniform interpretation.  Eg,
mixing my OID-to-URL TXT RRs with Jerry's host-to-location TXT RRs is
a bad idea, and depending on knowledge of current host naming
conventions to avoid collisions is not a good idea either, since such
rules do change over time, albiet slowly.

If you're trying to build an Internet wide service, standardize a new
RR type, that's what the type code is there for.  Feel free to define
it in such a way that it looks just like a TXT RR if you really don't
need any more structure, that way you can reuse all the existing code
to handle TXT RRs.  But don't try to impose new semantics on existing
types in the main tree, it'll just lead to confusion.

Thomas's point about using the type code to get exactly the RRs you
need is also well-taken.  Every few years somebody comes up with a
scheme that boils down to putting some kind of sub-type code into the
RDATA of an RR, so that we won't have to allocate new types.  Such
schemes are understandable, but misguided.  If two conceptual kinds of
RRs can be used independently, they should have distinct type codes.

--Rob