[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt

Thomas Clausen ietf at thomasclausen.org
Fri Jun 27 09:08:13 PDT 2014

On Jun 27, 2014, at 13:47, George, Wes <wesley.george at twcable.com> wrote:

> 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.


I’m reviewing the bulk (about 70% I think) of my IETF documents on an iPad, and this since the iPad1 came out. 

I do not recognize any of the problems that you indicate above as any that I have encountered.

I am not saying that these problems do not occur. I do not know. 

I am merely providing a data-point based on exhaustive experience with IETF-documents-on-tablets.

>> 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 look
>> archaic.
>> 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.

Steamroller all you want, Wes. The point that I am making is not that we should not evolve. I do not think that that’s what Chris is saying either.

What I am saying is, that in evolving the format, we should be extremely careful to not loose the qualities of the current format that some have come to appreciate. 

We also should be extremely careful to not let hypothetical problems be used as an argument for throwing out "qualities of the current format that some have come to appreciate.”

As someone who practically lives on my tablet, when I hear the argument “on a tablet, XXX, YYY and ZZZ are a problem, therefore we must….”, and I never have encountered XXX, YYY nor ZZZ, then I think that it is right to question if this is a hypothetical or real problem being addressed.


>> 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:
> http://tools.ietf.org/html/draft-hansen-rfc-use-of-pdf-00
> Wes George
> 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.
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list