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 (barryleiba(_at_)computer(_dot_)org)
http://internetmessagingtechnology.org/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html