I need to understand better what precisely you are asking for. When you had
suggested a mechanism other than 'dns' to use in the q= tag within the
signature header I took that to mean you wanted a non-dns based method for
fetching DKIM key record information. This is entirely a different thing
from what I've seen here:
> All I want to do here is to allow someone who has
> a key to advertise the existence of additional information
> defined using the existing accreditation mechanism.
"Additional information" doesn't sounds like a DKIM key record. So, I think
I've gotten confused (sorry all) but maybe there are others in the same boat
with me.
I'm in there with you, and as a matter fact I just finished sending private
mail to Phillip asking more or less the same thing as you're asking here.
So, (a) what is the nature of this "additional information" - is it the DKIM
key record or something else? and (b) why would this be critical to the
initial round of specification?
Assuming for the sake of argument that what's being asked for is a slot in the
DKIM key record to point at accreditation information, I see nothing in the
current charter that would prevent us from defining such a tag. IMO defining
a place to store a link to an accreditation system in no way qualifies
as actual work on such a system.
I also happen to think that defining a place to store such a link in the base
specification would be a good idea. While this could certainly be done as an
extension, I think getting people started thinking about the linkage is a good
idea, and defining the slot for it is a good way to do that.
Ned