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