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
