Jim Fenton wrote:
By remove, does that mean implementators can safely begin to not offer
it for Domain signers to use or consider?
I should probably have used the term "deprecate" rather than "remove".
That's correct, an implementation compliant with 4871bis would not
normally use the i= tag/value in signatures.
Ok, so if we begin to "REMOVE" it from the documentation, which I
think would be better because deprecation suggest some documentation
regarding the deprecated mechanics remains, the question is then is
what advice is provided to current DKIM verifier implementations in
regards to being prepared to handle legacy usage.
In other words, for current DKIM signers, the advice might be they may
begin to not offer it in their Signer Setups and for future DKIM
signer setups, to not consider it at all. For example, this is right
on for me because we are still getting all the setup and GUI help done
and removing i= tag would be great to finishing it. I don't have to
worry about past signer compatibility versions so I can just get rid
of it.
But for verifiers, old or new, the question is whether the software
can be simplified to remove the handling legacy usage. The issue is
not that software can keep the old logic intact even its not going to
be used, the issue is when legacy usage is found, what outcome comes
from it?
Off hand, and I have to go back, I believe seeing some systems using
Authetication-Results to always include a i= as part of its A-R header
result whether it was defined or not and when not, a default value is
displayed. For example, this is the A-R result for my signature into
this IETF-DKIM list:
Authentication-Results: sbh17.songbird.com;
dkim=pass (1024-bit key) header.i=@isdg.net
My isdg.net signer domain setup does not have a i= defined, yet it is
showing one in the A-R record when verified by sbh17.songbird.com.
Does that mean, a proposal to remove i= in DKIM-BASE, would imply an
update to the A-R draft is necessary?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html