On Tuesday 01 June 2004 17:34, Jeremy T. Bouse wrote:
I think people are failing to miss what I thought was the entire
point of James' intent which was why are we even bothering to waste time
contemplating the use of XML within DNS records for the publishing of
information. Enough with the Microsoft bashing, sure can't say I've done
my fair share of it, but the point is not to bash Microsoft and CID or
atleast that's not how I read James' email. The point is XML is
completely unnecessary for the task at hand. Use the right tool for the
job for pete's sake.
I don't want to appear to be fanning flames here (having advocated both sides,
and then a unification theory -- if anyone wants proof I'm not trolling on
behalf of MS then I'm more than happy to reveal any background considered
relevant), but let me explain why I suggested exactly this for my unification
theory.... [which I only typed quickly as I was being told off for staying up
late and making noise typing too loudly ;^) ]
- MS want XML, and hang the cost (runtime, latency, etc.), this is aimed at
people who want ease of use, integration with webservers and application
level code, and to pretend that low level protocols like IP, DNS, ARP etc
don't exist. And if the format changes, they only want to change the "action"
code, not the parsing and retrieval bits.
- "We" (term used advisedly) want small records that can be fit into a DNS
record and parsed immediately by a minimal standalone non-integrated app so
that we can check BEFORE the DATA section without having to buy huge pipes,
do tricky caching or being a huge organisation with limitless resources. If
the format changes we'll change our minimal parser et al - it's all one piece
of simple code together in one place, so it's easy to do it all at once.
There is NOTHING inherently wrong with either position - you have one set of
values or the other, but the two don't naturally mix (like wanting a
people-mover and a sports-car).
So, my suggested compromise is to have a core of a sports car (SPF) but to add
the ability (not the obligation) of making a 12 seater minibus available on
call.
From a user's point of view, my spf2 suggestion has an SPF1-like low
runtime-cost option (read it all from the specialist format from the DNS
record and ignore the XML URL - if the SPF record only had the XML URL then
pretend there was no SPF record), but allows those who don't mind the runtime
cost to spend some extra resources using what they consider more robust
commodity code (TCP connection, HTTP protocol, XML parsing) to get the info
in the format they prefer - sure it costs more but they only need parse the
DNS record for a single simple expression - if it's there then they can do
all the stuff they prefer, if it's not then they can pretend there was no SPF
record at all.
I know the cost of retrieving the XML is much higher, but if you're going to
validate and parse real XML (remember to read those schema declarations and
HTTP retrieve the correct DTD/Schema/Relax-NG spec in order to validate the
record properly, or there's no point in using XML and 'reduced XML parsers'
again miss all the point of why MS want XML in there) then this TCP etc.
overhead doesn't cost that much extra, and lets you use all the wonderous IIS
tricks you want (If-Modified-Since headers etc.).
Now, as a domain looking to PUBLISH an SPF record, you must add a DNS record
to qualify, but depending on your preference you can publish just the SPF1
data (in the DNS record alone - end of story), or just the XML record (and
only put the location in the DNS record - quite simple to understand what to
write), or you can bend over backwards and do both.
If you believe people should only be using SPF1, then you just publish that
record (no XML URL, no XML required, no-one will try and retrieve your XML)
and all the "true SPF" domains will respect your SPF and your intellectual
purity.
If you want to try SPF and you've got a MS out-of-the-box server and MTA, you
probably just do the XML stuff (and find only a few people of the people who
actually access your SPF record bother to go and get the XML), and so you
then learn enough or use a wizard and end up publishing both.
SUBTLE-HINT: the SPF website has a simple webpage where, if you type in a
domain name, it retrieves your DNS record, reads the XML location, retrieves
and validates your XML, parses it, and tells you EXACTLY how to express it in
SPF1 syntax - how easy was that !!.
The long and the short of it is: in order to get what you consider the best
solution, sometimes you have to tell a convincing story to get everyone
committed, and then, once you've got agreement, you can get on and DO the
thing and let the world see that what you originally suggested ends up being
the most useful bit, and for the price of a bit of extra implementation
effort and a slight swallowing of pride, you've saved 6 months of arguing
over precisely what TYPE of cheese the moon will turn out to be made from
when you get there...
It's not that I'm saying I love the idea of doing things twice, but sometimes
you just have to find a way to get on and do it.... the task at hand is
convincing others to adopt SPF and minimising the cost, and if the offer of
an XML escape-route is the honey-pot used then so be it.
Phew - if anyone fancies doing this over a beer sometime (in London) I can
make a much more convincing argument face to face!
Regards
--
Tim
P.S. This is not just Perl's TIMTOWTDI, but also the C++ idea of 'you only pay
the price if you use the feature', and the Unix idea of 'small tools that do
one thing neatly and orthogonally', while saving room for the MS idea of
'combine commodity units to fit our framework where, at the top level, just
the essence of this problem can be expressed'.