You have generalize ASSESSORS to have two minimum inputs:
BOOLEAN (DKIM verification result)
STRING (DKIM D= value)
Correct.
1) Why?
There is use in specifying an API here. Every other protocol we've named so
far as examples have an API, whether de facto from lots of experience, or
implicit from the spec that defines it the protocol, or something actually
explicit defining the API. There's no evidence that this is a bad idea.
Do you have a specific ASSESSOR in mind that is only
privy to certain people?
Nope. And let's stop with the insinuations that there's something secret going
on here.
2) How does a DKIM implementation generalize the fixed prototype
to satisfy newer ASSESSOR that require different input? You
are going to need some protocol that defines the input
requirements for the specific and different assessor.
Yep, and nothing that's been said so far precludes this idea. Defining a
minimum does not also automatically define a maximum or establish other
constraints.
So if you write an API in any of the dozen languages of expertise you claim, as
long as it takes at least a message as input (and other stuff, if you wish) and
returns at least the result and the "d=" value (and other stuff, if you wish),
you're compliant. You can provide *any* other hook into the API you want, but
as long as you do that minimum, you're good to go.
What's an example of an API you might need which is broken by that simple
requirement? You may use any language or data structure you wish for this exam
question.
The more general function prototype is to provide the entire process
environment variables, this is 1000% better for the general population
of developers of accessor routines:
ASSESSOR_RESULT is a function of SMTP data + DKIM result
Yep. And the only part of this that we're discussing is "DKIM result"; the
proposal is to define that as "at least the verification result and the value
of 'd='". The rest of this is outside of RFC4871's scope.
this allows for example,a SMTP system to run a wildcard filter
FOR EACH ASSESSOR in ASSESSORS.LIST
RESULT = EXECUTE( ACCESSOR, ENVELOPE, PAYLOAD)
IF NOT RESULT
THROW EXCEPTION, RETURN FALSE or whatever
END IF
END FOR
Yep. And nothing I've said blocks such an implementation.
That is general fit all never fail model. I'm pretty sure it applies
to everyone, even you.
Yep.
In short, it is the unspoken ASSESSOR API limited to two fields that
needs to change to better fit a generalize global SMTP/DKIM model.
This is a false conclusion. The assessor is not constrained or even discussed
in the proposed change. If the assessor needs, let's say, the value of "i=",
then it just needs to use a verifier that makes it available. Such a verifier
is compliant as long as it also makes the DKIM verification result and "d="
available.
If don't your suggested way, then its becomes harder to program
because it will look like this:
FOR EACH ASSESSOR in ASSESSORS.LIST
PARAMETERS = QUERY_ASSESSOR_REQUIRED_DATA(ACCESSOR)
RESULT = EXECUTE( ACCESSOR, PARAMETERS)
IF NOT RESULT
THROW EXCEPTION, RETURN FALSE or whatever
END IF
END FOR
I'm confused again by your notation, so I can't really respond to it, but this
doesn't look a lot more complicated to me than your other pseudo-code above.
EXECUTE will now have to create the proper function prototype stack
with the variable list parameters in order to satisfy specific
ASSESSOR APIs with different functional prototypes.
No. Each assessor will feed a message to the DKIM API and get back the result
and "d=". If it wants more, it just has to ask for whatever the "more" is from
the API as well. This might be additional parameters to the same function, or
subsequent accessor functions. In any case, I don't agree that this is
complicated.
The assessor is free to pick any DKIM API that provides what it needs. All the
errata is saying is that all DKIM APIs must return, at a minimum, the "d=" and
the evaluation result. There are no other limits imposed.
Just providing feedback on years experience of developing an a high
end SDK/API for C/C++, DELPHI, JAVA, PHP, VB, .NET languages and three
basic API models; native, COM and .NET.
You're not the only developer on this list with decades of professional
experience in multiple environments, Hector. Let's leave the resumes off the
list, please. We're here to co-operate, not compete.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html