Stephen, Pasi, and I have been considering the status and direction of the DKIM working group, and we think some clarification and procedural steering is important right now. Here are some thoughts of the chairs, Stephen and me, on where we are and what we need to do next.
Recent discussion has brought up the point that, while we had consensus in 4871 about i=, people do not have the same understanding about exactly what the text means. That's a valid problem that needs to be worked on immediately, and that should go into errata. But here's the thing: the *only* thing that belongs in errata in this regard is a clarification of what the *current* 4871 text means -- that is, what the consensus really was when 4871 was approved. It may also be that the working group has decided, or will decide, that i= in 4871 is *wrong* and should be changed. If so, that's fine. But that is *not* errata. We need to separate these two points, that which is errata and that which goes beyond that. ADSP makes use of i=, as specified in 4871. There see to be two thoughts going around related to this that I think are wrong from a procedural point of view (my own phrasing, here): Thought 1: 4871 does not put special meaning onto i=, and ADSP does. If 4871 is clarified to say that i= is an "opaque" string, or some other wording for those who don't like "opaque", then ADSP, as written, is in violation of 4871. This is wrong because ADSP is an extension of 4871 (maybe it should be labelled as "updates 4871", actually), and it's perfectly acceptable for it to layer new semantics onto what's there, as long as everyone can tell which semantics are in effect. In this case, it's simple: absent advertised ADSP support by the signer, the verifier has to take i= without specific meaning; *with* advertised ADSP support, i= can be taken to relate to the "from" address. There's no conflict here. Thought 2: If we're going to change the meaning of i=, that *will* cause problems with ADSP, as written, and so ADSP should wait until we've decided what to do with i=. This is wrong because all variants of what's being proposed for i= can be done with a new tag. In fact, it can be done in an extension, without having to update 4871 at all. Given that, ADSP is not in conflict with the new functions that are being discussed. So here's what Stephen and I think we need to do: 1. We need to close on the errata by making updates and clarifications that are limited to what's needed to fix the errata. Any re-thinking about what i= *should* be is out of scope for *this* effort. 2. Proceed with ADSP as written, which has rough consensus. 3. Consider any re-thinking of i= as part of a 4871bis effort. As we do that, consider moving significant changes to the concept (such as Suresh's "good@", "bad@" idea, and other suggestions) to extensions, as a possible alternative to putting them into 4871bis. 4. Aim 4871bis at incorporating what we've learned since 4871. If that results in a document that can and should move to Draft Standard, we'll do that. If it does not, then 4871bis will go to Proposed Standard, and it will take another round of work to move up the standards track. >From a procedural point of view, that is the direction the chairs think we >need to take. Therefore, the first thing we have to do, right now, is take care of the errata, with clarification, but not change, on the i= issue. Barry -- Barry Leiba, DKIM working group chair ([email protected]) http://internetmessagingtechnology.org/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
