It's my opinion that it isn't very likely that there needs to be any breaking changes to DKIM itself. DKIM already has the provision that unknown tags are just to be ignored, and DKIM is already capable of signing whichever new headers we come up with. Take the proposed modifications algebra: there is no reason it can't be a tag or even a completely new header that DKIM just signs. Same thing if you wanted to copy in the envelope.rcpt-to to the message. It doesn't seem necessary to involve DKIM itself. It's quite likely that such new headers could be useful in other contexts, so it would be better to abstract them from what DKIM's needs might be.
To me, the charter should say something like "Solutions that do not involve breaking changes to DKIM (rfc xxx) should be preferred unless it is absolutely necessary. Where a breaking change is something that a naive receiver verifier would not be able to verify even if doesn't take advantage of any new features. This would vastly simplify transition and leave it to receivers judgement whether making the upgrade is worth it.
Mike, forklift upgrades almost never work _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
