[ietf-dkim] Modified Introduction text forrfc4871-errata (resend)

[Murray S. Kucherawy]

> 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/