[ietf-dkim] a protocol needs a payload

[Hector Santos]

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