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
s/a non-reputation/some unspecified/
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
s/,//
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>
s/used/made visible to consumers/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html