SM wrote:
Murray stated:
This is why moving to DS is not allowed if we add stuff, only if we
remove stuff. So far, unless I've missed something, that's all
we've done.
DS is not about not adding stuff and removing stuff. The advancement
is about the maturity of the specification. This can be gauged in
terms of implementation and interoperability.
There are different approaches for such a move; a conservative one
where changes are narrow to avoid destabilizing the specification or
one where the rationale is changed without affecting the
requirements. This case can be argued both ways. I prefer to see
implementer buy-in than a label in name only.
+1 Thanks for your input SM.
I think we have four in-scope outputs that are non-spec nor code
changing and are 100% compatible with the DKIM Service Architecture
[RFC5585] and existing implementations that support the RFC5585
architecture.
verifier return status
d=
i=
From:
We have implementations and API libraries that inherently support
Checking Signing Practices (CSP) as shown in RFC5585. This inherent
support came with the original SSP support when DKIM and Policy was
one and was only modified to ADSP [RFC5617] definition.
I would like to also note that RFC4871bis has added references to
AuthRes [RFC5451] and with this official inclusion, we began to
support it and that required code changes to the API, but it is not
mandatory if you only stick with reporting the first three outputs
(status, d= and i=).
More importantly, if RFC5451 reference was compliant with DS, I would
suggest adding a reference to RFC5585 DKIM Service Architecture is
more justified and DS compliant and doesn't promote any current
implementation code changes and better prepares future implementations
with the proper DKIM output values.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html