Re: [art] New RFCs text formatting

[Keith Moore <[e-mail]>]

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