API Definition? The socket example? Come on.
BTW, What is the definition of an Application Programming Interface
and what portion of DKIM is like an API definition.
This is incomprehensible, overdone to get some simple concept across
that only needs 1 or 2 paragraphs. Dave, these paragraphs is really
obscure. You can do better and get this API angle out.
If you going to this level, you need to be more specific with software
engineering terminologies and how it applies to SMTP. Murray's API is
not going to be same as MY API or that guys API and it may not be just
in C or C++, but in multiple of languages, and the API be COM
interface, a .NET interface, including a JAVA interface. It may come
in the form of shims, hooks, callouts, triggers, events or what have
you.
If the functional model is attempted be described, a simple paragraph
that ALL developers with SMTP knowledge will understand might be:
DKIM Verification and Assessors Processing can be done during
the SMTP session or post acceptance level. In order to provide
assessors the available data it might need, the DKIM
verification result, the RFC 5321 envelope fields and RFC 5322
payload SHOULD be made available for internal and external
Assessor processing.
At a minimum, the DKIM verification result and the DKIM-Signature
signing domain identity (D=) value MUST be made available to
assessors.
How the information is provided to Assessors is implementation
dependent and not in scope of this document.
Simple? Huh?
---
Dave CROCKER wrote:
MH Michael Hammer (5304) wrote:
+1
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
Hmmm. Noting two quick +1s to Murray's text and in the interest of still
trying
to bring this "quick" errata/update effort to a close, I'm inclined to
suggest
adding his explanatory text to the existing proposed addition.
While it's entirely plausible that Murray can formulate a superior version of
the basic text for the addition, I think that the existing +1s for the
existing
text and the +1s for Murray's commentary offers us something quicker.
So, here's a suggested merging of the two:
<t>This currently leaves signers and assessors with the potential for
making different interpretations between the two identifiers and may
lead to interoperability problems. A signer could intend one to be
used for assessment, and have a non-reputation intent in setting the
value in the other. However the verifier might choose the wrong value
to deliver to the assessor, thereby producing an unintended (and
inaccurate) assessment.</t>
<t>This update resolves that confusion. It defines additional,
semantic
labels for the two values, clarifies their nature and specifies their
relationship. More specifically, it clarifies that the identifier
intended for delivery to the assessor -- such as one that consults a
white list -- is the value of the "d=" tag. However, this does not
prohibit message filtering engines from using the "i=" tag, or any
other information in the message's header, for filtering decisions.
</t>
<t>For signers and verifiers that have been using the i= tag as the
primary value that is delivered to the assessor, a software change to
using the d= tag is intended.
</t>
<t>So, this Update clarifies the formal interface to DKIM, after
signature verification has been performed. It distinguishes DKIM's
internal signing and
verification activity, from its standardized delivery of data to that
interface.</t>
<t>The focus of the Update is on the portion of DKIM that is much like
an API definition. If DKIM is implemented as a software library for
use by others, it needs to define what outputs are provided, that is,
what data that an application developer who uses the library can
expect
to obtain as a result of invoking DKIM on a message.</t>
<t>This Update draft defines the output of that library to include the
yes/no result of the verification and the "d=" value. In other
words,
it says what (one) identifier was formally specified for use by the
signer and whether the use of that identifier has been validated. For
a particular library, other information can be provided at the
discretion of the library developer, since developers of assessors --
these are the consumers of the DKIM library -- well might want more
information than the standardized two pieces of information. However
that standardized set is the minimum that is required to be provided
to a consuming module, in order to be able to claim that the library
is DKIM compliant.</t>
<t>This does not state what the implicit value of "i=" is, relative to
"d=". In this context, that fact is irrelevant.</t>
<t>Another example is the difference between the socket interface to
TCP
versus the TCP protocol itself. There is the activity within the
protocol
stack, and then there is the activity within in the software
libraries
that are actually used.</t>
Comments? (And yes, quick +1s are eagerly sought.)
d/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html