On Friday 23 January 2004 12:52 am, Meng Weng Wong wrote:
| 1. We believe it's critical to have an architecture for
| uncoordinated extensibility of the information published about a
| domain's email policies. Once deployed, we expect (and indeed hope) that
| others will build on top of what is initially defined with new ideas and
| functionality. They need to be able to do this without the need to act
| through some all-powerful central coordinating authority yet still be
| assured that their extensions both won't conflict with those of others
| and also won't disturb the operation of existing non-extension-aware
| interpreters of the data. XML already has a flushed-out and mature
| architecture for doing this (its namespace support and the wildcard
| infrastructure in XML Schema are critical pieces of it), one that was
| developed through a significant learning curve that would be both
| arduous and error-prone to repeat.
XML only generalizes syntax. I believe it is critical for SPF to have an
architecture that is *semantically* unambiguous. When I publish an SPF record
I need to be sure that everyone on the planet who reads it interprets it in
_exactly_ the manner intended. I certainly don't want the meaning of my
publication to be wrongly interpreted based on differing support for various
open-ended 'optional' semantic elements, 'modules' and 'extensions'.
The only reason the MS is interested in design goal #1 is because it
legitimizes an 'embrace and extend' strategy under a fictional 'veil of
standardization'. This is why XML is their 'pet technology'.
This argument for XML is rather like agreeing not to adopt a common standard.
Duh.
| 2. There already exists an incredible variety of deployed XML
| parsing tools available in a wide array of languages on virtually every
| platform anyone might care to want one for. These help raise the
| interoperability bar, in that by using these tools applications can
| avoid introducing inadvertent lexical and scanning problems due to bugs
| or specification ambiguities: the XML tree model semantically projected
| by these tools (it's so-called "document object model") makes it more
| difficult for these problems to creep in. Among other issues, for
| example, complications caused by issues of character set encodings are
| already handled. This even helps avoid things like the buffer-overrun
| errors that have lead to so many security alerts in recent years :-).
Parsing SPF as it stands is
a) Trivial.
b) Far more lightweight than any XML parser.
c) Already coded for many languages.
d) Constrained by DNS character encoding anyway.
| 3. These deployed parsing tools build upon the quite mature and
| polished XML syntax and lexical specification
| <http://www.w3.org/TR/REC-xml> , again helping to assure
| interoperability. The API of these tools is often based on the equally
| well established document object model <http://www.w3.org/DOM/> ,
| helping to assure portability of client code.
SPF is as interoperable as IP and DNS are. That is to say, exactly matching
the reach of the problem domain. Perfect.
| 4. The XML Schema <http://www.w3.org/TR/xmlschema-0/> definition
| language exists and is mature. For applications trying to use XML, like
| Caller-ID, this provides value by given a means to denote
| application-specific syntactic intent in such a way that generic schema
| validation tools can verify that the structure of a given XML document
| is well-formed and syntactically valid from an application point of
| view. The ability to provide this sort of formal syntactic specification
| is also crucial to being able to support uncoordinated extensibility in
| a robust way: as an interpreter of data, you need to formally know where
| someone might put in some new datum you need to robustly be prepared for
| and skip over vs. other places where you can assume more tightly you
| understand what the data looks like.
But we don't want new datums, that would only serve to screw things up. This
is an argument _against_ using XML.
Spec, adopt, problem solved. Next!
| 5. Validating parsing engines are also broadly deployed. Beyond
| just the syntactic parsing and verification performed by the lower level
| engines, applications using validating engines can be assured that data
| they are about to interpret conforms to the structural syntactic that
| the application expects. As a result, error checking and validation code
| in applications is reduced, and greater interoperability results.
See answer to (2). Note also that XML is complex enough that most parsers have
a host of bugs and differing interpretations of the standard. Anyone who has
ever made heavy use of XSLT and then tried to port it to a different XSLT
parser/transformer will know what I mean.
| 6. A number of rich auxiliary architectures have already been
| defined for XML, notable among them XML Encryption and XML Signature.
| Being able to leverage these infrastructures provides powerful
| possibilities for future enhancements to Caller-ID. For example, it is
| entirely trivial to create a signed Caller-ID Email Policy Document: one
| merely uses the XML Signature's "enveloped signature" mechanism in one
| of the document's wildcardable extensibility points. This works with
| existing tools and existing credential management mechanisms, and all
| that using only a handful of lines of new code to be able to put it all
| together. Being able to selectively encrypt parts of a policy document
| while keeping other parts open is also quite likely of significant
| interest to some publishers. All this just comes architecturally for
| free; duplicating the designs for a custom data model would be a huge
| amount of work. Similar synergies also exist with other XML
| architectures, such as XML Query and its relation to databases, though
| the utility there is less viscerally obvious.
Why would you want to encrypt your SPF record? Even signing should take place
at a lower level, ie: DNSSEC.
| 7. There is a huge vibrant industry out there building a large
| variety of XML tools to address various needs. A product like XML Spy
| <http://www.xmlspy.com/> , for example is a powerful XML development
| environment (XML Spy is what I used to produce the XML syntactic
| diagrams in the Caller-ID specification), and it has at least a dozen
| significant competitors. Other authoring environments like Visual Studio
| and other text editors already have XML text coloring and optimized
| keyboard navigation built-in. Internet Explorer has nice hierarchical
| XML rendering and browsing available just by loading a .xml file. The
| list goes on. Also, various transformation tools and architectures like
| the XSLT <http://www.w3.org/Style/XSL/> stylesheet language provide
| rich declarative means by which raw XML data can be automatically
| transformed into other forms such as human-presentable HTML.
Is it really that complex? Next we'll be encoding text as XML:
<w>The</w><s/><w>year</w><s/><w>is</w><s/><d>2</d><d>0</d><d>0</d><d>4</d>
Wow! So many tools can load that sentence in, must be a good idea!
| 8. There exists a large extant body of technical professionals
| already educated and trained in XML.
Only small numbers of programmers are ever going to need to code SPF support,
and it's trivially simple to understand.
As for publishing SPF records, I assure you that TXT in DNS is more intuitive
and understandable than XML.
There exists a large body of _ordinary_ _people_ who own their own vanity
domains and understand plain text, no 'techinical professionals' are wanted
or needed.
| 9. There exists a dedicated industry (books, seminars, etc) of
| companies and people working to educate same and grow this pool. The
| investment put into educating oneself in XML is leveraged knowledge
| beyond just administering a spam-deterrence infrastructure that can help
| one's career grow and expand outward.
Aha! Playing to the MCSE crowd? I can't argue with this one.
We must keep the wheels of commerce turning after all, no matter harmful the
snake-oil is.
- Dan
-------
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;±¤Ö¤Íµø?¡