Dave,
Dave Crocker wrote:
newest Draft Charter:
the DKIM working group will make every reasonable attempt to keep
changes compatible with what is deployed, making incompatible changes
only when they are necessary for the success of the specifications.
versus
Stephen:
I don't believe there is a
requirement for the dkim standard protocol to be backwards
compatible on-the-wire with what's deployed today, but rather
that the dkim standard be such that it's not a problem to migrate
from today's deployments or perhaps even to run them in parallel.
Folks have been expressing support for the new charter text. I'm
inclined not to perturb that, but have a continuing concern that forces
me to probe one issue: We should make sure that there is a reasonably
clear view of priorities for preservering installed base... or not.
I agree. I think the clearer we can get on that, the fewer arguments
about this that there'll be (though there'll always be some:-)
But, I think the charter text is fine btw.
Is it ok with folks to be required to replace essentially all of the
current software, administration and user deployment?
That's three things.
First, the current s/w will have to change since we're changing
the signature construct (c14n & maybe the digest thing). Since
its signing, a single bit is enough to require new s/w anyway
and there's 99.999% certainty that we'll at least change
one bit in an on-the-wire imcompatible way. Don't you agree?
Once that happens, many further changes have no additional impact
on incompatability, but of course, all changes do need to be
justified.
Secdondly, how admin is done isn't really part of these protocols,
except to the extent that an argument can be made that such-and-such
a proposed change makes admin of both old and new harder. Such
an argument is valid, but of course, its impact varies depending
on how many implementations are affected, where the proposed change
sits on the "nice"..."REQUIRED" dimension etc. So we can't settle
such arguments in advance.
Thirdly, I'm not sure exactly what you mean by "deployment", but if
you mean that the (distributed, virtual) database of policies and
public keys SHOULD still be usable with the output of DKIM, then
I'm totally sympathetic with that. (Using some new optional feature
of the standard might require adding new policy data of course, but
that doesn't break existing deployment, in the sense above.)
If there're other relevant aspects of deployment (or "incompatbility")
that we ought be considering when someone proposes a change, It'd be
really good to describe them now.
The new draft charter would seem to impose a very high barrier on
changes that render the new specifications incompatible with existing
implementations. It's language is similar to that of other IETF efforts
that seek to minimize incompatibilities.
However Stephen's comment creates a much, much lower barrier, and is
concerned only with stored data that are queried.
That's taken out of context - I was trying to get to the strongest
requirement for what-not-to-break. There is no "much lower barrier"
here.
Both are views reasonable, depending upon community need. My guess is
that the IETF's version of DKIM will deploy in about a year, if we are
lucky. So that the migration disruption would occur around then, and go
for a year or two.
(For reference, the DKIM pre-IETF effort similarly debated this point
extensively, relative to DomainKeys compatibility. It's never an easy
choice.)
You're right. There are a range of reasonable views here, but as in
most such situations, those on the far-right and far-left are far
from reasonable:-)
So while we don't have a precise definition of "incompatible" (and
probably never can, at least not in something the length of the
charter), I think the situation's nearly as clear as we can get it
for now.
Stephen.
PS: I still didn't hear much about what specific parallel scenarios
we'd like to support btw. e.g. if a single message can have both
new and old signatures from the same domain, do we require that
the same public key be usable to verify both, or should we remain
silent on that, or something else? And which of those signatures
should encapsulate the other, or do we care? ...
d/
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org