Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966)

From: John C Klensin <[email-masked]>
Date: Sat, 10 Sep 2011 07:20:40 -0400

RFC Editor and relevant IESG members: 

<rant>As a general observation, given that we do not change RFCs
once published and, especially for IETF Stream RFCs, that there
are extensive opportunities to suggest small corrections during
pre-approval review (and even post-approval if a problem is
noticed after the approval notice but before actual
publication), I believe the errata process would be considerably
improved by imposing a non-trivial administrative fee for a
filing, especially a filing within a few weeks of RFC
publication.  That fee would appropriately be doubled if the
person making the filing were on the mailing list of a WG that
considered the document  and doubled again if the proposed
change were either incorrect or specious.

I believe that, if half of the fee went to the RFC Editor Staff
Annual Party Fund and the other half were split among relevant
ADs, WG Chairs, and authors, it would considerably improve the
errata review process as well as providing a small barrier to
use of the errata as either DoS attacks or general annoyances.
Having the fee would provide those who read documents looking
for errors significant encouragement to read the I-Ds and
identify issues while they can still be fixed rather than doing
post-publication nit-picking on RFCs.

If nothing else, it would be useful if categories like
"rejected" and "accepted" could be supplemented with "probably
technically correct, but a massive waste of time".
</rant>

Now, as to substance, it is first worth remembering that,
whatever the writing system is called, the name in Latin-derived
characters is a transcription for an Austronesian language that
has apparently been written with Indic/Brahmi-derived characters
as well as Arabic and Latin ones. Such transcriptions and
transliterations are rarely as precise as one might like,
especially when one of the scripts through which a term migrates
is written without explicit vowel notation.  While "Jawi" is,
indeed, usually preferred, we've been informed by Malaysian
sources that "Jawa" is often used interchangeably.   Probably
the text in RFC 6365 should have read "Jawi, sometimes referred
to as Jawa" or equivalent, a change that would have been
trivially made had the issue been identified prior to
publication (see above).

Neither the Unicode script categories nor ISO 15924 are of use
here because they consider Jawi to be simply Arabic Script.
Whether it is or is not is a matter of judgment but then so is
the question of whether the Arabic script as used to write the
Arabic language and the various forms known as Perso-Arabic are
really the same script or are, like e.g., Greek and Cyrillic,
actually a single script with some variant and additional
letter-glyphs and phonemes.  The use of the term
"Arabic-script-based" in the text was intended to point that
out, so "...script (actually a variant of the arabic one)" in
the errata does not add any information.

regards,
   john

--On Saturday, September 10, 2011 01:34 -0700 RFC Errata System
<[email-masked]> wrote:

> 
> The following errata report has been submitted for RFC6365,
> "Terminology Used in Internationalization in the IETF".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6365&eid=2966
> 
> --------------------------------------
> Type: Editorial
> Reported by: St?phane Bortzmeyer <[email-masked]>
> 
> Section: 2
> 
> Original Text
> -------------
> Malay is primarily written in
> 
>       Latin script today, but the earlier,
> Arabic-script-based, Jawa
> 
>       form is still in use
> 
> Corrected Text
> --------------
> Malay is primarily written in
> 
>       Latin script today, but the earlier,
> Arabic-script-based, Jawi
> 
>       form is still in use
> 
> Notes
> -----
> I don't know this script myself but it seems that, in english,
> it is always called Jawi (Jawa is the old name for the island
> it came from, so Jawi = script from Jawa).
> 
> 
> 
> This script (actually a variant of the arabic one) does not
> seem to be in ISO 15924 so I cannot offer an authoritative
> reference.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,
> please use "Reply All" to discuss whether it should be
> verified or rejected. When a decision is reached, the
> verifying party (IESG) can log in to change the status and
> edit the report, if necessary. 
> 
> --------------------------------------
> RFC6365 (draft-ietf-appsawg-rfc3536bis-06)
> --------------------------------------
> Title               : Terminology Used in Internationalization
> in the IETF Publication Date    : September 2011
> Author(s)           : P. Hoffman, J. Klensin
> Category            : BEST CURRENT PRACTICE
> Source              : Applications Area Working Group
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG

---

From: RFC Errata System <[email-masked]>
Date: Sat, 10 Sep 2011 01:34:46 -0700 (PDT)

--------------------------------------
Type: Editorial
Reported by: Stéphane Bortzmeyer <[email-masked]>

Section: 2

