-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Thursday, April 28, 2011 3:24 PM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary - Mandatory Outputs
Rather I am highlighting the limited DKIM output requirements is
outdated and insufficient to support today's (extended) DKIM mail
integration and security needs outlined by WG consensus-built RFC
documents:
DKIM Security Assessment (RFC4686)
DKIM Service Architecture (RFC5585)
DKIM Deployment Guideline (RFC5863)
DKIM Signing Practices (RFC5617)
DKIM Reporting using A-R (RFC5451)
Please show me any citation in RFC5451 that demonstrates your claim.
Here is a way to view the old vs new design dilemma:
SMTP vs ESMTP (Extended SMTP)
We have decades of engineering foresight to not repeat completing a
protocol design with an outdated limited output scope especially when
extensions are already available.
And we're not. To use your analogy: DKIM returns a status and "d="; extended
DKIM (whatever that means) can return that and more. We're updating the
specification of DKIM here, not declaring what extended DKIM might be.
It works just fine.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html