(sorry...I clicked the HTML button on the last try and my own PDA was having problems with it)
Dave CROCKER wrote: > > > Jim Fenton wrote: >> Can you clarify what IESG concern this is attempting to address? > > > Frankly, for that level of question, I suggest you direct it to our > area director. That will be far more efficient than my attempting to > channel him and the rest of the IESG. > OK. Pasi: Dave has proposed a change to the rfc4871-errata draft in response to a concern from the IESG. Can you clarify what concern the IESG has this is attempting to address? I'll repeat my original question below since you may have missed it. -Jim Jim Fenton wrote: > 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