Original Text
-------------
Malay is primarily written in
      Latin script today, but the earlier, Arabic-script-based, Jawa
      form is still in use

Corrected Text
--------------
Malay is primarily written in
      Latin script today, but the earlier, Arabic-script-based, Jawi
      form is still in use

Notes
-----
I don't know this script myself but it seems that, in english, it is always called Jawi (Jawa is the old name for the island it came from, so Jawi = script from Jawa).

This script (actually a variant of the arabic one) does not seem to be in ISO 15924 so I cannot offer an authoritative reference.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6365 (draft-ietf-appsawg-rfc3536bis-06)
--------------------------------------
Title               : Terminology Used in Internationalization in the IETF
Publication Date    : September 2011
Author(s)           : P. Hoffman, J. Klensin
Category            : BEST CURRENT PRACTICE
Source              : Applications Area Working Group
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Sep 2011 18:58:51 -0400

--On Saturday, September 10, 2011 20:05 +0100 Stéphane
Bortzmeyer <[email-masked]> wrote:

>...
> I would say otherwise: such an errata is of small importance,
> in the grand scheme of things, but, should a 6365bis appear
> one day, it is a good idea if such problems are stored
> somewhere for the future revision. What is wrong with using
> the errata database as a bug-tracking system? And what is the
> actual cost of storing one bug in this database?

Stéphane,

First, my apologies for overreacting somewhat.  Bad week.

Beyond that, there are two answers to your question.  The first
is that, while it is probably inevitable that something will
slip through every once in a while, the amount of nit-picking
that goes on with a document like this while it is passing
through the approval stages makes it extremely frustrating that
something of more significance than many of the things that were
caught slips through nonetheless. The second is that,
unfortunately from my point of view, the errata system has
evolved rather quickly from just what you describe -- at least
in large measure a lightweight system for recording minor issues
that it would be desirable to check if the document is ever
revised -- to a rather heavyweight one in which a half-dozen
people and a WG mailing list get involved and a multi-step
approval process is needed.

Perhaps if the system permitted someone who found a problem that
"is of small importance,  ... it is a good idea if such problems
are stored somewhere for the future revision" to say that when
the erratum is submitted --perhaps by checking a "recommend
moving this immediately to 'hold for future revision' box" and
_not_ copy all present and past ADs and a WG as well as the
authors, the RFC Editor could assign that category in the
absence of someone deciding to take it up for more serious
discussion.    That would certainly have been reasonable (and
appreciated, at least by me) for this report; the problem if
any, lies in the implicit request for a broader discussion and
relatively immediate action, if only to classify it that way in
the end.

best,
    john

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 11 Sep 2011 01:36:50 +0200

On 10 September 2011 13:20, John C Klensin wrote:

> <rant>
[...]
> there are extensive opportunities to suggest small
> corrections during pre-approval review

It happens for obvious reasons; folks look at a draft
or RFC again when it somehow triggers their attention.

That is how I ended up to report the earth-shattering
fact that the MD4-obsolete RFC has the MD2-obsolete
page headers (or vice versa) on the day of its
publication, when I updated the relevant MD2+MD4+MD5
en:Wikipedia articles.  IOW, I did not see this minor
nit before; and actually I don't care about MD2+MD4.

But it would be stupid to update only the MD5 article
when you know that there are similar RFCs for MD2+MD4.
<counter-rant> There are also authors, notably you,
who hate to discuss editorial nits outside of AUTH48.
</counter-rant>

Recently the same pattern had a similar effect, I saw
an oddity in a "no-spam-report" draft only *because*
it is now in PubReq.  I didn't see it at a better time
(= WG LC).  My interest in that WG is not related to
the perfectly harmless "no-spam report" draft, and you
cannot expect me to find minor nits at a better time:
Mostly I stumble over nits, and the timing can be bad.

> I believe the errata process would be considerably
> improved by imposing a non-trivial administrative fee
> for a filing, especially a filing within a few weeks
> of RFC publication.

Refundable for verified errata, the IETF trust has to
cough up the costs caused by publishing erroneous RFCs
in their stream.  "Held for document update" slowly
degrades into "I don't like to check what this really
is", therefore it should be handled as "verified" wrt
the errata fee.  To avoid the fee posting an I-D with
biannual renewals would suffice.  Insert "</joke>" at
the place where it belongs.

> </rant>

Many editorial errata are editorial nits, and this has
to be fixed years later in a xxxx-bis document.  It is
perfectly okay to document the fact in a public erratum.

