Dave CROCKER wrote:
Murray S. Kucherawy wrote:
On Tue, 17 Feb 2009, Jim Fenton wrote:
But -rfc4871-errata-02 defines this backwards. The erratum makes
everything else internals, which eliminates a lot of information
that might be useful to a downstream assessor. For example:
[...]
Perhaps this is a terminology question.
No, the confusion is much deeper than that. It's about a protocol
layering and protocol specification scope.
The fact that upper layers sometimes reach down into lower layer
information, and the fact that this is sometimes useful, does not
eliminate the nature of the layering or the fact that there is a
layering violation. Protocol layering is a matter of design
discipline, not just terminology.
This is part of the reason that it's important to recognize that upper
layers may wish to make use of additional information in the signature,
and not only the signing domain.
In this case, it appears that Jim is confusing the sole stated goal of
DKIM:
"permitting a signing domain to claim responsibility for the
introduction of a message into the mail stream"
with other useful goals. He's conflating these other goals, such as
validation of message content, into the DKIM Signing spec, on the
theory that someone, sometime, might want to do it a variety of
yet-to-be-specified functions.
The DKIM signing specification is a base which may be extended. It is
for that reason that we worked hard to make sure that the base
specification was extensible (addition of tag/value pairs, for example).
Apparently the feeling is that any constraint in the Signing spec will
somehow prevent value-add functions that go beyond the spec.
When the specification describes specific payload values, and makes
extensions and other values that might be useful "DKIM internals"
requiring a layering violation to access, it does seem to be
discouraging value-add functions.
But again, why is this part of the erratum seeking to resolve d=/i=
confusion?
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html