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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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
