OK, so now I guess I'm confused. My understanding is that if "i=" isn't
specified it takes the value of "d=", so I'm not clear how it can be
undefined?
Maybe the wording of the errata draft could be improved (I'll propose new text
shortly if I can), but here's my understanding:
I believe you're confusing the semantics of the DKIM signature with the
definition of the DKIM interface.
Again, think of this in terms of an API definition. Let's say you're building
a DKIM library to sell or give away. Obviously you need to know what outputs
are required, i.e. what application developers will expect from you.
The errata draft is attempting to state clearly that the output of your library
has to include the yes/no result of the verification and the "d=" value. It
can include other stuff at your discretion (you might even find that most
assessors, the consumers of your library, want a lot more than that), but
that's the minimum you have to provide to a consumer in order to be able to
claim you are DKIM compliant.
It's not stating at all what the implicit value of "i=" is relative to "d=".
In this context, that fact is irrelevant.
Think of another example, like the socket interface to TCP vs. the TCP protocol
itself. There's what's going on in the protocol stack and then there's what's
going on in the C libraries we actually use. Could be that the language used
in RFC4871 and the errata draft don't make that distinction clear, but I
believe that's what we're trying to achieve here.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html