On 5/4/11 10:01 AM, Dave CROCKER wrote: > Folks, > \ > In terms of working group process, one line of criticism demands re-opening > (and, apparently, reversing) the work of the Update (RFC 5672). I haven't > seen > any working group consensus to do this nor any industry feedback indicating > this > is necessary. Consequently, attempts to pursue the content of that work is > entirely out of scope for the current working group effort. > > There are two continuing threads of other, technical dissatisfaction being > expressed that are based on fundamental misunderstandings of protocol design > concepts. The discussion on Wikipedia looks pretty good, for background: > > > <http://en.wikipedia.org/wiki/Network_protocol#A_basis_for_protocol_design> > > The easy misunderstanding is about the basic difference between software > design > and protocol design. When a discussion is about a protocol specification, > reference to the vagaries of software implementers' choices means that the > discussion is no longer about the protocol. > > A protocol is a contract between two or more sides of an exchange. The > contract > needs to be extremely precise so that all sides know exactly what is required > and what is meant. This includes semantics, syntax, and rules of exchange. > Semantics means all of the meaning, not just the meaning of individual fields. > And it means inputs and outputs. DKIM is unable to _only_ consider signature confirmation and not also expect existing email agents to not also adopt DKIM's unusual header selection methods retro-actively. To be compatible with existing email infrastructure and transparent to the fullest extent possible, one can not expect new supporting infrastructure or modified clients; This can *only* be achieved by some mandatory test within the Verifier.
-Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
