I think this message by Barry in March 2009 summarizing a conference
call between Pasi, Stephen and Barry nicely captures the upper/lower
layers, ADSP, i= and outputs conflicts that continue today:
http://mipassoc.org/pipermail/ietf-dkim/2009q1/011314.html
Perhaps Dave to lower confusion, you need to remove the "Checking
Signing Practices" process module from the DKIM Service Architecture
or perhaps consider changing the title:
DKIM Service Architecture with optional ADSP support
Extended DKIM Service Architecture
To ADSP or not ADSP, that is the question.
--
Sincerely
Hector Santos
http://www.santronics.com
Hector Santos wrote:
> Dave,
>
> My perspective was that the "damage was done" per se in the last
> errata and changes with this bis are irrelevant and don't reflect
> current existing implementations. Code changes are not necessary for
> current implementations because they already follow the DKIM Service
> Architecture with does include ADSP support. However from a strict
> RFC4871bis and the proposed Output Summary standpoint, it does not
> reflect with complete DKIM Service Architecture (RFC5585), as it was
> written, so it be told.
>
> Its really a simple matter from my engineering perspective and if I
> was confusing the DKIM requirement with ADSP requirements, I am not
> the only one. There is a clear history of this in the WG and I don't
> see anything reducing the "confusion" or as I prefer to call it,
> inconsistencies.
>
> One simple Bug Fix:
>
> Add Author Identity to the Output Summary with a reference to Checking
> Signing Practices per RFC5585.
>
> Thanks
>
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
