RE: Fwd: Re: [spfbis] SPFBIS proposed charter

> -----Original Message-----
> From: Commerco WebMaster [mailto:[email protected]]
> Sent: Sunday, December 18, 2011 9:39 PM
> To: [email protected]
> Cc: HECTOR SANTOS
> Subject: Re: [spf-discuss] Fwd: Re: [spfbis] SPFBIS proposed charter
> 
> I was of the impression reading the out of scope remark as being a
> decision to avoid discussion of the SENDER-ID fork of SPF, which has
> some show stopping issues that arguably stunted its implementation in
> favor of the MARID SPF draft.

Correct.  We are specifically and deliberately proscribing the reopening of those old debates with respect to SPFbis itself.  They serve no useful purpose here.

> I would think the
> SENDER-ID proponents and supporters may have gone to DKIM, if they
> found SPF V1 alone inadequate for their needs.

There are undoubtedly people that still believe Sender-ID is the way to go.  There's nothing stopping them from implementing it.

The fact is, however, that SPF has seen enough widespread implementation to warrant advancement to and along the Standards Track, so that's what we're doing.  It really is as simple as that.

As you've seen, there are always the grandiloquent among us that don't or won't believe such statements.  It's their prerogative to do so, but we shouldn't let them get in the way.

A substantial number of people behind this effort have no skin in the game in terms of the old MARID debates.  For example, I'm not even an active SPF proponent (I prefer DKIM) and I wasn't part of MARID, but I'm helping to advance this work because there's a need to encourage convergence on a single, standard protocol in terms of path authorization, and there are some things that want to build on it, but having SPF at Experimental is sometimes an issue.  So it really is time for this to happen.  I'm willing to put the work in, and circulating the charter is a call for consensus and for the like-minded to pitch in.

> I think you are in agreement with the thoughts that Brian Peterson
> offered regarding MUST vs SHOULD RFC arguments.

I believe RFC2119 defines MUST and SHOULD adequately, and I'll leave it at that.

> > 1) SPF receivers are NOT REQUIRED to ADD/OR enable the scope
> > extension,
> 
> Reasonable, as it goes back to keeping the integrity of what I think
> that SPF V1 was all about.

Right.  Moreover, I believe that falls within the definition of "extension".  Establishing such a requirement in the base document about an extension means a new version of the protocol, and that's not what we're doing here.  And that would mean the extension isn't really an extension anymore.  And the charter says clearly that major changes can't be made to the base specification itself, so the claimed contradiction doesn't exist.

> Again, here is where you lose me, I do not see what you are seeing.
> Perhaps it is me being thick headed, but is not the purpose of SPF bis
> to formalize the MARID SPF RFC draft into a standard RFC for SPF V1?
> If that is the case, then I'm not clear what the issue really is.

Ditto.

-MSK


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/6959934-50ec8f89
Modify Your Subscription: https://www.listbox.com/member/?member_id=6959934&id_secret=6959934-b7c4528d
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=6959934&id_secret=6959934-edadf31a&post_id=20111219020016:19075E56-2A0F-11E1-AD62-CC00FFE1F442
Powered by Listbox: http://www.listbox.com