ietf-dkim
[Top] [All Lists]

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

2009-06-16 11:38:01

First thanks to the WG for trying to address the problem I had raised.  
I had assumed nothing would be done to try and correct so I just put  
abstain as clearly some people felt the document was worth publishing  
but as we are trying to fix or clarify this, let me be more explicit.

My focus is mostly on what this errata means to implementations in the  
field. That would be implementations of both DKIM the narrow signing  
protocol and implementations that use the information DKIM provides. I  
think the document should be clear on

1) what is the interoperability problem. Can someone succinctly  
summarize this? When I read the document, I get that there is a  
problem but it less clear what it is or why some implementation would  
end up doing something that did not work with other implementations.

2) what needs to be changed in implementations to fix this? Again, can  
anyone succinctly summarize this. I do not think an implementor that  
did not follow the list could easily read the current draft and figure  
out if there code was OK or not and what changes where needed to their  
code to make it OK

More inline ....


On Jun 15, 2009, at 19:22 , 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:




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>


I'm not really sure what you mean by a reputation intent and non- 
repuation intent or when a signer or verifier would want one or the  
other.



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

Look, this is clear as mud - What I am getting is that the old  
document was unclear if you should use the d= or the i= and this  
document clarifies it to be you should use, uh, I'm totally lost here,  
I use the d= for white lists, which are a form a filtering, but I can  
also use the i= for filtering.

I'm just unclear on what one is supposed to use and when. And honestly  
it does not matter if I am confused in the slightest, but it does  
matter if people implementing this stuff are unclear on this.  
Evidently there is enough confusing about this that it is worth  
writing an RFC to fix it - that I believe. However, people outside the  
WG other than me seem like they too have a hard time reading this and  
figuring out how this clarifies what to do. This does seem like a bit  
of a problem.



       <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

<Prev in Thread] Current Thread [Next in Thread>