Agreed, indeed part of the logic for only providing two options in the first
place was because we knew we might need a third later.
I don't think that the C18N issue we face is as challenging as the MIME one as
we are initially only looking at edge to edge not end-to-end (or at least
end-host-to-end-host, the end being the user not the machine).
The other expectation that we might have that did not apply to MIME was the
expectation that deployment would drive conformance. The penalty for modifying
the content is now much greater.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave Crocker
Sent: Wednesday, December 06, 2006 12:52 PM
To: DKIM
Subject: Re: Fwd: Re: [ietf-dkim] Introducing myself
Wietse Venema wrote:
Charles Lindsey:
That was quite some time ago, so to refresh your memories,
I had been
claiming that DKIM-base would fail to verify if some
message had its
Content-Transfer-Encoding changed en route, and that it
proposed to
get
...
When DKIM signers and verifiers are requird to up-convert QP or
Base64 content before computing signatures, we also require
that all
DKIM signers and verifiers have bug-compatible MIME processors.
That is, bug-compatible with every MUA.
Introducing this extra requirement is unlikely to help with the
successful adoption of DKIM.
Canonicalization has been recognized as a *very* challenging
topic for at least
15 years of Internet mail work. It was a major focus for
MIME, it was a major focus for DomainKeys and it was a major
focus for DKIM. (I'm sure it's been a major focus elsewhere,
but this list will suffice.)
My own summary is that we know we can trade between high
qualitysimplicity and robustness/fragility. There seems to be
no perfect choice.
This invites infinite discussion. We should decline the invitation.
DKIM permits more than one canonicalization scheme to be
defined. The current set is the result of lengthy discussion
and even experience. As Stephen notes, the list can be
extended, without requiring that we replace any existing entry.
If the current set proves problematic *in the field* then we
can add more... later.
We most certainly do *not* need to add consideration of
additional schemes to the current public discussion, given
that the focus now should be on adoption and use of the
current specification that has benefited from a couple of
years substantial effort.
That said, as Stephen notes, anyone is of course free to
write an Internet-Draft proposing additional schemes.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html