Fw: The Kitchen Sink Resource Record

["Jim Fleming" <[e-mail]>]

-----Original Message-----
From: Jim Fleming <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; Barbara Simons <[e-mail]>;
[e-mail] <[e-mail]>; [e-mail]
<[e-mail]>; [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>; [e-mail] <[e-mail]>;
[e-mail] <[e-mail]>; [e-mail]
<[e-mail]>; Adele Goldberg <[e-mail]>; [e-mail]
<[e-mail]>; [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>
Date: Friday, July 02, 1999 9:18 AM
Subject: The Kitchen Sink Resource Record


>@@@
>http://www.ietf.org/internet-drafts/draft-ietf-dnsind-kitchen-sink-00.txt
>
>Donald E. Eastlake 3rd   IBM   65 Shindegan Hill Road   Carmel, 10512 USA
>   Telephone:   [phone] (h)                [phone] (w)
>   FAX:         [phone] (w)   EMail:       [e-mail]
>
>"The Kitchen Sink Resource Record"
>
>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>
>
>Dear Mr. Eastlake,
>
>I have read your notes regarding your proposal to extend the repetoire of
>resource records in the domain name system. I have the following comments
>and/or suggestions.
>
>1. The editorial language used in your notes appears to be intended to
paint
>a picture whereby people interested in changing the domain name system are
>"seized with desire" and end up with "proprietary" or "complex" solutions
>that
>fall by the wayside, whereas your solution is (of course) less complex and
>handled
>with "reasonable care" under the IETF process. I think that it is important
>to point
>out that the kludge commonly called the DNS protocol and the coming
>super-kludge
>that will result when IPv6 extensions are added can all be attributed to
the
>IETF
>process. I think the results speak for themselves and do not match up with
>your
>editorial comments.
>
>2. You note that the TXT records are sometimes a catch all for arbitrary
>data.
>You seem to have omitted the fact that the AAAA records can now also be
used
>for small binary quantities. I believe that if you take an
"object-oriented"
>approach
>to this problem you will see that many Classes (i.e. Integers, Strings,
>etc.) can
>be mapped to the current DNS resource records. As an example, the 128 bit
>AAAA
>records can be structured as follows WITHOUT the addition of new resource
>records.
>An AAAA record can be combined with a TXT record to handle many needs.
>
><Class-ID:11><Version:5><Time-Stamp:48><Signature:16><Address:32><Port:16>
>
>http://www.unir.com/images/architech.gif
>http://www.unir.com/images/address.gif
>http://www.unir.com/images/headers.gif
>
>NOTE: Most serious object-oriented systems based on Smalltalk, C+@ or JAVA,
>produced
>to date, make heavy re-use of Classes and therefore 2,048 classes with up
to
>32 versions
>rotating through the development process have been found to be quite
>sufficient for
>many systems. Smalltalk and C+@ generally make heavy reuse of less than 512
>classes.
>I doubt if most programmers can remember 2,048 classes and use them
>effectively.
>
>3. As a representative of IBM, I am surprised that you have not referenced
>more
>recent leading edge work before producing your notes. For example, I do not
>think there
>was anything about ORBs. Also, it does not appear that you have consulted
>with the
>ICANN members to synchronize with their work in this area. I also suggest
>that you work
>with the ITU, the ACM and the IEEE in these areas. The OMG might also be a
>group that is
>interested. Since IBM is one of the leading vendors of Smalltalk, you might
>want to
>check with people at your company to get their views in this area. This
>would include
>the people that IBM is funding at ICAIR.
>
>In closing...you might note the words of Jon Postel of the IEEE...
>he apparently did not think it was useful for the IETF to be writing
>down everything...including the "Kitchen Sink"...
>
>@@@@ http://www.spectrum.ieee.org/select/1098/int.html
>
>"POSTEL: What's been happening over the last few years is
>that the IETF is filling the rest of the space with every alternative
>approach, not necessarily any better. Every possible alternative
>is now being written down. And it's not useful."
>
>@@@@@@@@@@@@@@@@@@@@@
>
>
>Jim Fleming
>Unir Corporation
>
>