It is also good for readers stumbling over the same
issue, when they find that this was already reported,
and ideally verified.  (Or rejected, if the alleged
editorial nit turns out to be intentional, and a "fix"
would be a mistake.)

Some editorial errata are disguised technical errata,
I click on "editorial" whenever possible, reserving
"technical" for "this is really wrong, and that it is
wrong is not obvious".

I very much appreciate the work of A. Hönes, the RFC
errata system is a very important part of the RFCs.
It is not at all a waste of my time.  Of course I can
see your point as author, but all it takes is an ACK
or a NAK.  You should be also able to "opt-out" from
the errata process if you don't like it.  After all
it's the responsibility of the IETF to care about its
published RFCs.

> While "Jawi" is, indeed, usually preferred, we've
> been informed by Malaysian sources that "Jawa" is
> often used interchangeably.

Okay, simply put that as reason in a NAK.  I couldn't
care less about "Jawi vs. Jawa", but I certainly care
about the RFC errata process.

-Frank

---

From: SM <[email-masked]>
Date: Sat, 10 Sep 2011 17:31:12 -0700

>or RFC again when it somehow triggers their attention.

http://www.bortzmeyer.org/3536.html

As for errata [1]:

  "The idea was to discourage readers from repeatedly pointing out the
   same typos in published RFCs.  This evolved into the errata verification
   and posting process"

  "Unfortunately, our understanding of the errata problem was wrong in
   several ways.  The number of errors reported turned out to be
   significantly greater than anticipated"

  "We note that allowing technical errata is a slippery slope: there may
   be a temptation to use errata to "fix" protocol design errors, rather
   than publishing new RFCs that update the erroneous documents."

Regards,
-sm

1. draft-rfc-editor-errata-process-02

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 11 Sep 2011 03:17:07 +0200

>relatively immediate action, if only to classify it that way in

Could you explain where you got this impression from? The E-Mail that
started this thread says "Editorial Errata Reported" in the Subject,
and editorial issues typically do not require broad discussion or ur-
gent action, and there does not seem much else to suggest it does. So
I would think this field already exists. As for copying people, well,
I would think most of the people in question are used to dealing with
high volume email traffic with mails varying greatly in importance. I
am not saying the user interface for this can't be improved, but I do
not see the problem you have with it.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bill McQuillan <[email-masked]>
Date: Sat, 10 Sep 2011 22:05:00 -0700

> not see the problem you have with it.

I suspect that the people that are copied with these Errata
emails probably get a lot of them, so I understand the
spam-spam-spam sort of frustrated reaction.

I think that John's suggestion would be a good one: to have some
place to store problems with an RFC for future consideration. For
example, I just found a place in RFC 5322 (Internet Message
Format) in which the ABNF is clear and correct, but the
explanatory text could be read to contradict the ABNF. I know
that I have read this area of 5322 before, but not with this
particular syntax in mind so it is the first that I have noticed
it. The paragraph in question was copied from RFC 2822. Obviously
not an earth-shattering problem!

I thought that I should use the RFC Errata page to report this. I
first checked the existing Errata to see if it had already been
reported and it hadn't. No such errata was reported for RFC 2822
either.

While I was reviewing the Rejected errata, several of the
rejection comments referred to the fact that submitting errata
was NOT the way to raise some issues. I drilled down to see what
the guidelines were and I *think* that it would not be right to
submit *my* suggestion for rewording as an RFC Erratum. The
instructions said I should, rather, submit it to the appropriate
WG, however, I don't know which that should be! Maybe YAM, but it
seems to be disbanding.

I really shouldn't have to remember this issue until an
opportunity arises to mention it. There should be a cheap
mechanism for me to leave a note, associated with RFC 5322 that
will be easily picked up when a revision is contemplated.

-- 
Bill McQuillan <[email-masked]>

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 11 Sep 2011 08:12:43 +0200

On 11 September 2011 02:31, SM quoted:

> "Unfortunately, our understanding of the errata problem was wrong
>  in several ways.  The number of errors reported turned out to be

IMHO the process works much better now.

> draft-rfc-editor-errata-process-02

The [IESG-Err-Proc] reference in this draft matches the page at
<http://www.ietf.org/iesg/statement/errata-processing.html>, and
in this statement "Hold for Document Update" is almost literally
the same as "archived" in the rfc-editor-errata-process draft.

If that is unrelated to what you wanted to say I need a new clue;
especially, why did you mention Stéphane's RFC 3536 blog entry?

-Frank

