Tony Hansen wrote:
Whether it were done by adding semantic signposts for i=, additional tag
values, or additional 5322 headers, it should *not* be done in an ad-hoc
fashion.
+1.
From my perspective, we are beyond the idea of whether i= or a new
st= tag is needed or not, but rather whether the proposed standard
provides sufficient guidelines for the modelers to implement and allow
extensions to exist.
Case in point:
Any installed base of DKIM system designed using popular open source
DKIM APIs, would not ready to support DKIM-Signature tags extensions
without change.
However, due to the DKIM standard fundamentally requires
implementation flexibility to sign user-defined RFC5322 headers with
only one minimum requirement to sign 5322.From, implementators must
follow this technical design requirement to allow systems to add
additional headers to be signed, whether it is well-known or not.
Then is its reasonable to suggest to add some text to the proposed
standard (now, not later) that provides some extensions guidelines
starting with two off the top my head:
- DKIM implementators SHOULD allows adding non-standard tags to
the DKIM-Signature
- DKIM Extension namespace naming convention for adding
Extra Headers or tags.
If we think extensions will be an important part of DKIM future then
we need to make sure we provide the semantics to allow extensions to
be explored and co-exist with wider DKIM installed base support
without needing to revisit the RFC 4671 specs.
Even if one suggests that a new RFC for "DKIM Extension Design
Guideline" would suffice, until that is done, we still need some
additional text in the proposed standard to that should be a
implementation consideration.
Maybe a single sentence to advise developers to allow this flexibility
to exist is all that is needed.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html