[rfc-i] not just 'lineprinter' (was Re: Fwd: New Version Notification for draft-flanagan-plaintext-00.txt)

Joe Hildebrand (jhildebr) jhildebr at cisco.com
Mon Jun 30 12:29:53 PDT 2014

On 6/30/14, 10:30 AM, "Dave Crocker" <dhc at dcrocker.net> wrote:

>On 6/30/2014 9:08 AM, Joe Hildebrand (jhildebr) wrote:
>> On 6/30/14, 8:36 AM, "Dave Crocker" <dhc at dcrocker.net> wrote:
>>> Many applications do not treat FF as a page break.  Many do.  My
>>> text editor honors it quite nicely and prints pages properly, for
>> I'm going to remember that argument and repeat it back to you once you
>> start saying that there are some applications that don't process Byte
>> Order Marks.  Although in that case, the number of applications is quite
>> small, and your case the number that don't process FF is quite large. :)
>As usual, I guess it's important that we ignore the difference between
>retaining something we've been using for 40+ years, versus adding
>something we haven't been using at all...

The current format hasn't worked for its intended purpose for years except
for people that have lineprinters or software that emulate them, enough
paper to print on, and a magnifying lens to grant them access to the
ASCII7 glory of our "diagrams".   Yes, we're 10 years late in tackling
this problem, but that delay has mostly been caused by what appears to me
to be a misplaced reverence for the past.

I will grant that the current RFC text format has been in use for a long
time.  I revere those that came up with it, and what they were able to
accomplish in spite of its limitations.  I want to learn everything we can
from that experience, and ensure that we can replicate as many of the
features as possible that we know and love about the old format.

Yes, we have to do a lot of work to figure out what to change to.  There
are problems to solve, and nothing is ever going to be perfect.  But in my
opinion we need to try to move forward.  Can we please focus on what those
issues are and how to solve them, rather than trying to desperately cling
to a format that is no longer fulfills its mission?

>(That's not offered as an argument not the addition, but as an argument
>to pay attention to history, even when it doesn't suite one's

Calling the current set of requirements my preferences is a little
insulting.  I think I at least have tried really hard to listen to lots of
different inputs.  I've changed my thinking on several points rather
drastically based on those inputs.  I'm striving to continue to listen and
integrate everyone's needs together.  If you have a place where you see
that I haven't listened well enough, please take it up with me off-list
and I'll try to do better.

If you were referring to the general tone of the conversation or to
others' arguments, then I apologize for overreacting to your parenthetical.

>>> What is nice about Brian's suggestion is that it is very inexpensive
>> Did my tooling proposal make sense to you as a way to achieve this?
>If I were worried about the feasibility of providing
>intelligently-placed FFs, I'd be interested in the pragmatics
>demonstrated by implementation discussion at this stage.  But since I'm
>not, I'm not.

Then I don't understand what we're talking about anymore, sorry.  Perhaps
you could restate it.  I thought what we were talking about is whether it
is feasible to have a non-paginated XML file produce a printable form that
was adequately aesthetically pleasing.  At this point in the design
process, an existence proof seems like it would be all that is required.
As we progress through tooling architecture, design, and implementation,
choices other than the one I proposed may be chosen.

>>> It's not a question of whether every app honors FF, but whether it is
>>> easy for a user who cares about good page breaks to easily get them.
>> And the avoidance of visual or printed trash for the people that don't
>> want them. 
>Feel free to make your case for that, with specifics, but again note the
>counter points that Brian raised, which demonstrate their own
>problematic visuals that significantly affect utility of the printed

1) I go to http://tools.ietf.org/rfc/rfc6120.txt in my browser (Chrome 35
on OSX 10.9.3).  I hit cmd-P to print.  Page 126 of the output is attached
as PDF; you'll note that a) it's some combination of page 136, 137, or 138
of the RFC b) there's a header/footer blooped in the middle of the page
that makes the example hard to read.

2) I rsync the RFC repo and get the raw .txt file.  Two of the text
editors I use daily (SublimeText and Atom) don't even have print options.
TextEdit does the same thing as my browser.  Word 14.4.3 inserts an extra
blank page between each page (which I guess if I printed duplex would
produce something readable).  Pages 5.2 does the same thing as a browser.
Emacs did an even worse job than a browser, because my default font made
the lines longer, wrapping the ones that went over about 68 characters,
and then mangling the pagebreaks like the browser. Xcode 5.1.1 and Xcode
6beta did the same thing as a browser.  Calibre, whose purpose mostly
comes down to converting text formats to other text formats did such an
execrable job that both the PDF and .mobi versions were unusable.

3) After I installed enscript, it got the pagebreaks in the right places,
leaving the bottom of every page with ugly whitespace.

>As for the continuing argumentation style that chooses to say the way to
>deal with deficiencies in one form is to use a different form, please
>no, let's not.

I don't understand this.  If there are deficiencies in one form, we either
need to fix that form (and deal with the side-effects), use another form,
or decide to live with brokenness forever.  It seems like the RFC Editor
has decided that the last choice is no longer viable, so we're left with
one of the other two.

Joe Hildebrand

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rfc6120.pdf
Type: application/pdf
Size: 36856 bytes
Desc: rfc6120.pdf
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20140630/e0ec993b/attachment-0001.pdf>

More information about the rfc-interest mailing list