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.
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
refer to?
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.
While I'm not at all opposed to doing a -bis document, I think that a number of
people are vastly underestimating the time required to take one to completion.
My preference would be to declare consensus for the Errata document, and then
work the contents from that document and any other relevant errata into a more
polished -bis document. (I haven't been around for a whole lot of ietf votes,
but 2/3 sure sounds about as close as a working group is likely to get towards
consensus on issues like these.)
That approach gets the gist of the Errata clarifications out in a much more
timely manner (i.e., almost immediately), and does not preclude the generation
of the -bis document as rapidly as the process allows.
Ellen
------------------
Ellen Siegel
Constant Contact
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html