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