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.
Geez, I would swear Payload is Input. Well Output for the sender,
Input for the receiver.
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.
Huh? Why are you making this so complex with mumbo jumbo?
The PAYLOAD is SMTP 2822 mail packet/block/data (pick one). Lets not
confuse this ok?
DKIM is a process of validating a signed 2822 (header+body) payload.
Period.
That payload was OUTPUT for the sender, INPUT for the receiver. Its
relative. Its still the SMTP payload.
What is passed to external utilities is not defined. It could be the
entire payload or part of the payload.
What you need do to for DKIM is clearly define what are the process
parameters, what needs to the passed to other layers.
Can you equate the model DKIM (plus its "Assessors") using functional
definitions? for example:
DKIM_OUTPUT = DKIM_VALIDATOR(2822,BODY [,2821])
DKIM_RESULT = DKIM_ASSESSOR(DKIM_OUTPUT, 2822?, I=?, [,2821])
etc.
This will allow you to define and resolve your boundary conditions.
It will allow designer prepare their implementations so the
communications is resolved. It WILL even help define if process
separation will work, even dynamically or delayed and/or a tigher
integration is necessary.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html