spf-discuss
[Top] [All Lists]

Re: XML Poll (Please respond only once)

2004-06-02 16:58:33
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


<Prev in Thread] Current Thread [Next in Thread>