Re: [ietf-dkim] Output considered harmful
Mike Thomas says... 4871 had it right on this account. Everything since then has screwed the pooch. Put it back. Mike, I have a lot of catching up to do, having been travelling for a bit. Some of that catching up involves dealing with complaints (plural) about what you say on this list. While I'm catching up and figuring out how to handle all this, there's one thing I can directly say up front: Stop talking like this on the list. Be professional and polite. Avoid rancor. Don't say things that people are likely to take as implying that they're stupid, or have done stupid things. That stuff, along with phrases like screwed the pooch, doesn't make your point more effectively or forcefully; rather the opposite: it makes people tend to ignore your underlying point because of the resentment you're creating. And it prompts them to complain to me. Be civil, even if you're angry. And if someone else irks you, don't escalate it; stay civil then, too. And this all goes for everyone, of course, though here I'm specifically saying it to Mike. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Output considered harmful
On 05/04/2011 05:04 AM, John R. Levine wrote: For a scenario where a caller is calling a DKIM milter which in turn calls an API, this is all true. But DKIM will be/is deployed in many more scenarios. Indeed, but you're misunderstanding the point of a standard. The DKIM spec tells signers how to create a signature that recipients can verify, and it tells verifiers how to check whether a signature is valid. The spec is not an implementation guide for every possible implementation scenario. Indeed, this is precisely why it's silly to say there is a single output of the protocol. Take IKE and KINK, for example: the output is a complex set of parameters that eventually lead to the keying of a SA given the identity in the cert/ticket. They are *all* relevant and not just internals. Similarly, DKIM signatures have a lot of relevant information for filters to do the magic that filters do, and they by their nature find utility in information that is being walled off by -bis as being internal. And please stop trying to have it both ways: it's either internal or it isn't. Developers have a funny way of taking these documents literally and when you say it's internal, they make them internal in fact. We need to pick a lane, and single output clearly does not match the real needs of all DKIM consumers. 4871 had it right on this account. Everything since then has screwed the pooch. Put it back. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
