Since I am probably the person with greatest XML experience here I should
probably explain the pros here. I was the editor of the XKMS and SAML specs
and I am currently working on WS-Security. My first reaction to this idea
was pretty much what you see on the list from everyone else. It is like
adding a go faster stripe to a Lada and calling it a sports car. But...
The cons are fairly obvious
* It is a change
* The result is more verbose
* Network administrators are not familiar (Human readability issues)
* It is not the way DNS does things
The pro's need a bit of explanation
* Better extensibility model
* Re-use of existing parser infrastructure
* Programmers are more familiar (Human readability issues)
* Avoid emergence of competing spec with significant, well funded PR
effort
* Well funded PR effort instead supports SPF.
* It is the way any DNS replacement will do things.
It would be really useful if lurkers from the big filtering companies could
chime in here. Yes we know you are out there.
And in response to one point about folk comming out of the woodwork to
suggest alternative architectures. That is the consequences of success.
People are starting to look at what SPF has achieved and are trying to
decide if it is the right solution in the big picture. I am somewhat
fortunate to work for a company that is small enough to let me loose in this
type of forum without minders, there are few people in the companies I work
with to develop specs who have that freedom. You can look at the specs I
have written and see the companies I have worked with over the past 5 years
- believe me the major players are engaged here.
The question at issue here is whether SPF will be the anti-spam solution the
major players adopt or whether it merely becomes the catalyst to action,
forcing the various players to put their proposals on the table and come to
a consensus. That is one possible outcome and from a pure architecture
standpoint there are a lot of people who would prefer that route. The cost
there is that it would take a minimum of nine months and we cannot afford
that.
That is why I defected to the SPF camp. Nine months off deployment time is a
big issue for me. My credit card merchants are the ones who hold the bag
when an identity theft Joe job (sorry impersonation spam) gets sent.
The Extensibility Issue
-----------------------
The big issue we are facing with SPF is the difficulty of extending
protocols with very poor support for extensibility - SMTP and DNS. One thing
that XML has done right is to have a good model for extension.
The key to XML extensibility is namespaces. Each XMl document states what
namespace the markup is declared in using the xmlns="--some uri--"
mechanism. Namespaces can have prefixes so that you can have one markup
reference another and not have to worry about collisions between tag values.
What this means is a change in the extensibility model. Today it is possible
to extend SPF, that is new tags can be defined for the SPF framework. In the
research document I propose a mechanism that extends SPF to embrace the
Yahoo Domain Keys scheme.
There are two difficulties with this approach. First there is barely a
process for developing SPF. Who gets to decide what goes into SPF 1.1? What
happens if someone makes a proposal for an extension and the group does not
think it is a good idea? There is no way we can force them to drop it, they
can go ahead and publish anyway.
The second problem is that we have tried this mechanism for extension in the
IETF in the past and it has never worked in practice. If you look at the
main IETF protocols the most glaring fact is that they have existed
unchanged for at least a decade in most cases even when there are major
performance, scalability, reliability issues. The current state of SMTP is a
witness to this failure.
The subtler problem is that you end up centralizing change control. The
Internet was meant to be a grassroots effort but to add a feature to a
protocol you end up having to go through choke points such as the IETF. The
effect is that innovation is stiffled rather than encouraged.
Basically the sales pitch that is being given here is for
The Readability & Size Issue
----------------------------
Everyone accepts that XML is bloated size wise. Given any data structure you
will be able to encode it more efficiently in a different encoding -
S-Expressions, RFC822 style, you name it.
The real issue for readability though is what happens when you have a large
data structure rather than a small one. Sure the SPF records are pretty
simple when all we are doing is describing the IP based authentication
scheme. What if we want to go beyond that capability? For example:
* MTA Mark like description of IP address use
* Accreditation schemes
* Domain key type authentication
In the research note I descibe how these can be brought into the SPF syntax.
The result is something of a compromise because I have to make sure that I
do not exceed the complexity threshold that the SPF syntax is capable of.
It is a heck of a lot easier to provide a description of the accreditation
policy of an accreditation provider in XML than in SPF style. The big plus
is that you have parentheses and you can create nested structures.
Tools
-----
From a tools point of view XML wins, there are tools to parse XML available
in Perl, Python, pretty much any modern program environment. The industry
has adopted XML as its core mechanism for representing data structures. You
may think it is yukky, but there is a fundamental level where being part of
the standard is worth more than the cost of yuk.
This has a knock on effect, if we want to get Eric Allman on board on the
syntax issue for example. If we say SPF syntax he can kibitz, if we say its
XML he will say 'oh sh*t, why?' then he will hold his nose and accept his
helping of yuk.
We did it with HTML
--------------------
With the Web we got people to use angle brackets and the whole XML gubbins.
And that was in a day when there were no HTML tools at all, not even an
emacs editing mode.
There is no real difficulty generating XML syntax or shipping it out through
DNS, it is as easy to edit directly or to code with a wizard. The cost is on
the recipient side.
Its the way DNS is going to go.
-------------------------------
DNS is not XML based, but if there is a next generation in the next 20 years
it will be XML based. XML is simply the 2000's version of ASCII. It may be
flawed (missing characters) but it is going to win.
At some point Linux will ship with every configuration file in the whole
system converted into XML. Windows already went that way.
The politics
------------
Unfortunately I can't explain the politics here, I am under NDA with pretty
much every company you could imagine to be involved. Just to back up what
Meng said, this is not something that is motivated by some engineer riding a
hobbyhorse.
The real issue is whether we just solve the spam issue or whether we start
to dig ourselves out of the larger problem that the Internet protocols have
no mechanism for extension worth a damn. We have a major major player who is
willing to come on side with SPF if we are willing to work on the larger
problem. If they do, they have the clout to bring onside every other player
of any consequence at all. We can have 50% of email described by SPF records
in weeks.
Phill
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