---

From: SM <[email-masked]>
Date: Sun, 11 Sep 2011 03:36:02 -0700

Hi Frank,
>If that is unrelated to what you wanted to say I need a new clue;

There was a time when the author's email address 
was published in a RFC.  You could send comments 
to that address.  As an author, it can be tedious 
having the same errors pointed out 
repeatedly.  It is easier for authors if such 
comments are collected and is publicly 
accessible.  And the errata system took a life of its own.

What I wanted to say was read about the initial 
idea, see how it turned out and draw your own conclusion.

>especially, why did you mention Stéphane's RFC 3536 blog entry?

That's a guess about what may have prompted 
Stephane to read the RFC and send in a 
comment.  As a side note, it is an interesting piece of work.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Sep 2011 08:48:06 -0400

--On Saturday, September 10, 2011 22:05 -0700 Bill McQuillan
<[email-masked]> wrote:

>>> Perhaps if the system permitted someone who found a problem
>>> that "is of small importance,  ... it is a good idea if such
>>> problems are stored somewhere for the future revision" to
>>> say that when the erratum is submitted --perhaps by checking
>...

>> Could you explain where you got this impression from? The
>> E-Mail that started this thread says "Editorial Errata
>> Reported" in the Subject, and editorial issues typically do
>> not require broad discussion or ur- gent action, and there
>> does not seem much else to suggest it does. So I would think
>> this field already exists. As for copying people, well, I
>> would think most of the people in question are used to
>> dealing with high volume email traffic with mails varying
>> greatly in importance. I am not saying the user interface for
>> this can't be improved, but I do not see the problem you have
>> with it.

Perhaps, Bjoern, because you are not the listed author of a lot
of RFCs and hence don't see many of these, especially for
documents for which there is no near-term prospect of revision.
In practice today, the RFC Editor and their tools feel some
obligation to take these as serious errors and change requests
until proven otherwise and to track down their status.  There is
no practical way for the submitter to say "minimal distribution;
just keep this in the system so it doesn't get lost" and for
authors to say "yes, now, for the present, let's move on".

A _long_ time ago, an author could have responded to a
correction like this by saying "yes, useful clarification", sent
a revised draft off to the RFC Editor, and had it published as
an update.  Today, given that this is a BCP, even starting to
think about an update would require a conversation with ADs and
WG Chairs about whether the WG should take it on and possibly a
discussion on the WG list and consensus call about whether to
reopen the document (not about the suggested changes).  If
things got that far, we would then all have the "opportunity",
not just to review this particular change but to go back through
the process of asking what definitions are there, what
additional definitions people think should be added, and whether
other definitions and comments need to be fine-tuned.  That is
one of the reasons documents don't get revised unless there is a
compelling need to do so.   It is probably as it should be -- on
balance, I think we are better off with a more careful approval
and consensus process than we were three decades ago.  But, it
means that, as Bill points out, some easy way to simply build a
file of comments for later consideration --if and when the
document is reopened-- would be a good idea.

> spam-spam-spam sort of frustrated reaction.

yes.   We are, fortunately, nowhere near that point yet (at
least I'm not), but it isn't hard to imagine a situation in
which a would-be RFC author has to weigh the importance of the
work against the potential for more email noise -- noise that
cannot be discarded or ignored without reading and responding.

> I think that John's suggestion would be a good one: to have
> some place to store problems with an RFC for future
> consideration. For example, I just found a place in RFC 5322
> (Internet Message Format) in which the ABNF is clear and
>...

Right.  And that flags the fact that there are some textual
issues in 5322 that should be examined sometime.

    john

---

From: Stéphane Bortzmeyer <[email-masked]>
Date: Mon, 19 Sep 2011 09:04:57 +0200

On Sat, Sep 10, 2011 at 06:58:51PM -0400,
 John C Klensin <[email-masked]> wrote 
 a message of 54 lines which said:

> Perhaps if the system permitted someone who found a problem that "is
> of small importance, ... it is a good idea if such problems are
> stored somewhere for the future revision" to say that when the
> erratum is submitted --perhaps by checking a "recommend moving this
> immediately to 'hold for future revision' box"

Indeed. Most bug tracking systems have such a checkbox, allowing to
file the bug as Trivial, Minor, Major or Showstopper, and then sending
the email warning only if severity >= Major. That would be a nice
improvment to the RFC errata reporting system.

(And I disagree with Bjoern Hoehrmann: an "editorial error" CAN be
severe.)