Subject: [art] New RFCs text formatting

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 28 Nov 2019 00:31:29 +0100

Hello.

This is surely the wrong list, but neither am i at ietf@ nor do
i want to stress the admin for this.

But i just have downloaded RFC 8689 and the text is a top-down
conversion, likely from XML (terrible).  Meaning, no ^L'ss aka
\f's to separate pages, no page numbers, no page titles and
footers etc.  Is that normal now, or was that a mistake?  RFC 8617
still was of the expected formatting.
Shall this reported somewhere specific?

(It came down via FROM=https://www.rfc-editor.org/rfc/ by
: ${WGET:=`command -v curl` --silent}.)

Ciao,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 28 Nov 2019 00:32:47 +0100

Steffen Nurpmeso wrote in <[email-masked]>:
  ..
 |footers etc.  Is that normal now, or was that a mistake?  RFC 8617
 |still was of the expected formatting.

RFC 8621 indeed.

--steffen
|

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 28 Nov 2019 11:27:31 +1100

> Shall this reported somewhere specific?

This is the outcome of the process that produced RFC 799x and friends.

See https://tools.ietf.org/html/rfc7990#section-7.3

The lack of links in the text-to-HTML conversion of tools.ietf.org is probably worth reporting as a bug, but a low priority one considering that the HTML version should be available.  That said, datatracker.ietf.org only offers "HTMLIZED" and not HTML links.

---

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 28 Nov 2019 01:50:00 +0100

Martin Thomson wrote in <[email-masked]\
il.com>:
 |On Thu, Nov 28, 2019, at 10:31, Steffen Nurpmeso wrote:
 |> But i just have downloaded RFC 8689 and the text is a top-down
 |> conversion, likely from XML (terrible).  Meaning, no ^L'ss aka
 |> \f's to separate pages, no page numbers, no page titles and
 |> footers etc.  Is that normal now, or was that a mistake?  RFC 8617
 |> still was of the expected formatting.
 |> Shall this reported somewhere specific?
 |
 |This is the outcome of the process that produced RFC 799x and friends.
 |
 |See https://tools.ietf.org/html/rfc7990#section-7.3

Oh, i have missed this, thank you.

 |The lack of links in the text-to-HTML conversion of tools.ietf.org \
 |is probably worth reporting as a bug, but a low priority one considering \
 |that the HTML version should be available.  That said, datatracker.ietf.\
 |org only offers "HTMLIZED" and not HTML links.

Yah, hm, hm.  It surely has merits, both HTML as well as PDF.
I have a local RFC pool since, pooh, maybe 2003 or so.  The german
computer magazine c't once put all (?) of them on one of their CDs
by then, and i am only throwing onto that stock ever since.
I personally am almost perfectly served with plain grep(1) on
plain text.  Actually i do not even really care about missing form
feeds, i was only surprised.

Next time i report there.  The anonymous imap.ietf. thing reports
"Resource temporarily unavailable", that could be a possible
starter.

Ciao,

--steffen
|

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 28 Nov 2019 02:27:28 -0800

> This is the outcome of the process that produced RFC 799x and friends.

Hmm, applying xml2rfc 2.35.0 on the xml file does not restore the headers, footers and page breaks.  Is there an option to generate a True RFC(tm) or is it a bug?

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: John C Klensin <[email-masked]>
Date: Thu, 28 Nov 2019 11:33:01 -0500

(copying the IETF list -- this is not an ART matter alone)

TL;DL warning: while not terribly long, this is a rant.

--On Thursday, November 28, 2019 01:50 +0100 Steffen Nurpmeso
<[email-masked]> wrote:

>...
> I have a local RFC pool since, pooh, maybe 2003 or so.  The
> german computer magazine c't once put all (?) of them on one
> of their CDs by then, and i am only throwing onto that stock
> ever since. I personally am almost perfectly served with plain
> grep(1) on plain text.  Actually i do not even really care
> about missing form feeds, i was only surprised.

Hi.  I realize it is very late, probably too late, to be
complaining about this, but my clear recollection was that, when
the v3 project was started, the community was promised that,
while the authoritative/ canonical/ archival format would shift
to the XML and fully-functional HTML and PDF format (not just
HTML and PDF produced from plain text forms) would become
available, the plain text format would be preserved sufficiently
that tools [1] that were designed for, and used with, RFCs for
the last 40-odd years would continue to work and work equally
well [2].  If page breaks, running headers and footers, and TOCs
and indices with page references have disappeared, some of those
tools will cease working (even if grep still does) and that
violates that particular commitment.  If there were an xml2rfc
v3 option that was guaranteed to be supported and that would
generate the older format, even if that format were never stored
on IETF servers, I think that would be sufficient to let us (and
our tools) keep working, but that does not seem to be the case
at present (nor does it address any TOC or index issues).[3]

