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
Dave CROCKER wrote:
Current implementations are irrelevant. They will completely and utterly
ignore what is in 4871bis, because they are done and work fine. The problem
is whether we've introduced problems which will cause new implementations
to not interoperate with current implementations. Given the huge number of
changes, it's impossible to tell without getting real life data.
I quite agree that there's lots of text that's changing, but I'm having
trouble finding much in the way of actual protocol change.
An assertion that there have been problematic changes, such as going
violating
the requirements for advancing to Draft, needs affirmative, specific support.
"Too many changes" is generic and unresolvable and therefore cannot be
evaluated
and is unfixable.
What is "too many"? Where is the IETF basis for claiming that that criterion
prevents advancement? What specific changes are problematic?
These are the sorts of questions that a generic criticism should engender.
Reviewing changes does take a bit of work. In the IETF, folks making
complaints
are expected to do the work of making things specific.
Fortunately, it's relatively easy work. Time-consuming, perhaps, but not
cognitively challenging: Just look at the diffs across the draft versions.
Diffs are now provided automatically by the IETF's datatracker. No single
diff
is that massive. The one diff the datatracker does not provide is between
the
original RFC and the first Internet-Draft, so I've created one, albeit
between
the RFC and the /second/ version of the draft.
The references are conveniently accessible at:
<http://dkim.org/ietf-dkim.htm#rfc4871bis>
d/
--
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