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

[Bill.Oxley at cox.com]

If the intent is to get everyone to use d= for an identifier to reduce confusion between d= and i= perhaps
 "More specifically, it clarifies that the default identifier
 is the value of the "d=" tag.
Other tags such as the i= may still be used and assessed"

-----Original Message-----
From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Michael Thomas
Sent: Tuesday, June 16, 2009 12:34 AM
To: dcrocker at bbiw.net
Cc: Pasi.Eronen at nokia.com; ietf-dkim at mipassoc.org
Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

Will somebody please tell the editor that this still violates our charter
since reputation is out of scope?

Thank you.

Mike


Dave CROCKER wrote:
> Jim Fenton wrote:
>> I do have a problem with the last paragraph:
>>
>>>        <t>For signers and assessors that have been using the i= tag for
>>>          reputation assessment a software change to using the d= tag is intended.
>>>        </t>
>>>
>> and some of the text in the preceding paragraph because it attempts to
>> do exactly what the WG charter says we won't, specifically:
>
>
> Ahh, right.  That's the sort of land-mine I was afraid might need uncovering.
> Thanks for catching this.
>
> So...
>
> Previous Proposed Text:
>
>         <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 reputation, and have a non-reputation intent in setting the
>           value in the other. However the assessor might choose the wrong value
>           and produce an unintended (and inaccurate) reputation 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 reputation lookups (such as white lists) by the
>           assessor 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 header, for filtering decisions. </t>
>
>         <t>For signers and assessors that have been using the i= tag for
>           reputation assessment a software change to using the d= tag is
>           intended.
>         </t>
>
>
> New Proposed Text:
>
>         <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 reputation, 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) reputation 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>
>
>

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html