Re: Errata and Edited Recommendation [ISSUE-45]

Hello Charles,

Wednesday, October 9, 2013, 11:10:27 PM, you wrote:

> Hi Chris,

> On Wed, 09 Oct 2013 21:11:59 +0200, Chris Lilley <> wrote:

> [moved from the end to the beginning]
>> I would rather see the latest edited Recommendation roll in all the
>> stable, tested errata and have a non-empty errata list, rather than
>> the latest Edited Recommendation be years old and only make sense to
>> those people who can carry around large diff documents in their head
>> pertaining to all the stuff you need to "just know" about.

> I agree with your goal here.

OK, good.

> [and the rest including my response]
>> This comment relates to publishing an edited recommendation
>> I am concerned that the current text might be interpreted in a way
>> that leads to significant delay in the publication of Edited
>> Recommendations.
>> Consider the following situation: a WG has dealt with 100 errata
>> items, which all have tests and an implementation report that shows
>> implementors are on board with the changes. They plan to publish an
>> Edited Rec on Tuesday. On Monday a new errata item is opened. Lets
>> assume it is non trivial and generates substantial discussion about
>> whether it is actually an error and if so, the best way to fix it.

> I am very reluctant to make the change.

> As you note, the Process says groups *should* include all known errata.

I understand that you don't want to conflict with the Process
Document. On the other hand this is an update to one section of it,

> If a Working Group doesn't understand RFC 2119 well enough to offer the
> argument "it is useful to produce a better version soon, rather than wait
> forever to produce a possibly perfect version", I don't think the process
> document is the problem holding them back.

Fair enough. On the other hand, I don't think that text which says
"should do A" and means "will usually not do A because of reasons" is
as helpful as it might be.

Second proposal: keep the "should address all errata" bullet item and
add explanatory wording afterwards, such as

  <p class="helpWith2119Should">One reason to publish an Edited
  Recommendation, but not publish all errata, would be the existence
  of well tested and implemented errata (which should be published)
  along with more recent, untested errata or errata which are still
  under discussion. In such a case, the new edition would be
  published with a non-empty errata list.</p>

> Have there been real problems with this in the past, that suggest the
> problem will recur?

Yes, the slowness to publish a second edition of CSS 2.1 springs to
mind, caused by a slow but constant trickle of new errata while there
is a substantial set of well known, implemented in practice, tested
errata which could and should have been published. But the queue was
never (fully) empty.

Best regards,

Received on Wednesday, 9 October 2013 23:35:59 UTC