Re: Could binary encoding really be the answer?

Greg,
I agree that this sounds like a workable plan. This along an extremely 
similar line of thinking as what led me to my compromise proposal sent 
this morning. You have however expressed many of the points much more 
clearly. I have a few comments below where I believe a slightly 
different path is at least worthy of discussion.

Greg Connor wrote:

> 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.
Works for me. But since even in the current XML most records are still 
smaller than 512 bytes it would probably be worthwhile to explore 
exactly how much network traffic this really saves if for no other 
reason than to enhance the sales pitch to DNS admins who now have to 
create these records.
> 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.
Is this implying that DNS servers should store both formats and 
selectively translate them to their binary representation or that if the 
DNS server is doing the translation it is up to tools like dig and 
nslookup to do the translation back to human readable?


> 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 would suggest that since in your proposal TXT is used as transitional, 
and in mine the TXT is used for experimental new extensions that it 
would not be unreasonable for that record to support both formats, 
especially since as soon as their MTA and DNS software support it a 
system can use the standardized, binary formatted MARID record directly.

> 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?
I think the success of this group in creating a standard will depend on 
all of the various stakeholders being willing to compromise and do a 
little more work than they might strictly like to. The above approach 
seems reasonable to me.
This is just my two cents. Thanks for the clear write up.

To the group in general I will say that while I was a bit disheartened 
over the last few days over the heated and sometimes circular 
discussions, the willingness to compromise which I have seen today has 
done a great deal to raise my hopes again.

Thanks,

Robert

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