I frankly don't see the point of a -bis document, and so long as the errata
shows up reasonably close to the top in a google search, I think that the
dev front should be fine. Invoking another round of IETF process at this
point sends exactly the wrong message: that DKIM is not stable. DKIM
has been remarkable in its stability and interoperability, so sending that
message would be a real shame.
Mike, dev-by-google-consensus is the new "rough consensus
and running code"
DKIM Chair wrote:
> 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 ([email protected])
> http://internetmessagingtechnology.org/
>
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
