Jim,
I think this is at least the second time I've seen you offer this line of
commentary and I still don't understand it. On its surface, your comments seem
to me to be a complete non sequitor with the question at hand.
The best I can guess is that you think that distinguishing payload from
protocol
internals somehow creates an access barrier to the internals. I can't guess
what your evidence for this conclusion is, since the history of value-added
APIs
goes against your claim.
In general, seem to be confusing protocol definition with API definition, and
yu
seem to be claiming that ensuring specification discipline and clarity somehow
prevents later protocol enhancement, although it demonstrably does not.
d/
Jim Fenton wrote:
Dave CROCKER wrote:
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?
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html