ietf-mxcomp
[Top] [All Lists]

Re: Emotions, Encoding, and Ignorance (Was: Why not XML)

2004-06-23 12:56:05

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