The question one has to ask is broader than inputs and outputs. Are
each of the protocol elements described in the specification clear
enough to be understood as to their meaning? If they are not then that
is what needs to be clarified. Regardless, this debate about functional
programming (which is really what this boils down to) is pointless, and
you are ossifying a structure around a model that you needn't do. As we
have seen many times at the IETF, successful specifications are those in
which the model can easily evolve over time based on circumstances.
This is precisely the case with DKIM, where the AD's and the IESG's
intent was to walk slowly before we run. The DKIM specification
reflects that intent.
Your errata reflect a different intent.
Eliot
On 2/17/09 4:38 PM, Dave CROCKER wrote:
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/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html