Greg Connor wrote:
The appearance of Hadmut Danisch in the In Favor Of XML camp is
definitely a blow to the anti-XML team. This, coupled with the
support of Phillip Hallam-Baker is almost enough to make the anti-XML
team lose hope.
Here Hadmut demonstrates a typical argument method in the Not Based On
Logic categorym that of making fun of an argument he disagrees with.
The listener may be swayed into thinking that if the argument can be
mocked, it must not have been serious in the first place.
...
Now. All joking aside, I have a great deal of respect for Hadmut and
his work... we probably would not have arrived where we are today
without him. But, the arguments being made here are not logical ones.
In fact, Hadmut's message here is an *excellent* example of someone
reacting emotionally (and making an emotional argument) rather than
reacting with logic.
This was not meant to be logical.
This was not meant to be an argument at all.
This was meant to be irony and sarcasm. I wanted to point out on which
lousy level this
discussion is made. If you didn't realize this and still took this as an
argument, you confirmed
my point of view. While you were blaming me for beeing emotional, It was
you who gave a
purely emotional reaction. You were supposed to laugh and cool down.
Maybe you have realized that I didn't participate in this discussion for
a long time. Guess why?
Because this is an endless loop. An emotional loop. Caused by SPF.
Why?
Because SPF has never been a technical invention. SPF is only a public
relations coup of
a few people who were hijacking an idea to bring themselves in front of
the cameras
and the newspapers. I have spoken with several journalists who were
intentionally misinformed.
If you don't believe this, just have a look at the ASRG history.
And that's the reason for emotions. What is the main property of SPF?
Nothing but a
slightly changed syntax. If we don't stick to SPF syntax, what will
remain of the SPF hype?
Roughly nothing. That's the reason why so many people desperately defend
SPF syntax
against any progress. They try to enforce SPF syntax, because that's all
SPF consists of.
Think about it. Your overreaction to my sarcasm was very meaningful.
OK, let's come back to technical arguments.
A/The major argument for using SPF is readability. I confirm that
readability is
a very strong and important argument.
But is this correct? No, it isn't. Why not?
Because it ignores the fact that DNS records are not readible by default.
Readibility of SPF is based on wrong assumptions. It is based on abusing
TXT records. The readibility argument includes a lot of ignorance of
technical
facts. Most people don't seem to be aware of layer models.
Have you ever seen DNS records from inside? How DNS records are
encoded? They are not readible. They are binary encoded.
If you can easily read what nslookup/dig spit out, then this is not a
property of DNS records. It is because the dns library includes
encoders and decoders for every single DNS record type. What you
see is a result of a decoding process, not the DNS record itself. Even
TXT records require some encoding. It's extremely simple, but it
is there.
What does that mean? The whole argument of readibility is pure nonsense.
Based on wrong assumptions and ignorance of technical details.
What do you believe? Why did I put both a syntax and a binary encoding
in the RMX drafts? Because you have to cover both, the external
representation and the internal encoding. That's what we have to deal
with in context of DNS, whether you like it or not.
Of course, you can decide to abuse TXT records or invent a new
MARID record type with exactly the the same simple encoding as TXT
records. But that itself is a step of engineering most people never thought
about. This MARID/SPF/... discussion is a religious controversy, not a
technical
development process.
How do we make it any better?
I propose to start beeing aware of having to do two different jobs:
- Define an internal encoding
- Define an external representation
(This requires to understand how DNS works, which is significantly
more than just being able to abuse TXT recors...)
I'd propose an example. You don't need to stick to it, it's merely
to explain what I am talking about.
- First, define an abstract semantics. This is almost done.
Define that MARID records can authorize IPv6 addresses,
IPv4 ranges,etc.
- Second, define an internal encoding.
I'd prefer ASN.1/DER
DER decoders are not that difficult, because in contrast
to XML you can work with a simple one byte lookahead.
DER de- and encoders can be extremely small and
compact. (And I don't know that anyone ever seriously complained
that SNMP, X.509,... are encoded in ASN.1).
- Define an external representation. This is what nslookup or
dig spit out when displaying a query result or what bind
eats when reading a zone table. If you don't understand what
I am talking about, have a look at the bind sources or the
RMX implementation example available at danisch.de
Why not having two external representations?
You are free to express the ASN.1 encoded information in
any readible syntax, both SPF or XML, for zone tables,
for human readibility, for printouts, for storage, as a
mime type, whatever you want.
This way you can have two different representations without
having two different types of records.
Those who love SPF can have there DNS library compiled
that it displays MARID records as SPF. Has advantages on
command line tools. And others, including
the MS world, can use XML representation. Good for
programming languages.
Important is that we have two representations, but only
a *single* encoding. Only one type of DNS records. That's it.
SPF or XML is not a matter of the record itself. It's a matter
of the program you use to display the record.
- MARID interpreters, those which are built into MTAs, can
work directly on the encoding, e.g. ASN.1. This is
actually easier or actually not more complicated than
parsing SPF. You have automated tools for those who
don't know ASN.1. And if you do, it is also a simple
afternoons job to write a parser on your own in
any available language.
So in my eyes, this would be the best solution as long as we
are bound to store MARID records in DNS (if not, see RMX++ proposal).
regards
Hadmut