On Sunday 30 May 2004 20:55, dave wanta wrote:
Keep XML
1. It's bullet proof tested
2. its extensible by its very nature
3. represent any file structure, easily and effortlessly
4. parsers are easily available
5. it will be accepted by those "part time programmers" who need to whip
something up to get it to work
6. easily readable
7. less fragile, than say something as convoluted as mime
8. will be more acceptable to Fortune 1000 companies
9. easily scriptable by part time admins.
Other than the comment about it being bloated, I have yet to hear a valid
negative point.
Being the author of a recent anti-XML posting, I applaud Dave's post.
My post wasn't trying to show both sides, and I'd hate for anyone to think it
was - I sort of admitted in a backhand way a few of the points made above,
but XML does offer a lot over 'yet another cryptic markup'. My major gripe is
that the ABILITY of XML to support bloat will lead certain organisations to
bloat their SPF records (cf 73 line legal disclaimers added to emails - any
investment bank or large re-insurer... WestLB adds a 50 line sig, then
repeats it all in German) which will lead to pressure to NOT store them in
DNS servers, thereby harming all of the lightweight lo-cost nature of SPF.
This is not a failing of XML, but an unfortunate social human organisational
consequence of using a more general solution - and there is no way to
realistically enforce a rule like "XML but no comments or declarations
allowed".
The poster who suggested ASN.1 and similarly reducing all SPF records by
Huffman style encoding - a noble aim, but I just screamed "please no" - it's
the same mistake but in the opposite direction (not to mention the security
holes in mal-formed ASN.1 records and their complete inpenetrability).
As a rhetorical point - Why do we write [source/data/config] in a code ?
The answer (IMHO) is: to make the intent, and the codification of our intent,
clear to HUMANS. The computer can be made to read anything from the most
compact binary form to the most verbose ramblings imaginable, but the point
is that the priority of the importance of being able to read a record are:
1. the author (in the course of structuring their thoughts)
2. the author (to verify that their codification of a solution is complete)
3. other humans in order to learn the author's complete intent
4. other humans in order to modify the record to match some new intent
5. the computer, to execute the strict rules of what it says to do (not the
same as the intent - the computer never interprets the intent, except
sometimes optimisers may do so).
Insert the obligatory Einstein quote here. And add a KISS aphorism or two.
SPF records must be kept short enough that no sys admin can refuse them on the
basis that they'll turn his DNS server into a database, or kill his DNS (or
any similar low level protocol like ARP) by inappropriate use or a mammoth
distortion of its operational characteristics. But the records must also be
kept simple and readable enough that a sys admin can SEE broadly what a
record says, and can INSPECT the difference between 2 different records
without having to resort to external tools.
I welcome a proper defence of XML in SPF, but I am the wrong person to do it.
Cheers
--
Tim
P.S. For the record, I'll post my opinion seperately