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

Hello,

I appreciate your taking the time to write a reasonable reply.  It is 
evident that we all feel strongly about this issue (and others) so the best 
we can do is to be clear about our thoughts, feelings, beliefs and 
intentions, which it looks like you have done.
Here is a quick response to cover a couple points you raised.


--Hadmut Danisch <hadmut(_at_)danisch(_dot_)de> wrote:
> > 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.

I understand what you mean.  I probably wasn't very clear and I apologize.

What I meant to say was, making fun of someone else's post is considered 
rude.  If you make someone else the butt of a joke, it's funny, but it's 
also somewhat inappropriate behavior for a polite civilized list.  It's 
also a warning sign to indicate that someone is reacting emotionally, 
though there may be other reasons someone might behave rudely that don't 
have to do with emotions, they are often associated.

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

This is a common reaction to SPF among technical folks who are aware of its 
history.  I would like to take a moment to address it.
SPF is not just a cool idea, it is a number of cool ideas, very few of 
which are original.  It owes its origins to a number of good ideas like 
RMX, DMP, etc.  Its users ought to be grateful to those intrepid inventors 
such as yourself, and you, Gordon, Andrew Church, Paul Vixie and others who 
came up with great ideas ought to be proud of yourselves.
However, the success of SPF is not built on ideas alone.  The success of 
SPF is built on hard work.  It takes hard work to create running code for 
MTAs.  It takes hard work to have discussions with stakeholders and make 
decisions on what to change.  It takes hard work to create web pages and 
revise them.  And it takes hard work to evangelize and market the great 
ideas so that people will be compelled to try something different and a bit 
risky.  Talking to reporters is also hard work.  Just having a great idea 
is not enough -- if the problem of forgery could be solved by brilliant 
minds thinking about it, it would be solved already and we would not be on 
this list.  But there comes a time in the life cycle of a great invention 
when *someone* starts digging the trenches.
So, if you and Gordon are the fathers of modern LMAP, Meng Weng Wong is its 
mother.  Of course you care about the little LMAP, but are you willing cook 
and clean for it and change its pants?
THAT is why I have a great deal of respect for SPF and for Meng 
specifically.  He has taken a handful of really good ideas and turned them 
into a PRODUCT which can be marketed and sold.

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

I agree that some SPF supporters are having an emotional reaction to XML. 
However, your emotional reaction to SPF is equally irrational.  Can you 
definitely say beyond a doubt that you support XML for well-considered 
logical reasons, and NOT because you have an emotional investment in seeing 
SPF fail?
Let's get everything on the table and let's all be clear about our agendas. 
My agenda here is not to push SPF syntax on people, though I admit that I 
like SPF syntax and I have a negative reaction to XML because I think it's 
the wrong tool for the job, but I'm willing to be proved wrong and if XML 
is the end result of this group, I will support it, because I think MARID 
is more important than its syntax and can succeed even with a bad choice of 
syntax.
I am willing to set aside my emotional reaction, BUT, if we are trying to 
sell MARID to ordinary users, we MUST take their emotional reaction into 
account.  If we produce a wonderful, architecturally sound, technological 
marvel and people don't want to adopt it, how would people like that 
outcome?

> Have you ever seen DNS records from inside? How DNS records are
> encoded? They are not readible. They are binary encoded.
...
> 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.

It's a wonderful idea and we should strongly consider that.  I would prefer 
the TXT to be human-readable and the new RR type that we create to be 
binary... would that work for you?
Of course we would have to update the dns tools to display the data 
correctly, but that can be done at the same time as the new RR is added. 
Plus, we can tell the DNS server what additional records to serve along 
with it, etc.
The only drawback there is, what if the DNS tools don't understand the new 
binary format, when it comes time to revise things?  Can we come up with a 
binary format that is as flexible as XML?

>   This way you can have two different representations without
>   having two different types of records.
...
>   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.
...
> 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).

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.

Thanks again
gregc

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>