Pasi, Stephen, and I had a conference call to sort out where we can go with the
errata, the idea of a 4871-bis, and so on. This summarizes what we think,
where
we'd like the working group to go, and what the working group needs to decide.
The first point is that while 2/3 of the working group prefer the stronger and
more extensive clarifications in the "Dave draft" (realizing that he's the
editor, and that others were involved in drafting this; it's a convenient way
to
refer to it) to the more minimal, more "errata-type" update of the "modified
Eliot draft", Pasi thinks the discussion shows neither text is probably
appropriate as an RFC Editor errata (that skips the usual IETF consensus
process). Dave's changes, in particular, introduce new terminology and make
enough changes in how the affected areas of the spec are worded that Pasi
believes -- and thinks the IESG as a whole will agree -- that it needs to go
through the full process of getting community input and rough IETF consensus.
He is sure, though, that the IESG will be happy to handle this expeditiously,
and
so we recommend that Dave's draft be processed as an RFC that updates RFC 4871.
This will mean that we have come to agreement on the text, but there are less
constraints about the length, and the outcome can include text that some folks
would interpret as changes to RFC 4871. Since Dave's draft has a clear
majority
behind it, we'd like those who disagree with some parts of it to help with
making
it more acceptable to everyone -- or most of us, anyway -- so we can get it out
as a 4871 update.
Next is the question of how to put it out and what to do with the other errata,
which are non-controversial. We could handle them as normal errata, put Dave's
draft out as an update that resolves that item, and then start work on whatever
4871-bis would be. We're concerned, though, with the lack of visibility of
errata, and we note that some of these errata are important for people to see
when they're implementing 4871. That might make it worth taking one of these
two
paths (and this is what we'd like the working group to decide):
1. Include the other errata into Dave's draft, leave the whole thing as "old
text
/ new text" format, and put it out as an RFC that updates 4871. There would be
no rev of 4871, and implementors would need to use both documents. Work on
4871-bis from there.
2. Include the other errata and Dave's draft into a 4871-bis, which would
obsolete 4871 and make sure that implementors get the right version. Nothing
would go out as "old / new"; the merged document would be a rev of 4871. Work
on
4871-ter from there.
Then there's the question of where ADSP stands, and whether it can proceed as
is,
or needs to be changed in light of the "errata". Pasi may have some comments
on
this, and I know the working group will. We've been holding ADSP up for a
while,
and we need to release it and move it forward.
We would like to get the decisions of how to proceed sorted out before the San
Francisco meeting, and to use the meeting time in San Francisco to
<strike>shout
at each other</strike> come to the agreements and compromises that we need to
get
this done. We'd like to be able to confirm these decisions on the mailing list
and move ahead shortly after the San Francisco meeting.
Responses to this message should stay in this thread, until we decide to split
sub-threads off.
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