The Mystery Stakeholder's name for their answer to SPF is
"Caller-ID for Email".
I should preface this message by saying:
- they are not stupid. they are in fact very smart.
- they have been developing it since this time last year,
- and may therefore be further along the curve than we are.
This message comes from the system architect who designed Caller-ID.
| Meng,
|
|
|
| Here's a summary of some of the reasons we used XML in Caller-ID for
| Email and continue to think that that is important. In no particular
| order:
|
|
|
| 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.
| 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 :-).
| 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.
| 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.
| 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.
| 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.
| 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.
| 8. There exists a large extant body of technical professionals
| already educated and trained in XML.
| 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.
|
-------
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;±¤Ö¤Íµø?¡