ietf-dkim
[Top] [All Lists]

[ietf-dkim] why we should clearly specify domain existence

2008-05-25 02:10:59
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