I've said that it is important to state what protocol behaviors actually
are. My reasoning is really quite simple: if we don't specify behaviors
it leads to one of two outcome:
* a conservative defacto standard that constrains the architecture
to what exists today, and no more. A perfect example of this is
what happened with NAT. Because the IETF wasn't ahead of the
curve, we failed to at least state safe behaviors, which led to
all manner of inconsistent behaviors, which meant that
applications could only rely on a handful of protocol operations
being carried out at the transport level. In other words, if we
don't say anything we will lose our opportunity to really have a
say, and we won't like the results.
* a plethora of special code that is engaged based on what vendor
implementation one side detects the other side using. This is
what has happened with the web, javascript, ActiveX, et al, where
the cost of development of a commercial site has been increased
because of special code requirements for the various different
browser technologies. It also introduced barriers to entry, which
are IMHO Bad.
In the case of DKIM, if we specify a conservative check – meaning that
if any of a number of records are present (say, MX, A, AAAA) – then we
will allow for uses of disconnected connectivity, some of which exist
today, and others of which may exist in the future. This is equivalent
to the rfc2821bis outcome, if I am not mistaken. It meets John Levine's
stated concern that we not specify an additional mechanism, and I
subscribe to that notion when there is not strong ground to do otherwise.
Some will argue that we don't know the right answer and that operational
experience may teach us differently. Fine. This is a proposed
standard, and not emblazened in stone. Some might argue that recipients
will do what recipients will do. So they will. As Dave Crocker and I
once wrote in the title of an RFC, some practices shouldn't be codified.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html