Responding to Dave's, Doug's, and John's replies (I'll get to Jon's later)...
Dave says...
Recent discussion has brought up the point that, while we had consensus in
4871 about i=,
Recent discussion also brought up the point that this assertion was factually
incorrect and that there is no documentation to substantiate it. Yet it
appears to be the foundation of your analysis.
It's not factually incorrect, but I think you misunderstand it. The
documentation to substantiate it is that RFC 4871 went through working-group
last
call, IETF last call, and IESG processing with the text that's there. What we
see now, though, is that not everyone had/has the same understanding of what
that
text meant.
Anyway, Dave, I think we're just talking about semantics, here; see below.
Dave says...
We need to separate these two points, that which is errata and that
which goes beyond that.
...
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.
What, specifically, do you believe "goes beyond that" in the Errata
draft? And what's your basis for believing that?
What specific changes are you suggesting?
I'm not suggesting that there's anything wrong with the errata draft.
I'm addressing the extended discussion of i=, and what it could be and what it
might be, and I'm saying that the chairs are setting a boundary here: any
change
to how i= is used is beyond the scope of errata (and into the scope of Jon's
comment).
I never said that the errata draft crosses that boundary; I think it does not.
Dave says...
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=.
...
2. Proceed with ADSP as written, which has rough consensus.
You left out a key, alternative consideration, for ADSP, that it should
be changed to use d=, rather than i=. With a clarification of the roles of d=
and i=, as DKIM signature output, relying on i= by ADSP can reasonably be
subject to re-evaluation. Was your omission intentional?
Doug says...
Changing ADSP to use d= rather than i= restores single signature compatibility
with RFC 4871. :^)
My omission was not intentional.
Yes, I think that given the recent discussion, it's quite fair to see if the
working group wants to re-open that issue in ADSP before we go forward with it.
John says...
Dave's draft clarifies the meaning and use of i=. It's time for a last
call on it.
Stephen was planning to do that on Monday. I wanted to get the "status and
direction" message out first.
I think we're all actually in agreement here.
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