[ietf-dkim] Output summary - Purported Author
hsantos at isdg.net
Sat Apr 30 01:55:15 PDT 2011
>> 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
verifier return status
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
More information about the ietf-dkim