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>
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: Why not XML, (continued)
- Re: Emotions, Encoding, and Ignorance (Was: Why not XML), Mark Lentczner
- Re: Emotions, Encoding, and Ignorance (Was: Why not XML), Hadmut Danisch
- STOP NOW! (was Re: Emotions, Encoding, and Ignorance (Was: Why not XML)), Andrew Newton
- Re: Emotions, Encoding, and Ignorance (Was: Why not XML), Greg Connor
- Re: Emotions, Encoding, and Ignorance (Was: Why not XML), Hadmut Danisch
- Re: Emotions, Encoding, and Ignorance (Was: Why not XML),
Greg Connor <=
- Could binary encoding really be the answer?, Greg Connor
- Re: Could binary encoding really be the answer?, Aredridel
- Re: Could binary encoding really be the answer?, Robert Barclay
- Re: Could binary encoding really be the answer?, Douglas Otis
- Re: Could binary encoding really be the answer?, william(at)elan.net
- Re: Could binary encoding really be the answer?, Douglas Otis
Re: Why not XML, Jon Kyme
RE: FW: Drive Towards Consensus, Jim Lyon
|
|
|