SM, all, > It > would be better for the DKIM WG to meet its goals before starting a > discussion about Draft Standard. >
This would be reaching goals for the sake of reaching goals. I would note that an update isn't in the charter at all. I'm not saying don't do it. I'm saying that I would rather the group re-examine its goals and decide what the right approach is. Is there a dependency on the proposed changes to get ADSP out the door, for instance? What about the readability of the document series? Can one simply write an update that attempts to cut and paste from the original without adding confusion? And now that this is going to be a full blown update or -bis effort, what can be revisited? For instance, the approach I proposed, and many of my objections to the approach Dave and others proposed, was based on the notion that we were discussing an errata document and not a standards-track I-D. If we are to have a standards-track I-D, as I wrote quite some time ago, we have more leeway in changing DKIM. For instance, what is the proper way to deal with i= as a component of the standard? Should we deprecate it? This, by the way, is one of the problems I have with the chairs' approach. We (those who opposed the draft) were asked to tweak specific lines in the doc, while at the same time being told that the draft's final disposition is being changed by the AD. I still have other concerns. Ultimately I think there is a downside to being too constraining (the argument that John made earlier), that people will ignore the constraints. For instance, in this case, it's pretty clear that many people will ignore some of the terminology and just take d=, Sender:, From:, and potentially l= and the length, as inputs to identity assessment. And then they will use i= anyway. Saying otherwise, IMHO, *is* premature. Whatever. You're attempting to standardize secret sauce. Here's news: some people's secret sauce tastes bad (I always disliked Burger King's myself). Eliot _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
