On 11/29/19 12:07 PM, Julian Reschke wrote:
On 29.11.2019 17:13, Keith Moore wrote:
On 11/29/19 12:01 AM, Julian Reschke wrote:
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.
Yes, the assumption was wrong.
FWIW, I think this is something the RSE should answer.
From my recollection:
1) We did not require the new implementation to do proper pagination,
because we didn't want people to refer to page numbers in RFCs anymore.
I can sort of see that, because if different people are referring to
different versions of the RFC, the page numbers don't work. I
definitely prefer using section numbers for reference. At the same
time, unpaginated RFCs cause problems other than those caused by
omitting page numbers.
2) We also expected that pagination in the plain text output would
require complexity in the formatter, and we wanted to avoid that. That
point is moot now, as the developer decided to implement it anyway.
So if you actually want a plain text RFC with "proper" pagination, take
the "canonical" XML and run it through xml2rfc with the proper options.
Sure, but now I have to go through extra steps, and I have to treat new
RFCs differently than old ones.
And it's not possible to enumerate exactly how all of the tools everyone
is using now break. But more importantly, that's the wrong question to
ask.
Many of us realize that when we revise deployed protocols, it's better
to NOT to make assumptions about which obscure features of deployed
protocols people depend on. Instead we try to maintain strict
compatibility when possible, because we realize that we can't reliably
know about all of the assumptions that are embedded in existing
implementations. Sometimes it's necessary to break strict
compatibility, but arguments of the form "nobody depends on feature X"
are always dubious and should be interpreted as red flags.
For better or worse, the legacy text RFC format is a widely deployed
protocol. And while most people these days are probably not using this
feature, there are actually quite a few modern printers out there that
understand plain text, including form feeds, and also several software
programs that paginate text files based on form feeds.
For me, printing plain text RFCs never ever made sense, because on DIN
A4, they leave ~25% of the page unused. So please don't assume everybody
uses letter-sized paper.
Oh, I don't. But even if, say, you print RFCs 2-up sideways on A4
paper, the pagination is still useful. (Besides, one person's wasted
space on the page is another person's ample space for notes.)
Printing RFCs makes a lot of sense to me, in some circumstances. It's
much easier to make notes on paper than on an HTML or PDF document. I
can read paper more easily in coffee shops or on airplanes than I can on
a laptop. If I'm writing code based on an RFC, I can print out the RFC
and refer to it without the RFC taking up screen space. On the other
hand, a great many more documents can be carried on a laptop than in
paper form. So, I routinely use different RFC formats depending on the
circumstances.
I also don't quite get why you are mentioning printers at all. Are you
saying you can't print the HTML variant?
I never use the HTML variants produced by the RSE. The type is too
small, the sans serif typeface is less legible than Courier. On a normal
width browser window the small type used makes the lines too long to
read. And yes, I can narrow the browser window to make the lines
shorter, but the result "looks" wrong and then I'm constantly resizing
the browser if I need to view other pages. The "HTMLized" RFCs
produced by the IETF tools are a bit better for my purposes. It's not
that I have a great love for fixed-pitch type or paginated text on a
scrolling display, but the RSE HTML versions aren't really making the
best use of either HTML or the browser environment.
I also don't want to use a web browser to read RFCs in most
circumstances, because web browsers are themselves pretty dysfunctional
for document review and not great even for occasional reference when
writing specifications or code. They waste too much screen space, they
make it cumbersome to arrange one's screen space effectively. Also
with a typical desktop, when you click on an editor or word processor to
write code or make notes, it often buries the very browser window you're
referring to, unless maybe you have so much screen space available that
you can completely avoid any overlap of windows. Of course, it's not
the fault of the RSE that modern desktops and web browsers are so
dysfunctional, and web browsers aren't all they're cracked up to be.
(Expecting everyone out there to use Windows is not only incorrect, it's
also insulting.)
Not sure what this has to do with the operating system.
All of the other modern desktop OSes I've used have had little or no
problem dealing with ordinary text files, even if the default
end-of-line convention was different. Windows is the only one I've seen
that was gratuitously, and aggressively, incompatible.
Keith
