Getting back to the question that the Chairs asked us to answer:
DKIM Chair wrote:
Next is the question of how to put it out and what to do with the other
which are non-controversial. We could handle them as normal errata, put
draft out as an update that resolves that item, and then start work on
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
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
/ new text" format, and put it out as an RFC that updates 4871. There would
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.
4871-ter from there.
I'd like to see us go straight to a 4871bis (option 2). The extra
editorial effort involved in merging the versions seems well worth it,
to have a single normative document for DKIM signatures.
The question that I still have is whether this 4871bis document would be
limited to "erratum" sorts of changes. There has been a significant
amount of deployment experience since 4871 was published, and IMO it
would be beneficial to address that as well. No, I don't have anything
particular in mind; I'm just trying to understand the ground rules. Or
would the deployment experience be incorporated into 4871ter that you
I don't have any experience with the types of changes that would be
allowed in 4871 and still progress the next revision to Draft Standard.
I realize that is important to many, but I'm more interested in getting
the spec right than whether it's PS or DS.
NOTE WELL: This list operates according to