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

[John C Klensin <[e-mail]>]

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

> 
> On Sat, 2011-09-10, Bjoern Hoehrmann wrote:
>> * John C Klensin 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.

> 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.

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
>...
> 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.

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

    john