spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: Standards process

2007-03-25 23:47:52

On Mon, 26 Mar 2007, Frank Ellermann wrote:

Standards track RFCs don't "update" experimental ones, do they?

Frank is correct. The STD can obsolute experimental RFC but can
not update it as update would require original to be on highier
or same level of standards track (experimental is not but for
most purposes it can be considered level 0 with proposed being 1,
draft 2 and full standard 3).

Not sure, obsoletes should be okay.  Updates would be rare if it
results in a normative "downref" (tons of rules, with loopholes
for the loopholes like a "variance" procedure, and of course it's
also possible to fix the damned rules.)

My idea to get rid of PRA by explaining why it's mostly pointless
in an I-D is independent of 4408bis.  It could be a IANA registry
of SPF version tags, seeded with the five existing tags.

We'll not be able to do it. But if 4408bis is standards track and
SID is still experimental and can not move to standards then for
all purposes its dead and some time way way later it can be made
historic. However it'll be very tough to move SPF to standards
track within IETF (not for technical reasons but political)

I think any attempts to get "v=spf1" to "Standard" status are a
waste of time.  What is there to be gained?

A proper standard, what I always wanted since day one when I saw
this messy list with its moving target v=spf1, one day adding odd
mechanisms, another day unifying itself with Caller-ID, wild and
wonderful scopes, modifiers, and more cruft.

SPF1 was not put together in consistant manner with proper analysis
and architectural design. Result of certain decisions to do it as
far as possible and accomodate as many proposed uses as possible.

What survived from all these discussions ?  Tiny minorities of
users consider op=auth and op=pra as good idea.  And tolerate
op=helo and op=nohelo for educational purposes, documenting two
"roads not followed" proving that nobody needs a helo-scope.

Our understanding of modifiers is certainly better than in 2004.

I dont agree. We have not used modifiers in any serious way.

We'd know how to do say op=dkim if there ever is an SSP for DKIM.

You mean if there is not an SSP (or if there is one that is not very useful). because then it makes lots of senses to use SPF record
modifiers for purposes it failed to do.

Our understanding of the IETF standards process is also better.
And if you think that SPF is _necessary_ to save SMTP from the
forces of evil, then that's no "experiment".

SPF maybe necessary to save SMTP. I'm back to 2002 when I was
thinking if its worth saving or if redesigning better email
protocol is right thing to do. And there is also such a thing
as when you have too many patches on something, its really no
longer original but something new (i.e. ncsa httpd -> apache).

What is there to be gained by turning
<http://www.openspf.org/SPF_vs_Sender_ID> into an I-D?

You mean informational one? Nothing good.

Ordinary admins will never find it, they've no clue what the
differences between PRA and v=spf1 really are.  Gullible folks
might find the Wikipedia articles and believe it, and that's it.

Aren't you the one writing in wikipedia about spf and sid?

Publishing I-Ds offering new insights (the appeal didn't discuss
the relationship of version tags) is another way to "promote SPF".

The appeals were for obvious reasons confrontational.  The I-D
would be the next obvious step, assimilation:  "PRA was a nice
idea unfortunately unrelated to reality, let's talk about SMTP."

If you can write this id, but all means, but it'll not fly through
IETF to become an RFC even informational one (they'll find a reason
even if everything else is ok).

<target-name>
Yes, not specifying it was a mistake (I think I said that a long
time ago).  However, shit happens and we cannot change the v=spf1
specification to such an extent now.

That's nonsense.  Fixing bugs and mistakes is always allowed, one
popular way to fix bugs is to document them as "features".

Its a lot harder to fix an error between proposed and draft or between
draft and standard - then you have to really convince everyone there was
original intent of the document and this is just an error in how it is
written and explained. But for experimental -> proposed standard fixing
an error is a lot easier, you just say we learned it was an error during the experiment and now ready to publish real documents with this and other
errors taken care of.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?list_id=735

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