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.
This isn't much clearer, but it does suggest a possible test: if these
changes had been proposed when the document was about to be approved,
would they have been accepted?
If someone had suggested the changes in rfc4871-errata-00 during
AUTH48, would they have been accepted? Or would the person proposing
them have been told "no, you're too late, maybe we can consider these
when we do 4871bis"?
[> ]
I wasn't around then either, and it's a bit difficult to take that mind-set
literally given that it's the experience and discussion that has happened
since then that made clear the confusion that the proposed Errata is trying
to address.
Perhaps better to ask whether, if they had the information then that we have
now, would the changes have been approved.
I'd suggest that the answer to the latter question would be yes, since
releasing a spec that engenders this much confusion/debate among the
technical experts working on closely related specifications will almost
certainly cause much greater confusion in the broader community.
If the rules put this in a grey area, even if we're pushing the boundary
slightly, I think it might be more constructive to allow this to go out as
Errata with an agreement that we'll follow up with the 4871bis that
incorporates other Errata and possibly additional clarifications.
Ellen
------------------------------------------------------
Ellen Siegel
Director of Technology and Standards
Constant Contact
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html