Pasi,
Pasi(_dot_)Eronen(_at_)nokia(_dot_)com wrote:
However, it seems we're not just fixing simple errors in the wording,
but adding new design that was... well, somewhat underspecified in
RFC 4871, or at the very least, not well understood at the time (or
understood in different ways by different folks).
That probably goes a bit beyond what should be changed using errata,
and I would suggest doing 4871bis instead. If there's rough consensus
about the content, I think it'd be possible to get it published as RFC
relatively quickly (say, well before the summer).
Pasi,
Please reconsider your suggestion.
This Errata effort developed out of real and immediate community need. Your
opening comment indicates an understanding that the problem does exist. In
other words, it does fix a specific, actual problem with the current
specification, and that's what Errata are for. If you know of documentation
that specifies a limit on the scope of an Errata (erratum?), please point to
it,
because I could not find one. We should not invent one on the fly.
Coupling the publication fate of this one, specific change with an a
substantially larger -- and potentially much larger -- set of additional
changes
ensures a delay of months, where 6 months is optimistic. Adding arbitrary
delay
to the publication of an approved Errata note is not helpful for community need.
The specific clarification being attempted by the current draft Errata is
needed
now, not months from now.
d/
ps. Independent of the formal IETF publication barriers that we encounter, the
working group can still resolve the current topic, by formulating working group
consensus, and then post it to the dkim.org web page. That's not the same as
formal IETF publication but can still declare it for community use.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html