>> 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