This is especially important because at least some of us who
prefer the text form when working with RFCs (even if some of us
might prefer something else for reading them), after losing the
argument about whether XML (or any other generic or formatting
markup arrangement) was appropriate as the canonical/archival
form essentially tuned out of the discussions of xml2rfc v3
details and decided to devote our available IETF time to
technical standards and other work that we felt had impact on
the Internet rather than just on the IETF and how it operated.
The tuning out was reinforced as it became clear that xml2rfc v3
was evolving into a odd hybrid between generic and formatting
markup, one that was as or more likely to share the disadvantage
of each rather than the advantages and that, in terms we use
when talking about networking, raises all of the issues of layer
violations.  So we didn't read the reports and documents
carefully; we just assumed that, as long as the plain text
format was stable (pagination and all), we would continue to be
able to work without having to spend time converting habits and
tools.

Perhaps what all of this means is that I (and a few others) are
just old and stuck in our ways and that the IETF would be better
off if we just retired or otherwise moved on.   The "old" part
is certainly true for some of us but I'm not convinced about the
"better off" part.  However, by requiring us to develop new
tools or learn new tricks, this change may have the effect of
raising the bar for effective participation in the IETF enough
to push us out.   That is especially likely when we need to
review and revise older documents.  Personally, I think that
pushing anyone out who is willing to do work and might have
useful contributions to make is a bad idea.

So, even if it is too late to reconsider these decisions, I hope
we can at least be aware of possible negative side effects.

best,
   john

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

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

[3] The last argument for removing pagination in Section 2.1.3
of RFC 6949 is almost completely bogus.   The problems with
unbroken sections that span several pages, including
difficulties with references to material in those sections, was
noticed not long after RFC 1543 was published with its specific
comments about cross-references to sections and not pages, IIR
much earlier.  There was discussion even before then about
insisting on numbered paragraphs, an idea that was abandoned in
large measure because of difficulties with document preparation
and tooling.  For some years, the RFC Editor pushed back
aggressively or (or simply modified) such very long sections,
especially when there were cross-references to them (by either
section number or page number).  Later, for reasons unrelated to
this rant, the pushback became much less frequent.  The problem
is over-long sections; the solution is to manage RFC Style
decisions (during final editing if not earlier) so that they
don't happen, not to pretend that eliminating page numbers will
eliminate those sections by precluding the possibility of using
page number for more granular references.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Nov 2019 17:59:43 +0100

> we can at least be aware of possible negative side effects.

It is never too late to fix this bug.

I think the last few months have uncovered a lot of usages for the plain text form of RFCs, as well as the fact that “nobody will ever look at the plain text now that we have HTML” is maybe true for 80 %, but not for 100 %.

Grüße, Carsten

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 28 Nov 2019 18:55:06 +0100 (CET)

and just let me add to John, that "aestetic" is not always a synonym od 
"funcionality". More machine processable formats are ok if there is an 
advantage out of their use, but if not... then, why?

It's late... but do not foget this

PS: no I'm not a nostalgic of TXT formatting, expecially of the itme when 
there were no toold than "vi" or equivalent an formatting according to 
rules was a real pain (and very few wanted to be I-D editors also because 
of this)...

On Thu, 28 Nov 2019, John C Klensin wrote:

> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

      PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 28 Nov 2019 10:25:05 -0800

On 28 Nov 2019, at 8:33, John C Klensin wrote:

> well [2].

I strongly believe you are wrong: no such promise was made. If you can 
find any actual message that made such a promise, I'm happy to stand 
corrected.

--Paul Hoffman

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Nov 2019 20:05:37 +0100

> developed or maintained under IETF auspices.

Do you have a concrete case of a tool that fails with the new format?

> So perhaps that omission is a bug.

AFAIR, the intent was to *paginate*, nothing more (yes, no headers,
footers, no page numbers).

Best regards, Julian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 29 Nov 2019 08:35:22 -0800

Carsten,

> On Nov 28, 2019, at 8:59 AM, Carsten Bormann <[email-masked]> wrote:
> 

I think that is about right, I use both html and txt.  Html for reading on the screen, txt for doing comments and markups, excerpts in email, etc.

I have one active document that I converted to V3.   I note that the txt output of XML2RFC produces headers, footers, and page breaks.

The other thing I have noticed, since I now have the latest draft produced by V3 and the previous drafts produced by V2, is that several things changed that make this transition more difficult than needed.

The first I have found was when doing the conversion from V2 to V3, the default was to expand references, instead of the one line version.   This can be worked around when using the

--add-xinclude

when doing the conversion.

The other was default symbols in lists.   These can be worked around by using the --legacy-list-symbols when running XML2RFC.

My point is that in both cases I think the defaults should have been to make it closer to V2.  The current defaults make it harder to deal with converting an existing in progress draft from V2 to V3.  I suspect these are issues that many will run into when starting to use V3.

Thanks,
Bob

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Nov 2019 11:59:09 -0500

> I think the last few months have uncovered a lot of usages for the plain text form of RFCs, as well as the fact that “nobody will ever look at the plain text now that we have HTML” is maybe true fo…

I hardly ever look at the true HTML versions. I generally prefer the 
HTMLized form, as it offers many conveniences over the plain text while 
giving line-for-line compatibility with that. It is convenient for 
clipping sections of text into emails for commenting while retaining the 
formatting.

I expect that my interest in the pure HTML format will expand when there 
are documents of interest (to me) that that graphics that don't 
represent well in text.

	Thanks,
	Paul