Phil Howard has raised a couple of these issues already (among many
others), but I think my second point here definitely needs reiterating,
and the first is just a peeve of mine...
First, on "The Stakeholder Whom Shall Not Be Named"... It's hard to
debate a proposal of an design change when the entity proposing will not
actively debate. From what I can tell, the only two people on the list
that know who has made this proposal is Meng and Phill, and really the
primary argument that I've seen come from them is that this stakeholder
has much clout and much funds to put behind SPF. Do they have any
technical reasons? The only technical arguments FOR XML that I have
seen have come from a few people on the list playing Devil's Advocate,
or the few that like XML and want to make sure we are not mis-informed
on the pro's and con's, but it seems that even those feel it is probably
the wrong technology for the job.
Secondly, let's make sure we are talking about the same thing. From
what I gathered from a few of Meng's posts and what Phill seems to be
getting at, is that not only is the proposal to add XML, but to expand
SPF to be more of a complete solution, and not just sender
authorization. Is that a correct assumption? If so, how far is it
proposed to extend it? To what functionality? For SPF and what it's
goals to achieve are TODAY, I think we have a very applicable solution
already designed and in the process of being deployed, and the only
thing that could make it better would be the dedicated RR.
In conclusion, my primary concern with this whole thread is that it's
hard to debate the merits of a proposal when the entity proposing is not
actively engaged in the debate. It also creates suspicion of motives
and gives the "Don't mind the man behind the curtain" feel to the whole
thing. I also get the feeling we're talking about expanding SPF into
something larger than it is today, with a broader scope of
responsibilities. The xml: directive seems like a reasonable way to
include XML support into the current design, but I'm not sure it's even
needed given the scope of the current design. If we're designing
something with a broader scope than SPF currently has, then we should
focus on that, not XML'izing SPF as it is now. If it truly is to be an
extension to SPF without changing the scope, I'd say it's a version 2
feature at best (as is the dedicated RR) and we move forward with
version 1 as it is now.
My post-lurk $0.02.
---
Dustin D. Trammell
Vulnerability Remediation Alchemist
Citadel Security Software, Inc.
-------
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_)½§Åv¼ð¦¾Øß´ë ù1Ií-»Fqx(_dot_)com