Eliot Lear wrote:
For example, Eliot's draft does not attend to the basic requirement for
specifying what is primary output.
...
And that is because it is not a basic requirement; and in fact hits
against our charter limit of discussing reputation systems. You've
cleverly couched this debate in terms of interoperability, but what are
we really talking about? It's the input to reputation services, no
matter what terminology you throw at the matter.
Eliot,
You are confusing the difference between output and input. DKIM Signature
output, versus Assessment input. The Errata discusses the former, but you are
referring to the latter.
Protocols have payload, or output. A protocol that does not specify what its
payload is is not complete.
Take a look at Figure 1 in the new Deployment draft:
<http://dkim.org/specs/draft-ietf-dkim-deployment-03.html>
Note the transition from Identity Validator to Identity Assessor. The former
is
part of DKIM; the latter is not. But that transition entails delivery of the
payload by DKIM to its receive-side consuming module, the Assessor.
The current RFC 4871 does not specify what its payload is, versus what is
internal to the protocol operations. The DKIM-Signature: header field contains
both DKIM internals and DKIM payload. Which is which?
Take a look at the TCP Header Format diagram in the TCP spec:
<http://www.rfc-editor.org/rfc/rfc793.txt>
Note the field at the end labeled "data". That's payload.
The DKIM spec has no equivalently clear and precise definition of its payload.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html