spf-discuss
[Top] [All Lists]

everybody please calm down :)

2004-06-07 11:43:17
On Mon, Jun 07, 2004 at 06:35:35PM +0100, Tim Meadowcroft wrote:
| 
| But I see it all went quiet on my proposal after that. Presumably I was 
| missing something... but I thought it was a good way to AVOID forking SPF 
| (which I am dead set against - I'd drop interest in SPF if it forked, whereas 
| if it went XML-in-DNS I'd retain a skeptical interest).

I think it's premature to talk about forking SPF.

First, the merged spec is still under construction and is
changing rapidly.  It contains lots of parts that say
<<<FILL THIS IN LATER>>>.

Second, when the spec has been reasonably fleshed out, we
plan to present it on the MXCOMP mailing list of the MARID
forum (and here).  This will happen around the end of June,
maybe the 22nd.  We are iteratively developing it and are
posting snapshots as we go.  The first snapshot was posted
last week, and another one should come out this week.

Third, even when it has been presented as being "ready for
eyeballs", that's just the start of another round of
debate and refinement.  That will happen in the MARID
forum.  The hard deadline is the San Diego IETF meeting, and
that's in August, a few months away.

Fourth, once a draft is submitted to the IETF, change
control rests formally with the IETF; Microsoft does not
dictate the content of the new specification.  Rough
consensus drives change.  Because the IETF is an open forum,
anyone can join the MXCOMP mailing list and make their
opinions known.  In developing the SPFv1 draft, I have tried
to let consensus be my guide.  In my contributions to the
merged draft, I plan to reflect the consensus seen on the
MXCOMP list as well.

So I would ask people to keep in mind that the New SPF that
was presented on this list was not much more than a
proposal.  It was meant to be a starting point for
discussion, not some finished thing for people to vote yes
or no.

Therefore, any discussion of forking, etc, is premature, and
frankly looks a bit paranoid.  It would be more constructive
to help the merged spec develop in the direction you want it
to go, than to try to oppose it on the basis of any real or
imagined shortcomings.

A huge portion of the email industry converged at the
http://www.InboxEvent.com/ last week, and will converge
again at the http://www.ETCevent.com/ next week.  The people
who show up there are excited by the news they've heard that
Microsoft is now working with SPF; and now they are ready
for guidance and direction.  Over the next two weeks, it
would be more useful if we could set aside the objections to
a new draft that is, after all, still under construction.
Instead, it would be better to try to help the users with
their questions regarding publishing and early deployment.

For now, because the new XML syntax hasn't even really
solidified, and because everyone has agreed that at a
minimum the SPFv1 syntax will be supported for the
foreseeable future, the most constructive message we can
send the public is this: keep publishing SPFv1 records;
receiver-side developers should develop SPFv1 capability; by
the time August rolls around we may have new news but until
then just get the version 1 stuff under your belt.

Technical debate over the appropriateness of XML and the
viability of the PRA algorithm and the refactoring into
layers is fine and good, but where the public is concerned,
all that is a tempest in a teacup.

Things like this matter much more in the long run:

  20040607-14:36:24 mengwong(_at_)dumbo:~% dnstxt verizon.net
  v=spf1 ip4:206.46.170.0/24 ip4:206.46.128.33 ip4:206.46.128.101 
ip4:209.84.13.21 ip4:209.84.13.20 -all