On Aug 26, 2005, at 7:53 AM, wayne wrote:
In <7E876E12-3D43-4BFB-8F5B-76C3E985A610(_at_)hxr(_dot_)us> Andrew Newton
<andy(_at_)hxr(_dot_)us> writes:
But since you brought this up: if you (the author of the document) do
not consider this to be an experiment, then perhaps the IETF should
not publish SPF as an Experimental RFC.
I asked for the IESG to not consider the SPF I-D to be experiemental.
It was turned down. According to Ted, *none* of the IESG members
expressed interest in changing the status from Experiemental.
So far, no one has appealed that decision, and there are only a few
days left to do so. Like the appeal on the re-use of SPFv1 records, I
don't think it would be a productive use of my time to write an appeal
on the experimental status, and thus I won't do it.
If the goal of the SPF Classic draft was intended to capture a point
in time pre-dating semantic extensions related to RFC-2822 defined
content, then perhaps the draft should be on an historic track. ; )
SPF Classic has not achieved the goal of capturing a pristine version
of pre-MARID semantics. With some semantic changes introduced by the
SPF Classic draft itself, these potential semantic conflicts, as well
as those introduced by Sender-ID, have not been addressed. Prudent
accommodations were made within the Sender-ID draft however. The SPF
Classic draft has not found higher ground in this regard. Expecting
any standards group to retroactively arbitrate semantics restrictions
for a previously enigmatic DNS record would be disruptive. An
unfrozen SPF Classic draft adding provisions for a scoped version of
the DNS record would allow some percentage of publishers the means to
indicate their intended semantics when so needed. The conflict issue
being described seems specifically based upon a design flaw within
SPF Classic.
-Doug