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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html