Hi Eliot,
At 00:30 22-03-2009, Eliot Lear wrote:
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
Without goals, we don't have a clear path stating what we want to
achieve. I don't think that we should reach goals for the sake of
reaching them.
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?
I'll skip your question about ADSP for now. Before doing any change,
we should take into account its effect on the document series.
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?
I agree with your point about having more leeway if we are discussing
a Standards-Track I-D. There has been discussions about making DKIM
leaner by dropping some components. If we drop i=, then we introduce
a change that affects ADSP.
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 won't question the Chairs' approach.
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).
In my opinion, people will take whatever input they view as useful
for an assessment. There is nothing we can do about that except to
say "don't do it". John Levine made a good point about interoperability.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html