ietf-mxcomp
[Top] [All Lists]

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

2005-08-25 17:07:00
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Douglas Otis wrote:
As with any conflict, there are two parties involved.  In this case,
the SPF group has essentially ignored potential conflicts by
neglecting to include support for a subsequent version of the DNS
record.  This newer record explicitly expresses the intended scope.
At the MAAWG meeting in Dusseldorf, Julian suggested SPF developers
would only consider use of the newer DNS record version provided
Sender-ID abdicated use of the initial version of the record.  Sender-
ID supports both versions.  An appeal was made for the SPF group to
consider supporting the newer version of the record as a solution for
avoiding this conflict.  This suggested use of the record is part of
interim advice on the MAAWG website.  It would appear this appeal
reflects a decisions to remain intransigent.

You are misrepresenting the SPF project's intentions.

We are still open to support "spf2.0" or even an "spf2.1" (with some of 
2.0's other issues resolved).  "Support", however, does _not_ mean to 
s/v=spf1/spf2.0/ (sort of) in draft-schlitt-spf-classic, which as the 
name implies is supposed to document the classic version of SPF.

The reason we have decided to file this appeal is to protect existing 
(legacy, if you will) "v=spf1" records from any misinterpretation sanc- 
tioned by the IETF.  Beyond that, almost everything is negotiable.

While this conflict should be resolved, without evidence that Sender-
ID has fallen out of favor, which the stance by the SPF group
prohibits, the obvious solution would likely be for the SPF group to
finally adopt the newer record version.

The declared policy of the SPF council, the project's elected leading 
group, is _not_ to bring down Sender ID (although it is probably true 
that many would like to see that happen, me not included), but to promote 
SPF and to ensure that its reputation doesn't get tarnished by the 
unnecessary misinterpretation of v1 policies by Sender ID.

The SPF council can very well see promoting a polished "spf2.0", as long 
as "v=spf1" is left alone.  It would probably not even be a point of 
contention if PRA was an _optional_ part of that specification (as it is 
now with "spf2.0", as opposed to "v=spf1", thanks to draft-lyon-senderid- 
core-01).

Julian.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDDlqJwL7PKlBZWjsRAkv9AJ9u9rE2bwGlmNZSmebNNFke80Fx+QCeMmIY
ZfO7UzZus5h0ZGYN1B9YUbc=
=e5dm
-----END PGP SIGNATURE-----

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

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