[ietf-dkim] Output summary - Purported Author

[Hector Santos]

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