Re: [art] New RFCs text formatting

[Julian Reschke <[e-mail]>]

On 29.11.2019 03:22, John C Klensin wrote:
> ...
> 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.
> ...

John, with all due respect, there's a reason I asked, so for me this
question definitively is not the "wrong" question.

When we had these discussions many years ago, the assumption was that
tools that operate on plain text RFCs would strip pagination first (or
ignore it altogether) before doing what they need to do next. I would
like to understand whether this assumption was wrong, and how *exactly*
tools now break.

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

Heather has sent out mails, published FAQs, explained things at the
plenary, and had a poster at the RFC desk for a long time. I would say
this was hard to miss.

Best regards, Julian

PS: I have many other issues with the V3 switch, mainly that we are now
publishing "canonical" versions in a undocumented and un-reviewed
format. In comparison to that, the changes in the produced text format
currently seem to be a minor issue.