Could binary encoding really be the answer?

Team-

I am sending my third and final message of the day, in order to express 
support for Hadmut's suggestion of a binary encoding.  I think this is a 
good idea, and I believe it combines the best of various worlds 
(extensibility, economy, etc).
Here are some highlights.

1. Records can be composed in SPF, XML, or with a wizard.  Whatever the 
input, the DNS format transmitted over the wire is a binary encoding.  MTAs 
need to understand the binary and that's it.
2. DNS servers are not required to read other format, but they can.  If 
they do, you can enter either SPF or XML text in the zone file.  DNS tools 
like dig can display one or both formats.
3. The new binary format applies to the new MARID RR.  I would probably 
want to keep using SPF format in the TXT records in the short term, because 
I'm not entirely sure of my ability to type binary data into a zone file. 
TXT records in SPF format are referred to as "legacy format" records.  Use 
of TXT records may be deprecated at some future time when the new RR is 
widely available.
I think this allows for extensibility and reuse of other standards, like 
the XML team wants, and it also allows for byte economy like the DNS core 
folks want, and MTA independence that the MTA writers want.

I am not sure how Microsoft is going to like this proposal... on the one 
hand we are approving XML for use in composing the records, which is good, 
but on the other hand we are defining a new RR and MS needs to fix their 
servers to understand the new RR.  This can take however long it's going to 
take, and the TXT record is available now, but not in XML.
The way I see it, it will be tough for MS to have it both ways: they are 
probably not going to win approval for a new data format (MARID XML) AND 
also avoid the work of deploying a new RR.
Feedback?  Comments?  Flames?


Hadmut's previous message any my previous reply follows here (in case you 
were ignoring the other thread :)

--Greg Connor <gconnor(_at_)nekodojo(_dot_)org> wrote:

> --Hadmut Danisch <hadmut(_at_)danisch(_dot_)de> wrote:
>
> > After spending a few more minutes to thing about it, I'd currently
> > propose this (which, I admit, would also require the gods of DNS to
> > move a little bit forward to accept it):
> ...
> > An MTA would receive the record as it is, as a bit/byte sequence.
> > DNS does not care about it's structure. The MTA then simply passes
> > this record to the MARID interpreter, together with other parameters
> > (peer IP address, sender address,...). The MARID interpreter then
> > disassembles the ASN.1 encoding.
> >
> > This way anything is completely covered in the MARID interpreter.
> > All DNS parts don't depend on any detail.
>
> I would agree with this.  I like the idea of being able to go forward
> without waiting for DNS upgrades.
>
> Given a choice I would probably lean toward the TXT record being one of
> the human-readable representations, and the new RR being the "binary"
> form, but I don't have a strong feeling and I'm willing to be talked out
> of it :)
>
> Question for the DNS/bind gurus out there.  Is it possible to put stuff
> in your zone file using TYPE1234 notation, even if the bind version
> doesn't support it?  We would probably want to go with TXT at first but
> when we have an RR type it would nice to start using it... I'm not sure
> if this is possible.
>
>
> > Now give it eye sugar:
> >
> > Allow the DNS encoder (i.e. bind reading the zone file) to not only
> > understand base64 text representations, but also other
> > representations, like SPF, XML, or whatever future might bring.
> >
> > In the same library, allow MARID records to be converted into
> > any of a list of representations: base64, SPF, XML.
> >
> > This way, it will *always* work with base64. That's the fallback
> > solutions. If you can't upgrade your DNS software, it will always work.
>
> Good.  Also, when we get around to publishing a new RR and rolling
> support for it into various DNS servers, we can make a recommendation for
> other "additional" records that can be stuffed in the response packet.
> For example, if the a: mx: or include: mechanisms are used, the
> additional section could include the A, MX, or other MARID record in the
> first reply packet.  This is of course optional for the DNS server, but
> as long as we are working on a new RR in DNS we might as well make
> recommendations on additional records too.
>
>
> > If you extend the MARID records, it depends on wether the extension
> > is marked critical or not (see my former posting). Non-critical
> > extensions allow slow upgrades. Or even no upgrades.
> >
> > And then you have time to extend SPF or XML syntax and upgrade
> > the conversion library. Until then, base64 always works. Just hack
> > a perl script to encode new record types.
>
> Good stuff.  Thanks.
>
>
> --
> Greg Connor <gconnor(_at_)nekodojo(_dot_)org>


--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>