ietf-mxcomp
[Top] [All Lists]

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

2004-06-23 11:25:05

Greg Connor wrote:


Excellent idea.  Let's move forward with that.

What would you think about, for ease of deployment pre-bind-10, maybe having the TXT record be SPF format and the _ep record being XML format? I'm just concerned that people will not be able to type binary into their zone files.



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

MARID records in DNS should be encoded as raw bit/byte sequences. I would
keep the encoding out of the DNS internals. If it has not structure, then
DNS relays and caches do  not have to de- and reencode (what they do,
why I had to learn that my early RMX proposals, which made use of
DNS compression, would not work). Keeping the record opaque for
DNS internals keeps the processing overhead low.

There should be a canonical encoding, where you are able to
write the MARID as a base64 encoded string into the zone file.
This gives you the ability to generate the record with any program
of your choice and to encode things which are not yet part of the
SPF or XML or whatever representation.

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.

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.

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.

regards
Hadmut