+1 > -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy > Sent: Tuesday, June 16, 2009 5:53 PM > To: Cullen Jennings; dcroc...@bbiw.net > Cc: pasi.ero...@nokia.com; ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Modified Introduction text forrfc4871-errata > (resend) > > > > <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. > > Think about it in terms of an API specification. > > The intent here, I believe, is to specify that "d=" is mandatory output of > a DKIM verifier module. "i=" (and everything else, frankly) is optional. > Thus, a compliant verifier implementation will give you a yes/no on the > signature and the name of the domain in "d=". There may be other stuff > there, but that's what you need for minimal compliance and > interoperability. A consumer of such a minimal specification could > conceivably interchange DKIM implementations and still keep working as > before. However, there are no guarantees if such a consumer decides to > try to make use of optional stuff like "i=" or "x=" or "l=" or whatever, > because some other DKIM verifier implementation might not give that to > you. But if you code for yes/no and "d=" only, then any compliant > verifier will give you what you need to interoperate. > > If you as a consumer of such an API feel that you'd rather use "i=" for > particular applications or types of messages, then either create or use an > implementation that makes that value available. There's nothing wrong > with that either. > > (If any of that language resolves the concern, feel free to use it.) > > -MSK > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
