On Sun, 2004-05-30 at 13:02, George Mitchell wrote:
Before we waste any more time on XML, could we take a quick poll on
whether we want to use it at all?
I am opposed to the use of XML in conjunction with SPF.
Looking at the issue from technical, political, and
willingness-to-change, and PR sides:
Technical:
----------
I see no technical advantage in having XML in the spec for extensibility
reasons:
o XML's extensible syntax is moot given spf's
not-so-extensible semantics.
o SPF's not-so-extensible semantics is a necessary *feature*, as
you don't want two SPFv1-compliant receivers to come up
with different results for the same record and emails.
o There is "play" in the spec for custom semantic extensibility
using your own modifiers. This is useful for things such as
"ses=v12" or something, but not so much in things that could
cause the SPF result to change between PASS and FAIL. (In my
mind, there's a possibility of an SPF PASS together with an
SES FAIL.)
I don't see the need for any more semantic extensibility than
that.
(When the SPF spec was first frozen, I asked a question
about extensibility from the points of view of testing
development of new features and implementing new features
for use internal to an organization. Modifiers can handle
both cases. Problem solved.)
o Side note:
If we really end up wanting semantic extensibility, we could have
a rule similar to that in mail body headers an RFC2821 itself,
where things beginning with 'x' are unofficial and can be ignored.
This would mean that unrecognized mechanisms *and* modifiers cause
an error result, unless they begin with an 'x', in which case
they're ignored.
Throw in a syntactic parentheses-matching requirement, and that
would allow everyone to do everything they wanted with extensible
semantics, without anyone being able to claim their extensions
are truly part of the spec until the spec is updated to non-x-names.
The 'x'-prefix possibility is of course unrelated to any
xml-versus-non-xml decision.
Technical:
----------
Many people have pointed out the numerous technical problems with the
XML *syntax* as it relates to spf--there's no point re-listing them
here.
Political:
----------
Adopting XML gains us a political advantage, as Microsoft likes XML.
With Microsoft as an active supporter:
o Presumably a new RR type will be easier to get through.
A new RR type would be nice, but we could live without it,
and previously we were in fact going to go without it.
o Presumably RFROM/FRED/DAVE SMTP extensions will be easier to
get implemented.
But the DAVE SMTP extension is unnecessary if we use "fake"
source and return routes, and in fact using fake source and
return routes probably can be implemented more quickly than
an SMTP extension RFC!
(As an aside, as discussed on the list and irc, RFROM does the
pretty much the same thing that ORCPT does or IMHO should do,
except that RFROM is in the IMHO correct place (MAIL command)
instead of the silly place of being part of RCPT. If it ends up
that we can't get Microsoft's help in implementing RFROM/DAVE
*and* for some reason this means that we can't get RFROM/DAVE
pushed through in an RFC (which at this point I doubt will be
as big an issue as a few months ago), there's still the fallback
position of getting a more minor clarifying RFC for ORCPT
that allows the use of ORCPT by itself as its own extension,
without the mail server having to implement all of DSN just for
ORCPT functionality--and of course there's also the
more-talked-about fallback of using source and return routing and
not needing any ESMTP extensions at all.)
So, given that we actually need neither a custom RR type nor a DAVE
extension, there's no reason to permanently capitulate on XML
just to get these two things.
Political:
----------
Adopting XML also *causes* political problems for us, as admins will be
reluctant to parse XML from within their mail servers.
This isn't just theory--We already have empirical evidence that
admins *like* the SPF syntax over the CID XML syntax, and are much
more willing to implement SPF over CID when both sending and
receiving.
Willingness-to-change:
----------------------
Meng was willing to instantly change the very core of SPF by
incorporating the notion of the PRD.
Granted, it's a much better way of going about things, and all of us
were falling over ourselves agreeing with him and thanking him for
doing that, because it's the *right* thing to do.
But, doing the right thing isn't always easy--Note again that this
was a change to the project's core, made in response to listening to
constructive feedback. No matter how much each of us likes to think
we can do this, it's hard to listen to such feedback on your projects
and actually follow through on things by changing your projects
at their very core.
By asking Microsoft to drop the XML notation for the SPF/CID merger,
we're asking a group of people representing a large company to
do much the same thing--to reexamine and throw out a part of their
spec that's precious to them--and it's even harder for a group of
people to do that than it is for a single person to do it.
So, I think it made a lot of sense to at least accept XML for the
time being and discuss things further, a bit of political wisdom that
I would not have had were I there.
This gives time for all parties to really examine the idea of
XML--again. On this list we've now had even more well-written
reasons against it than we had back at Christmas. I know I've
racked my brain thinking of any technical justification for XML
in SPF, as well as trying to come up with any continuing political
justification, and I can't find a reason or justification on either
basis that really stands up to scrutiny.
I'm hoping that Microsoft employees are reading this list with
a similarly introspective mindset. If they have any remaining
technical reasons why XML will help SPF, they should let them be
known. If not, I hope they are willing to drop it from the spec--
there is no shame in withdrawing a technological solution that
is shown to not be a match to the problem at hand.
Public Relations:
-----------------
The spec merger gains Microsoft PR advantages.
o Before the merger, spf was based on the return-path. Afterward,
on RFROM/FRED/DAVE + PRD. They were part of the reason for
the switch. They can take credit for being a reason SPF isn't
based just on the return-path anymore.
That's good PR, spinnable in a way to make Microsoft look good.
o They're apparently open(ish) to patent grant(s) as required.
I personally doubt their patents if issued would actually
turn out to be valid if ever tested, but that's not important
to the PR value of announcing a useful patent grant.
Again, spinnable to positive PR.
o Microsoft can surely even spin dropping XML in a good way.
As none of these PR advantages for Microsoft require the use of XML, but
all of them require a continued merger, I don't see a real political
reason why Microsoft needs XML in spf/cid.
Public Relations:
-----------------
We benefit from a continued merger, but we don't actually need it:
o Microsoft can help in implementing source/return
route DAVE-substitutes, but such help isn't required.
o With source/return routes, going more slowly on getting
a DAVE rfc through would be just fine. (I guess we can
do both source/return-routes and DAVE--though no one's talked
about this.)
o Going more slowly in getting an RR assigned is okay as well.
o Apparently, SPF-implementing exchange plug-ins are possible
without Microsoft's help too, but it obviously will go much
faster with their help!
o The general PR value of being in agreement with Microsoft helps
implementation proceeds faster.
o If people are worried that Microsoft might use patents against
spf implementors down the road, a merger that included a useful
patent grant would allay such fears. But I really doubt that
people are more worried about Microsoft using patents against
folks for SPF-related reasons any more than for non-SPF-related
reasons, so this isn't as big a issue overall as it might sound
like at first. (Not that it's not a potential problem, but it's
just one small part of a potential worry about patents.)
Conclusions:
-----------
o There are no proven technical advantages of XML over existing syntax
for spf, while there are demonstrated technical disadvantages of XML
with spf.
Apart from the merger itself, XML on balance doesn't have political
advantages for either side, which means that it *shouldn't* have
political advantages in relation to the merger..
o While it's true that Microsoft has more to gain from a continued
merged spec than we do, that should be irrelevant, as there's no
real advantage in their continuing to push for XML in the first
place, and I think the Microsoft representatives will come to the
same conclusion if they are willing to fully re-examine all their
reasons for wanting XML.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com