Can you clarify what IESG concern this is attempting to address? I looked at the IESG evaluation record for the draft (https://datatracker.ietf.org/idtracker/ballot/3084/) and didn't see anything that this change would address, except possibly Cullen's comment that he asked three developers what changes to a 4871 implementation might be required and they told him "this document was completely incomprehensible and they have no idea what needs to change."
I don't see this modification as addressing that comment. -Jim Dave CROCKER wrote: > Folks, > > In reviewing the errata (Update) draft, the IESG expressed concern that a > reader > could miss that there is a potential for software changes due to the change > in > the specification. Indeed, some IESG readers and others did believe there > was > no software change needed. > > To clarify things, without producing text that makes integration into the > base > document a challenge later, a modification to the Introduction is proposed. > I'm > circulating it to the mailing list to be sure that there are no land mines in > its interpretations. > > If the proposed changes causes you particular heartburn, please explain your > concern in detail. > > Thanks. > > d/ > > > Existing Introduction text: > > >> This currently leaves signers and assessors with the potential for >> having differing -- and therefore non-interoperable -- >> interpretations of how DKIM operates. >> >> This update resolves this confusion. It defines new labels for the >> two values, clarifies their nature, and specifies their relationship. >> >> > > > 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> > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
