[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt
Dearlove, Christopher (UK)
chris.dearlove at baesystems.com
Fri Jun 27 05:25:31 PDT 2014
Keeping the current line printer format is not what I've suggested. (I did make one early intemperate comment, later retracted. But it didn't say that, and it's not what you're quoting.)
The characterisation is based on replies here. I was expecting the answer to be "if that's what you want, just print the PDF". Which would have been a fine answer. But rather got a "the PDF is not defined yet". Even that would be fine if combined with a "but it should do something like that", but rather got people saying paper isn't important.
I might add that the printable format needs to include everything normative at least.
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 | Fax: +44 1245 242124
chris.dearlove at baesystems.com | http://www.baesystems.com
BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
From: George, Wes [mailto:wesley.george at twcable.com]
Sent: 27 June 2014 12:47
To: Dearlove, Christopher (UK); John Levine; rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt
----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
On 6/27/14, 6:29 AM, "Dearlove, Christopher (UK)"
<chris.dearlove at baesystems.com> wrote:
>No one has suggested not being able to put things on an iPad.
WG] Well, no, but the problem with the current format, especially the ASCII art, is that it actually doesn't render properly on some eReaders due to the width+font requirements, where a graphic will. So suggesting that the current format is perfectly adequate is in a way doing so.
>However it also remains useful to put things reliably, and formatted at
>least to the point of not splitting things cross pages, on paper.
>Fanfold is just an transparent attempt to make an opinion not your own
>And this got raised because you may not want paper, but some of us do,
>and you at least now appear to be ready to steamroller those who
>disagree with you.
WG] Look, while I don't read and review on paper, I have nothing against paper. That said, I do not believe that your legitimate request for a printer-friendly format translates to a need to keep the existing nongraphical *line printer*-friendly format, and if that's not what you're advocating for, I apologize for misunderstanding you, but given some of the discussion on this thread, it'd be an easy mistake to make. I am, however, prepared to steamroller those who believe that the current format is perfectly acceptable but are unwilling to provide any objective reasons why other than "it works for me" or "it's worked for many years", while continuing to suggest that we haven't properly considered the benefits of the current system before deciding to change it and accusing those suggesting changes of being distracted by shiny objects.
>At the moment what appears to be on offer is
WG] You really do need to go read the draft before making this characterization.
>- Text, but freeflowing and not suitable (tables and figures will break).
WG] This problem is known and has been addressed. The Canonical (XML) RFC format has tags to identify where text that cannot be reflowable and must be displayed with a fixed-width font to ensure that there aren't rendering problems. It should also be straightforward to treat those blocks of text as objects such that they can't break over pages when rendered down for a printer-friendly format. The value of the XML canonical version is that anyone willing to write a processor to do it can render it down to whatever format they'd like.
>- HTML, where some (but definitely not all) browsers might offer what
>you want, but at the least not guaranteed.
WG] as I've said in other threads, you need to be a good bit more specific in your concerns here if we are to properly address them. Hand-waving around interop and compatibility problems is not helpful in the least.
What are the specific limitations that you're concerned about, keeping in mind that IETF will be keeping to standards-based HTML, and not one optimized for a certain browser, and unlikely to require any too many features that aren't in the early HTML specs in order to ensure maximum compatibility.
>- PDF, where format is stated as not defined yet. (It's still my best
>hope, and I think people planning it are thinking of this issue, maybe
>more than they were.)
WG] Appears you should make friends with these chaps:
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
More information about the rfc-interest