-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Statements that imply the i= value is always OPAQUE prevents its
utilization for highlighting purposes with respect to identity
assurances, even when there is an exact match and this value could be
said to not be opaque. This also seems to conflict with the defined
use of the i= value as representing on whose behalf the signature was
added. There should be an exception spelled out for exact matches.
Forgive me for this short rant and applying a riding crop to this
horse, but when you say:
"Statements that imply the i= value is always OPAQUE
prevents..."
You are correct.
However, the fact that you do not wish it to be opaque does not make
it transparent. It is opaque. It is not in "... conflict with the
defined use..." because it *IS* the defined use. It is not your
*desired* use, but it is the defined use.
Why is it so hard for you to just write a followon RFC to DKIM that
has an Identity Accessor or whatever you want, that you stick in some
header and sign *that*, rather than continuing to insist that i= is
what it is not?
For all the effort we keep spending declaring that the sky is green,
we can just go get some nice tinted lenses.
I *support* creating a header that is what you want, but really,
that's not what is in DKIM-base. Just write up an I-D defining the
header you want!
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFJiwFQsTedWZOD3gYRAkhTAJ9bagjCETiu0Vitix1tiHeo46NezACg7PCl
NQhn0cUi5hKpP+GoVYYt2h0=
=gZs7
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html