I think it is inevitable that we will propose additions. In particular I
think it is inevitable that we will end up specifying a new
canonicalization algorithm. That's why I argued that the original spec
should only have two (because we should not have more than three).
I think the objection is met if we introduce the work 'backwards' in
front of 'incompatible'
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen
Farrell
Sent: Thursday, October 13, 2005 10:19 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] DKIM BOF -- draft charter and agenda
"The working group recognizes that a significant amount of
infrastructure and deployed software already compatible with the
input specifications currently exists. The working group will
therefore make every reasonable effort to refrain from
introducing
incompatible change."
I like it.
This can open up a political can of worms.
I agree that the can is open, and that we ought impose some
compatabililty requirement in the charter.
However, I'd quibble with the above (which is btw, *much*
better than the "minimal" phease), in that 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.
(Questions: Is parallel operation needed? If so, need that
apply to a single message?)
Concrete example: if the dkim wg decided to move the
DKIM-signature field as input to hashing from after the body
to being the first input (e.g. so we could perturb hashing
with some of our own randomness), then that'd be incompatible
on-the-wire, but no problem for migration.
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org