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

First, the proposed charter has contradictions, like making out of 
scope the old MARID SPF vs SENDER-ID debates which is 100% pertinent 
to the idea of whether this scope extension is a good idea or not.  No 
way to have a legitimate engineering WG debate without highlighting 
the fact that the same reason to reject it will be the same reasons 
SENDER-ID was required to be a separate protocol.  Simply put, SPF is 
not a PAYLOAD technology, SENDER-ID is a PAYLOAD technology and the 
"twine shall never meet."  Introducing this scope in SPF violates the 
boundary layers.

Second, I don't pay attention to what that charter says (especially 
when written by this person, which I don't mind saying I have a hard 
time agreeing with his engineering thinking often especially when it 
comes to PRODUCT R&D) but how would the proposed extension by applied 
with 100% compatibility without FORCING it down people's throat.

1) SPF receivers are NOT REQUIRED to ADD/OR enable the scope extension,

2) Administrators adding a scope to their 5321.From domain that 
includes a scope:

    a) MUST NOT attempt to force preemption of the 5321.From check,
    b) MUST NOT assume receivers will support or honor the scope 
information,
    c) SPF receivers MAY honor the scope extension,
    d) SPF receivers MAY skip the 5321.From check

Regardless of what the charter says, this is the only way it can be 
implemented without harming current operations.

The design issue will be how to best leverage this scope extension the 
proper way which means under what the SPF boundary conditions available:

    NONE          n/a
    PASS          Is scope used as a double check?
    SOFTFAIL      Seems more applicable here.
    FAIL          Should scope override 5321 level SPF "HARD" failure?

Thanks

-- 
Hector, Engineering & Technical Support
Santronics Software, Inc.
http://www.santronics.com (sales)
http://www.winserver.com (support)
http://www.winserver.com/AupInfo (Online AUP Help)

Commerco WebMaster wrote:
> Brian,
> 
> Excellent point.  MUST defines the absolute minimum criteria for 
> compliance with an RFC.  SHOULD often defines best practice additions 
> which extend an RFC.
> 
> As the charter of this RFC bis, as I understand it, is not to add any 
> functionality (required as MUST or otherwise) to the existing draft 
> specification from which the bis shall become based, the argument over 
> extension compliance for this process seems moot.
> 
> If there is a desire to add functionality to the specification as a 
> requirement to implementation (a MUST case) then perhaps that is for a 
> V3 or V4 SPF task force to hash out.
> 
> Alan M.
> 
> On 12/18/2011 10:25 AM, Brian G. Peterson wrote:
>> On Sun, 2011-12-18 at 09:29 -0500, HECTOR SANTOS wrote:
>>> Thats fine, and yes Extension are Extensions when mean OPTIONAL. So
>>> anything new added to the RFC bis, MUST NOT be rammed it down people's
>>> throat using odd readings of RFC 2119. In other words, people are
>>> still compliant with SPF and SPF BIS while completely ignoring this
>>> ILLEGAL CROSS BOUNDARY scope extension.  I don't want to see
>>> statements like you made recently such as:
>>>
>>>          "Put another way, you can't claim compliance with this document
>>>           unless you apply the SHOULD, but extant implementations are
>>>           otherwise completely unaffected.
>>>
>>> IOW, you CAN NOT make this cross boundary scope extension a SHOULD for
>>> SPFBIS if you truly believe what you stated.   If you feel
>>> differently, then this not BIS work but a new protocol and new mandate
>>> for a new version of SPF - a different protocol.
>>
>> I'm not taking sides here, since I am not really familiar with the
>> technical details anymore, but a implementation is compliant if it meets
>> all of the MUST directives.
>>
>> SHOULD directives have always been strong recommendations, but in no
>> standards process that I have ever been associated with (and there have
>> been many) have the *recommendations* in SHOULD directives been required
>> for compliance. You may not have as broad of interoperability as you
>> would like without implementing SHOULD directives, but that doesn't mean
>> you are non-compliant.
>>
>> Now, I would suggest from plain meaning of the word 'Extension' that no
>> extension would ever be required for standards compliance. MUST and
>> SHOULD directives could still be applied within each extension method to
>> make the *extensions* compliant and inter-operable with each other.
>>
>> Cheers,
>>
>>      - Brian
>>
> 
> 
> 
> -------------------------------------------
> 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/993478-34c23837
> Modify Your Subscription: 
> https://www.listbox.com/member/?&
> Unsubscribe Now: 
> https://www.listbox.com/unsubscribe/?&&post_id=20111218183619:14698A1A-29D1-11E1-B863-E166C5ACC682 
> 
> Powered by Listbox: http://www.listbox.com