spf-discuss
[Top] [All Lists]

Re: draft: SPF community's position on MARID closing

2004-09-25 19:00:07
In <x4y8izlf4u(_dot_)fsf(_at_)footbone(_dot_)midwestcs(_dot_)com> wayne 
<wayne(_at_)midwestcs(_dot_)com> writes:


Meanwhile, working with Microsoft on Sender ID, we have
defined a spf2.0 specification which will be backward
compatible with the spf1 records out there; and it will give
senders in unusual situations greater expressiveness.

I have problems with this part.

Meng answered most of the following questions on the #spf IRC channel,
but since most people don't follow it, I'll relay the answers here.

The short-lived "spf2.0" record definition was not backwards
compatible with "v=spf1" records.  You and Mark explicitly did not
want to add that compatiblity.  Also, are you really still working
with MS?

Yes, Meng is working with MS.

          Are they committed to staying with the specs, or are they
going to go off and do their own thing?  Is it wise to try to speak
for them?

Meng didn't try to speak for what MS will do, but it appears that MS
will likely try to stay with the SenderID specs.

What about the PRA?

The PRA is being blessed by drafts that Meng is going to submit soon.
The PRA will be "optional", but MS will not need to change their
license to have it part of the standard.


                      The IETF has asked for individual submissions,
but if you submit the PRA as a scope, you will run into the same
buzzsaw trying to get an individually submitted draft accepted as an
RFC as what happened in the MARID working group.  The sparks will just
fly at the IESG "last call" level, rather than the working group "last
call".

The disbanding of MARID appears to be an end-run around the working
group last-call.  Since the PRA license would likely block any
consensus by the working group, the working group has been
eliminated in order to move the PRA forward.

I still think what I said above is true, that the same problems will
happen at the IESG "last call" level.  We just won't be able to say
anything until Meng has submitted the new drafts with the PRA
included.


So, if you try to support the PRA, you aren't going to get an RFC.  If
you don't support the PRA, you probably won't get support from MS.  If
you just try to push a new spec without trying to get IETF RFC status,
and you include the PRA, you are going to lose a huge amount of
support from the SPF community.

Maybe I'm wrong and the "SPF community" doesn't have a problem with
the PRA and the MS license, and therefore Meng's backing of the PRA
will not cost him anything.    Personally, I think it is a huge
mistake to not drop the PRA until such time as there is an acceptable
license.


-wayne


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