Re: [art] New RFCs text formatting

[Claudio Allocchio <[e-mail]>]

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:

> (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
> <[e-mail]> wrote:
>
>> ...
>> 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.
>
> 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.
>
> _______________________________________________
> art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/art
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [e-mail]
                         Senior Technical Officer
tel: [phone]      Italian Academic and       G=Claudio; S=Allocchio;
fax: [phone]        Research Network         P=garr; A=garr; C=it;

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