Re: [art] New RFCs text formatting

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

--On Thursday, 28 November, 2019 20:05 +0100 Julian Reschke
<[e-mail]> wrote:

> On 28.11.2019 17:33, John C Klensin wrote:
>> ...
>> [1] The concern is about user-developed tools, used by one
>> person or a cluster of people who have shared them, not ones
>> developed or maintained under IETF auspices.
> 
> Do you have a concrete case of a tool that fails with the new
> format?

Julian, I think that is precisely the wrong question to be
asking.  My note indicated that the concern was about private
tools, not ones that the IETF community has necessarily ever
been told about. I'll answer the question anyway, which is that
I have such tools, mostly written for an emacs clone as either
macros or in its proprietary extension language.  Some of them
predate even the first instance of XML2RFC.  A subset of those
include some that have not been used recently but that were used
to write drafts for RFCs either direct-to-text or using private
macros for nroff or similar format markup systems that were then
converted to text using those systems before submission. Others
have been in active use more recently.  One got into trouble
with RFC RFC 8689 because, for some reason, it tried to do a
search on "[Page" or some regex equivalent.  I don't know how
important that search is or how hard it would be to replace (I
haven't looked at the internals of most of those in 20-odd
years) but the point is that this is a more disruptive change
than some of would have predicted.

My response to Paul's comment is similar, again with the
observation that it may be much too late to do anything other
than maybe learn a lesson: it really does not make any
difference whether I can find a specific promise or not.  I
believe the community of people who work with RFCs (not just the
subset who have been designing and implementing v3 or the
overlapping subset who design and implement too for the
community) were led to believe this was going to be a
non-disruptive change.  We were told that we could keep working
in v2 (with whatever v2-prep tools we had) and submitting that
way and the Production Center would sort things out, and, while
v3 would bring many advantage to the Production Center, those
who wanted to use it, and people who preferred reading RFCs in
more "modern" formats, no one needed to make changes in how they
were doing things.  In addition to the positive things that have
been said about v3, to the best of my knowledge at least, the
community was never told "this is going to result in some
incompatible changes that you will need to deal with, are those
changes acceptable for the benefits they will bring".  In
itself, the absence of that question strongly implies only
changes that are non-disruptive except to those who choose to
use new features and to the Production Center.

Well, causing old tools, even non-public tools, to not work as
they did before and without changes to those tools is a
disruptive change.

>> [2] Reading RFC 7994 only after these changes were
>> identified, I find that Sections 4.1ff remove headers and
>> footers and the page numbers from the TOC.  But the
>> introductory paragraph of Section 4 does say
>> 
>> 	"One plain-text output will be created during the
>> 	publication process with basic pagination that includes
>> 	a form feed instruction every 58 lines at most,
>> 	including blank lines."
>> 
>> So perhaps that omission is a bug.
> 
> AFAIR, the intent was to *paginate*, nothing more (yes, no
> headers,
> footers, no page numbers).

That is certainly what 7994 says.   To me, the important
question is whether publication in that (and other) documents is
sufficient to warn the community about changes that may be
incompatible with tools or working procedures used by
contributors.  If the answer is "yes", then every one of us is
responsible for being thoroughly familiar with every RFC or
announcement that might affect IETF procedures, publications,
and other ways in which we do things so there is an opportunity
to raise timely objections.   I don't think we want to go there
but should instead assume that people in the community should be
warned by explicit questions and requests for consensus before
incompatible changes are made.  YMMD, of course,

   best,
    john