the success of MIME types was Re: discouraged by .docx was Re: Plagued by PPTX again
- Original Message - From: Julian Reschke julian.resc...@gmx.de To: Yaakov Stein yaako...@rad.com Cc: John C Klensin john-i...@jck.com; ietf ietf@ietf.org Sent: Monday, November 28, 2011 6:07 PM On 2011-11-26 21:52, Yaakov Stein wrote: That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8. That wouldn't bother me much, but be careful what you wish form. What we have been told is that the rationale behind the use of ASCII and several other formats is that they will remain readable on devices that will be used X years hence. ASCII is already unreadable on many popular devices and in a few years will be no better than old versions of word. ... Can we *please* distinguish between the character encoding we use (US-ASCII) and the file format (text/plain)? If *we* don't get this right, how can we expect anybody else to get it right? You will be aware of the recent threads on apps-discuss about MIME types (of which the text/plain you mention is one) which concluded, AFAICS, that there is no rationale why a (top level) type should or should not exist, there are no criteria for creating new ones, that it is impossible to draw up a taxonomy of types because there is no underlying logic in any dimension. If this were not true, then I believe that something such as text/plain would indeed be the basis of our discussion here, we would be saying that xxx/yy is acceptable for presentations or our mailing lists whilst /...x is not; but we aren't, which to me points to a lack of success of that particular piece of technology. Tom Petch Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: the success of MIME types was Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-29 09:32, t.petch wrote: ... You will be aware of the recent threads on apps-discuss about MIME types (of ... Internet Media Types :-) ... which the text/plain you mention is one) which concluded, AFAICS, that there is no rationale why a (top level) type should or should not exist, there are no criteria for creating new ones, that it is impossible to draw up a taxonomy of types because there is no underlying logic in any dimension. Yes, that's a discussion about top-level types. I don't think there was disagreement *here* (as opposed to, for instance, the WHATWG) about having the types in general. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: the success of MIME types was Re: discouraged by .docx was Re: Plagued by PPTX again
- Original Message - From: Julian Reschke julian.resc...@gmx.de To: Yaakov Stein yaako...@rad.com Cc: John C Klensin john-i...@jck.com; ietf ietf@ietf.org Sent: Monday, November 28, 2011 6:07 PM On 2011-11-26 21:52, Yaakov Stein wrote: That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8. That wouldn't bother me much, but be careful what you wish form. What we have been told is that the rationale behind the use of ASCII and several other formats is that they will remain readable on devices that will be used X years hence. ASCII is already unreadable on many popular devices and in a few years will be no better than old versions of word. ... Can we *please* distinguish between the character encoding we use (US-ASCII) and the file format (text/plain)? If *we* don't get this right, how can we expect anybody else to get it right? You will be aware of the recent threads on apps-discuss about MIME types (of which the text/plain you mention is one) which concluded, AFAICS, that there is no rationale why a (top level) type should or should not exist, there are no criteria for creating new ones, that it is impossible to draw up a taxonomy of types because there is no underlying logic in any dimension. And I would have to characterize all of that as 100% grade A hogwash. I'm not going to bother refuting each point since even if this nonsense were true top-level type rules, or the lack thereof are completely irreleant to the matter at hand. But feel free to read the thread if you want the real story. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: the success of MIME types was Re: discouraged by .docx was Re: Plagued by PPTX again
t.petch wrote: You will be aware of the recent threads on apps-discuss about MIME types The threads are on PPTX and DOCX, that is, file name extensions, not MIME types, which demonstrates that MIME was not necessary and uuencode is just enough. If this were not true, then I believe that something such as text/plain would indeed be the basis of our discussion here, The MIME type of choice, other than text/plain, is application/octet-stream. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
Marc I opened the link on two different devices, to see how the tables rendered. On one (iPod touch with Safari), it worked reasonably. The only problem was that the table columns were skewed due to browser not using monospace fonts. Were the table more complex or were there some truly wacky ASCII art it probably wouldn't have worked. On a second device (running a different browser, unnamed to protect the guilty) I received a continuous stream of characters with no line breaks at all. When viewing the txt version on www.rfc-editor.org that same browser does a fairly good job, assuming that I rotate the device to fit the table into the width. However, these 2 tables were small and relatively simple. Why don't you try Figure 3 of RFC 5087 or Figure 2 or 15 of RFC 5905 ? Y(J)S -Original Message- From: Marc Petit-Huguenin [mailto:petit...@acm.org] Sent: Sunday, November 27, 2011 18:20 To: Yaakov Stein Cc: Dave Aronson; IETF Discussion Subject: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. [1] Try this link: http://ietf.implementers.org/rfc5928.txt. The mime type should be text/lp. On 11/27/2011 12:20 AM, Yaakov Stein wrote: Dave I agree that we are thinking as content creators, and that is the problem. The requirement is not that we will be able to write a new document in 50 years in the same format. The requirement is that we should be able to read the documents written 50 years before. The problem about ASCII art is not simply the monospacing. The main problem is the line wrapping. I have tried many times to look at ASCII art on iPhones, iPods, and even small pads. Once you zoom down sufficiently to get the lines not to break, the characters are no longer readable. For a screen size of about 60 mm, 80 character lines means that the characters are only 0.75mm in width. Even assuming a short figure that could be viewed rotated (width 110 mm) each character width would be only slightly more than the 1 mm needed for viewing, and less than the 1.5 mm needed for actual reading. Put in another way, high-end cellphone screens presently have 640 pixel widths. For 80 character layouts, this translates to 8 pixels per character plus inter-character spacing, or about 6 pixel character widths. Even were they visible (and each pixel is less than 1/10 of a mm!) this would mean very low quality fonts - 5*7 was the lowest quality used by old dot-matrix printers. And modern software is not optimized for readability at that font resolution. So, if we expect people to be able to read our documents in 5 years, let alone 50, we need to stop using ASCII art. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave Aronson Sent: Sunday, November 27, 2011 00:10 To: IETF Discussion Subject: Re: discouraged by .docx was Re: Plagued by PPTX again On Sat, Nov 26, 2011 at 15:52, Yaakov Stein yaako...@rad.com wrote: ASCII is already unreadable on many popular devices Oh? For what reason? Sorry, I'm still using an incredibly stupid phone, so I may be behind the curve on such changes. As far as I've seen in my limited exposure, any difficulty is usually because it's often not linewrapped well (or at all), forcing a lot of horizontal scrolling, especially after being forced to be big enough to be legible on tiny screens not held right up to the face. That's rather inconvenient, but still a far cry from unreadable -- plus it's a problem with the reader program (being too featureless to rewrap the text), not anything inherent in the format. ASCII *artwork*, yes, that often gets ruined by the refusal of many programs to allow the user to display content in a monospaced font. But that's not because it's in plain ASCII; you could say the same thing of a Word or PDF document that incorporates ASCII art. I am referring to the fact that more and more people are reading documents on cell-phones and other small devices. According to analysts, this will be the most popular platform for reading material from the Internet within a few years. But among what audience? End-users at large, yes, I can certainly believe that. But techies, especially of sufficient caliber to even *want
RE: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
That would work too. I added a third URL that returns text/plain;format=fixed;line-length=72 http://ietf.implementers.org/fixed/rfc5928.txt That is the worst option for my two devices. On both devices the line wraps distort the tables beyond recognition. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-26 21:52, Yaakov Stein wrote: That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8. That wouldn't bother me much, but be careful what you wish form. What we have been told is that the rationale behind the use of ASCII and several other formats is that they will remain readable on devices that will be used X years hence. ASCII is already unreadable on many popular devices and in a few years will be no better than old versions of word. ... Can we *please* distinguish between the character encoding we use (US-ASCII) and the file format (text/plain)? If *we* don't get this right, how can we expect anybody else to get it right? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-27 09:20, Yaakov Stein wrote: Dave I agree that we are thinking as content creators, and that is the problem. The requirement is not that we will be able to write a new document in 50 years in the same format. The requirement is that we should be able to read the documents written 50 years before. The problem about ASCII art is not simply the monospacing. The main problem is the line wrapping. I have tried many times to look at ASCII art on iPhones, iPods, and even small pads. Once you zoom down sufficiently to get the lines not to break, the characters are no longer readable. For a screen size of about 60 mm, 80 character lines means that the characters are only 0.75mm in width. Even assuming a short figure that could be viewed rotated (width 110 mm) each character width would be only slightly more than the 1 mm needed for viewing, and less than the 1.5 mm needed for actual reading. Put in another way, high-end cellphone screens presently have 640 pixel widths. For 80 character layouts, this translates to 8 pixels per character plus inter-character spacing, or about 6 pixel character widths. Even were they visible (and each pixel is less than 1/10 of a mm!) this would mean very low quality fonts - 5*7 was the lowest quality used by old dot-matrix printers. And modern software is not optimized for readability at that font resolution. So, if we expect people to be able to read our documents in 5 years, let alone 50, we need to stop using ASCII art. ... I don't think that the format is the problem in this case. If we artwork is too wide for a narrow device as ASCII art, it will also be too wide in other format, such as SVG. What's important is that things that *should* work well on small displays, such a reflowing prose paragraphs, and re-pagination, do so. This is where text/plain fails big (and HTML does not). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2011 01:52 AM, Yaakov Stein wrote: Marc I opened the link on two different devices, to see how the tables rendered. On one (iPod touch with Safari), it worked reasonably. The only problem was that the table columns were skewed due to browser not using monospace fonts. Were the table more complex or were there some truly wacky ASCII art it probably wouldn't have worked. On a second device (running a different browser, unnamed to protect the guilty) I received a continuous stream of characters with no line breaks at all. When viewing the txt version on www.rfc-editor.org that same browser does a fairly good job, assuming that I rotate the device to fit the table into the width. However, these 2 tables were small and relatively simple. Why don't you try Figure 3 of RFC 5087 or Figure 2 or 15 of RFC 5905 ? I added all the RFCs in all 3 directories, so you can now test with your favorite RFC. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7TwaMACgkQ9RoMZyVa61cAEwCfSoNZ0htfiOTnpXbceAEybW0U rOoAoIAd2Ad3b8+n5jzjPKFmkpejeArg =ONLn -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
On 2011-11-27 17:20, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. ... I think something is wrong if we seriously consider that writing new reader tools is the solution to whatever we think our problem is. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2011 01:58 AM, Yaakov Stein wrote: That would work too. I added a third URL that returns text/plain;format=fixed;line-length=72 http://ietf.implementers.org/fixed/rfc5928.txt That is the worst option for my two devices. On both devices the line wraps distort the tables beyond recognition. Well, the point was that a browser or any other display application cannot detect that a specific text file is in fact a line-printer ready text file. This is why we propose to assign a mime type or a mime parameter, so (future) applications know how to present it. The first step is to let John know if you support doing this (and eventually if you have a preference between the 3 options). Then if the idea goes forward, we can start the work of modifying the applications so they render correctly this format. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7TwqcACgkQ9RoMZyVa61cEBACfeL+jaxH86JV7PE1YmDzqDAuK ZAEAn2XoUYFTjinfZuTLctF2MnAhp9kT =swso -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On Mon, Nov 28, 2011 at 06:12:42PM +0100, Julian Reschke wrote: What's important is that things that *should* work well on small displays, such a reflowing prose paragraphs, and re-pagination, do so. This is where text/plain fails big (and HTML does not). That's more of an attribute of the text reader than any thing else. I've had readers that reflow text just fine --- far better than PDF, at any rate. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 18:21, Ted Ts'o wrote: On Mon, Nov 28, 2011 at 06:12:42PM +0100, Julian Reschke wrote: What's important is that things that *should* work well on small displays, such a reflowing prose paragraphs, and re-pagination, do so. This is where text/plain fails big (and HTML does not). That's more of an attribute of the text reader than any thing else. I've had readers that reflow text just fine --- far better than PDF, at any rate. It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
Hacking text display applications when HTML was designed for it already and most RFC's natively generate HTML (xml2rfc), do we really have a problem to solve? On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote: On 2011-11-28 18:21, Ted Ts'o wrote: On Mon, Nov 28, 2011 at 06:12:42PM +0100, Julian Reschke wrote: What's important is that things that *should* work well on small displays, such a reflowing prose paragraphs, and re-pagination, do so. This is where text/plain fails big (and HTML does not). That's more of an attribute of the text reader than any thing else. I've had readers that reflow text just fine --- far better than PDF, at any rate. It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 18:46, Eric Burger wrote: Hacking text display applications when HTML was designed for it already and most RFC's natively generate HTML (xml2rfc), do we really have a problem to solve? ... If all documents were submitted in xml2rfc format (or something equally expressive): not really. We could just generate easy-to-read documents in addition to the official text/plain format, and pretend there's no problem :-). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote: It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. In practice, reflowing RFC-formatted text/plain works just fine. You have to skip the page headers, but it's really not that bad. Yes, ASCII-art won't work well --- but a 800x600 SVG jpeg won't work well on a 3 screen anyway. -- Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 19:24, Theodore Tso wrote: On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote: It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. In practice, reflowing RFC-formatted text/plain works just fine. You have to skip the page headers, but it's really not that bad. Yes, ASCII-art won't work well --- but a 800x600 SVG jpeg won't work well on a 3 screen anyway. Ok, so it works well except when it does not. Not convinced. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
--On Monday, November 28, 2011 18:27 +0100 Julian Reschke julian.resc...@gmx.de wrote: That's more of an attribute of the text reader than any thing else. I've had readers that reflow text just fine --- far better than PDF, at any rate. It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. Julian, PDF/A is a page-image format, just like base PDF. I think there is enough information present to permit reflowing lines and repaginating, but that certainly is not the intent. PDF/A wouldn't help at all with RFC 12 and those nice hand-sketched flowcharts: the ideal display situation would do a little scaling, a little line-intensifying, and a little scrolling of the charts while flowing the (non-header) text. If one knew --via some mechanism such as those Marc has been considering and experimenting with -- that a document was actually in paginated ASCII page images (rather than an ASCII stream) -- what Marc calls line printer -- then the heuristics to remove the pagination headers and footers and flow other text are actually pretty obvious and not much less reliable than trying to display PDF/A in a format not intended by the file creator. Where I think we disagree is how to characterize the situation vis-a-vis rendering engines. If I understood one of your earlier notes, you think that creating new readers/ rendering engines is a bad idea. I think we've had a problem rendering plain-text materials since assorted operating systems decided they were much smarter than users and content-creators about the meaning of line terminators, etc. I think that creating an expectation of being able to render plain text (Given that it isn't 1975 any more, I'd hope for UTF-8 with Bidi and multiple-script rendering support, not just ASCII) in a plausible way, including variations for what the text/plain spec calls fixed, flowed, DelSP, and maybe lp would make a lot of things easier and more sensible. At the other extreme, if one really does want device-dependent formatting and rendering for highly structured text, then many of us (including you, or at least so I assume from earlier comments in other thread) have understood since the early 80s that one wants generic markup, the purer the better. Whether the right answer to that version of the problem is HTML (as someone else said, which version?, to which I'd add which variation?), XML with some agreed-upon characteristics for processors, or even slightly-hybrid combinations of generic markup with inline formatting markup or directives (e.g., docx and the way most people seem to write xml2rfc files) is a matter of taste and how far one wants to go to accommodate arbitrary present and future devices. I don't see a lot of future in those scenarios for formatting markup (e.g., nroff and other runoff descendants) as a distribution format but, as far as I know, if one doesn't count U**x man files, no one ever did. And now, in deference to the colleague who suggested that this whole repeating discussion causes him to have strong urges to find an appropriate virtual tower from which he could start picking people off with an equally virtual weapon, I'm going to try to drop out of this conversation because I don't think any minds are being changed by it. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
Julian Reschke wrote: So, if we expect people to be able to read our documents in 5 years, let alone 50, we need to stop using ASCII art. ASCII arts is just fine. Just that there there is an awful number of modern software that is too stupid to display ASCII text with fixed pitch fonts. (i.e. it applies an information-destroying compression algorithm on the information content). I don't think that the format is the problem in this case. If we artwork is too wide for a narrow device as ASCII art, it will also be too wide in other format, such as SVG. Not always, but often. What's important is that things that *should* work well on small displays, such a reflowing prose paragraphs, and re-pagination, do so. This is where text/plain fails big (and HTML does not). The real problem is buggy software for displaying on small displays. Reflowing ASCII is *no* problem whenever ASCII text is reflowable at all. It can be done in 1-2 KByte of code. Displaying HTML or XML usally requires more than a megabyte of code. And btw. most of the Web pages that I try print out on paper have truncated borders, waste lots of paper because only a small portion of the surface is used for information and sometime only the first page gets printed (the rest only accessible inside the browser with a scroll bar). How to print ASCII text is the type of problems for which easy solutions existed already 20 years ago. That some modern devices fail to display ascii text in a reasonable fashion is a demonstration that the software in these devices is defective, not that it is not possible to sensibly display ascii on such devices. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 20:29, John C Klensin wrote: --On Monday, November 28, 2011 18:27 +0100 Julian Reschke julian.resc...@gmx.de wrote: That's more of an attribute of the text reader than any thing else. I've had readers that reflow text just fine --- far better than PDF, at any rate. It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. Julian, PDF/A is a page-image format, just like base PDF. I think there is enough information present to permit reflowing lines and repaginating, but that certainly is not the intent. I think it's the intent with the reflowable feature. (It may not be used a lot, but it's there; it requires consideration on generation time, though). ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 20:44, Martin Rex wrote: ... The real problem is buggy software for displaying on small displays. Reflowing ASCII is *no* problem whenever ASCII text is reflowable at all. It can be done in 1-2 KByte of code. Displaying HTML or XML But our format currently is not reflowable. Can we make it? And if we do so, do we have clients to display it? usally requires more than a megabyte of code. ... So? And btw. most of the Web pages that I try print out on paper have truncated borders, waste lots of paper because only a small portion of the surface is used for information and sometime only the first page gets printed (the rest only accessible inside the browser with a scroll bar). Use a proper browser (- Firefox), and make sure to do print preview. How to print ASCII text is the type of problems for which easy solutions existed already 20 years ago. That some modern devices fail to display ascii text in a reasonable fashion is a demonstration that the software in these devices is defective, not that it is not possible to sensibly display ascii on such devices. No, it just shows that our format has been optimized for a use case which almost nobody cares about anymore. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On Mon, Nov 28, 2011 at 09:03:02PM +0100, Julian Reschke wrote: No, it just shows that our format has been optimized for a use case which almost nobody cares about anymore. Perhaps because no one actually reads RFC's on these small devices, and so we've been trolled by a master into worrying about a use case which isn't really a problem. And plain text works just *fine* on a desktop machines, which is what implementors of network protocols generally use. If we actually have people regularly coding up TCP or IPSEC or SMTP implementations on iPhones or Android devices, at some future point in time, we can worry then about whether those devices can correctly deal with text/plain RFC's. :-) Thinking about how to deal with deeply nested C, C++, or Java code on a 3 screen is kind of amusing, though. :-) Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On Mon, Nov 28, 2011 at 15:26, Ted Ts'o ty...@mit.edu wrote: plain text works just *fine* on a desktop machines, which is what implementors of network protocols generally use. That's what I've been trying to tell them -- but some people love to engineer so much that they don't know when to stop! -Dave -- LOOKING FOR WORK! What: Ruby (on/off Rails), Python, other modern languages. Where: Northern Virginia, Washington DC (near Orange Line), and remote work. See: davearonson.com (main) * codosaur.us (code) * dare2xl.com (excellence). Specialization is for insects. (Heinlein) - Have Pun, Will Babble! (Aronson) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
Julian Reschke wrote: On 2011-11-28 20:44, Martin Rex wrote: ... The real problem is buggy software for displaying on small displays. Reflowing ASCII is *no* problem whenever ASCII text is reflowable at all. It can be done in 1-2 KByte of code. Displaying HTML or XML But our format currently is not reflowable. Can we make it? And if we do so, do we have clients to display it? ASCII itself is fully reflowable. Web Browsers that are displaying HTML are actually reflowing ASCII pretty much on every page. But there are two things that cause problems: * reflowing ascii arts makes the information incomprehensible * displaying ascii arts with variable width fonts distorts the information up to incomprehensibility Since plain ascii does not contain hints about reflowability, the visualization software would need to account for two things: * a heuristic to ensure that lines that should not be reflowed are not reflowed. Looking at the amount of whitespace (empty lines) and left to the text (indent) is often sufficient. * display non-flowed text with a fixed-width font (which normally means that the flowed text should also be displayed with a fixed-width font by default) Really, displaying ascii text was a *solved* problem 30 years ago, where the common environment was 8-bit CPU, 2 Mhz clock cycle and 1-2 kByte of code for display text. It would almost a no-brainer to make this work on smartphones and pads--so unless one is stuck in a no-brain situation... When modern display devices, which claim to be *made* for reading text, can not adequately display ASCII text that is pre-formatted for 80chars line-length, then it is first of all a clear shortcoming of the software on these devices and the engineers responsible for this software. During this summer holiday, I tried to use my childs Nintendo DSI (256x192 3.25 inch display, WLAN-support, Opera Browser) for reading a few news headlines in a language I am more accustomed to than french. I only used it with HTML pages, but it was a royal PITA as far as usability goes, inspite of HTMLs flowability. There are Phones with displays of 128 pixels across. Where is the limit? At 480 pixels wide, a display could show 80 char fixed width text directly (e.g. xterm -fn 6x10), unless the software, that tries to render the text, is too dense to accomplish this in a sensible fashion. usally requires more than a megabyte of code. ... So? Fix the obviously broken readers of new devices rather than requiring 30 full years of computing history being re-edited and re-published just so that the dense creators of those devices do not have to add 1-2 KByte of code for sensibly visualizing ASCII text (which seems too much to ask compared to the megabytes of code-updates that vendors have to regularly provide due to other shortcomings and negligences in the security area.) And btw. most of the Web pages that I try print out on paper have truncated borders, waste lots of paper because only a small portion of the surface is used for information and sometime only the first page gets printed (the rest only accessible inside the browser with a scroll bar). Use a proper browser (- Firefox), and make sure to do print preview. I do and it regularly doesn't work. Many sites render well only in specific browser and print badly, if at all. How to print ASCII text is the type of problems for which easy solutions existed already 20 years ago. That some modern devices fail to display ascii text in a reasonable fashion is a demonstration that the software in these devices is defective, not that it is not possible to sensibly display ascii on such devices. No, it just shows that our format has been optimized for a use case which almost nobody cares about anymore. I'm sorry, but I'm a developer and not in the professional publishing service, and I care much more about non-flowing 80-char text than I care about flowing text. I have my EMail at 80chars, and I try to make all of my C-Source code fit 80-chars, and accompanying readme.txts at 80 chars. And most other C-Code I look at is the same. Last time I checked, the IETF was about Engineering. I often put snippets of RFCs into code comment blocks of my C-Code. Not having to reformat the text manually saves me a lot of time (compared to copying ASN.1 structures into comments from ISO X.something). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 2011-11-28 22:09, Martin Rex wrote: Julian Reschke wrote: On 2011-11-28 20:44, Martin Rex wrote: ... The real problem is buggy software for displaying on small displays. Reflowing ASCII is *no* problem whenever ASCII text is reflowable at all. It can be done in 1-2 KByte of code. Displaying HTML or XML But our format currently is not reflowable. Can we make it? And if we do so, do we have clients to display it? ASCII itself is fully reflowable. Web Browsers that are displaying HTML are actually reflowing ASCII pretty much on every page. Web browsers that display text/html are reflowing text pretty much on every page. Yes, that's my point. Again: please distinguish between character encodings and file formats. Web browsers are *not* reflowing text/plain, and that's the format we currently use. But there are two things that cause problems: * reflowing ascii arts makes the information incomprehensible That's why you need markup so the browser knows what is what. * displaying ascii arts with variable width fonts distorts the information up to incomprehensibility That's why you need markup so the browser knows what is what. Since plain ascii does not contain hints about reflowability, the visualization software would need to account for two things: * a heuristic to ensure that lines that should not be reflowed are not reflowed. Looking at the amount of whitespace (empty lines) and left to the text (indent) is often sufficient. Maybe. Maybe not. Proposal: take Henrik's rfcmarkup tool and tune it so that it *reliably* distinguishes between reflowable stuff and what's not (examples, diagrams, tables, whatnot). Once you get this working in more than a few sample documents I'll likely tell you: great, but why didn't you produce HTML in the first place? * display non-flowed text with a fixed-width font (which normally means that the flowed text should also be displayed with a fixed-width font by default) I disagree, but that's another thing HTML allows you to control. Really, displaying ascii text was a *solved* problem 30 years ago, where the common environment was 8-bit CPU, 2 Mhz clock cycle and 1-2 kByte of code for display text. It would almost a no-brainer to make this work on smartphones and pads--so unless one is stuck in a no-brain situation... So go ahead, do it. I don't mean to be rude but telling people that it's simple doesn't help. Do it. When modern display devices, which claim to be *made* for reading text, can not adequately display ASCII text that is pre-formatted for 80chars line-length, then it is first of all a clear shortcoming of the software on these devices and the engineers responsible for this software. No, it's just a sign that the world today is different from the world 30 years ago. During this summer holiday, I tried to use my childs Nintendo DSI (256x192 3.25 inch display, WLAN-support, Opera Browser) for reading a few news headlines in a language I am more accustomed to than french. I only used it with HTML pages, but it was a royal PITA as far as usability goes, inspite of HTMLs flowability. Yes. What does this prove? There are Phones with displays of 128 pixels across. Where is the limit? I think it would be worthy goal to get proper display of RFCs on 7 inch tables in portrait mode, or dedicated ebook readers of that size. ... usally requires more than a megabyte of code. ... So? Fix the obviously broken readers of new devices rather than requiring 30 full years of computing history being re-edited and re-published just so that the dense creators of those devices do not have to add 1-2 KByte of code for sensibly visualizing ASCII text (which seems too much to ask compared to the megabytes of code-updates that vendors have to regularly provide due to other shortcomings and negligences in the security area.) And btw. most of the Web pages that I try print out on paper have truncated borders, waste lots of paper because only a small portion of the surface is used for information and sometime only the first page gets printed (the rest only accessible inside the browser with a scroll bar). Use a proper browser (- Firefox), and make sure to do print preview. I do and it regularly doesn't work. Many sites render well only in specific browser and print badly, if at all. Yes. You need to consider printing when generating the HTML. You also need to consider printing when generating text/plain. But with the latter it's much harder because you need to known the paper dimensions beforehand. How to print ASCII text is the type of problems for which easy solutions existed already 20 years ago. That some modern devices fail to display ascii text in a reasonable fashion is a demonstration that the software in these devices is defective, not that it is not possible to sensibly display ascii on such devices. No, it just shows that our format has been optimized for a
RE: discouraged by .docx was Re: Plagued by PPTX again
Perhaps because no one actually reads RFC's on these small devices, and so we've been trolled by a master into worrying about a use case which isn't really a problem. I, for one, regularly (attempt to) read RFCs and other standards on small devices. I do this because I have stopped shlepping a laptop to short meetings. (I still take a laptop to week-long conferences like the IETF, but that is because I can't afford not working on day-job tasks.) Frequently I am sitting in a lecture or discussion and something comes up that I want to check. Of course epubs and similar screen-size-aware formats are optimal, but doc, docx, ppt, pptx, and most HTML are very reasonable. PDF is workable but requires a lot of pan/zoom effort. Text RFCs are completely impossible to read. I have experimented with TeX and LaTeX (source text), and can get it to work very well on A5 format pads, and reasonably well on smaller devices. The main problem with the smaller devices derives figures that are not in native TeX or eps, but rather imported from gif or jpg. (I haven't tried SVG, but assume that it would work similarly to embedded postscript.) BTW, there is a great algorithm for shrinking relatively sparse images that conserves structure even if the text becomes too small to read; but even it breaks down at some point. I was thinking about hacking around with our xml format, but realized that the ASCII art problem is a show-stopper. It would be easy to detect the special cases, but what would I do about them ? The obvious answer - simply treating them as fixed length and reducing the size, doesn't produce useful figures. Unlike native TeX diagrams where the graphic elements are in markup language, here multiple special visual characters (like for an arrow head) effectively disappear. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: discouraged by .docx was Re: Plagued by PPTX again
Dave I agree that we are thinking as content creators, and that is the problem. The requirement is not that we will be able to write a new document in 50 years in the same format. The requirement is that we should be able to read the documents written 50 years before. The problem about ASCII art is not simply the monospacing. The main problem is the line wrapping. I have tried many times to look at ASCII art on iPhones, iPods, and even small pads. Once you zoom down sufficiently to get the lines not to break, the characters are no longer readable. For a screen size of about 60 mm, 80 character lines means that the characters are only 0.75mm in width. Even assuming a short figure that could be viewed rotated (width 110 mm) each character width would be only slightly more than the 1 mm needed for viewing, and less than the 1.5 mm needed for actual reading. Put in another way, high-end cellphone screens presently have 640 pixel widths. For 80 character layouts, this translates to 8 pixels per character plus inter-character spacing, or about 6 pixel character widths. Even were they visible (and each pixel is less than 1/10 of a mm!) this would mean very low quality fonts - 5*7 was the lowest quality used by old dot-matrix printers. And modern software is not optimized for readability at that font resolution. So, if we expect people to be able to read our documents in 5 years, let alone 50, we need to stop using ASCII art. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave Aronson Sent: Sunday, November 27, 2011 00:10 To: IETF Discussion Subject: Re: discouraged by .docx was Re: Plagued by PPTX again On Sat, Nov 26, 2011 at 15:52, Yaakov Stein yaako...@rad.com wrote: ASCII is already unreadable on many popular devices Oh? For what reason? Sorry, I'm still using an incredibly stupid phone, so I may be behind the curve on such changes. As far as I've seen in my limited exposure, any difficulty is usually because it's often not linewrapped well (or at all), forcing a lot of horizontal scrolling, especially after being forced to be big enough to be legible on tiny screens not held right up to the face. That's rather inconvenient, but still a far cry from unreadable -- plus it's a problem with the reader program (being too featureless to rewrap the text), not anything inherent in the format. ASCII *artwork*, yes, that often gets ruined by the refusal of many programs to allow the user to display content in a monospaced font. But that's not because it's in plain ASCII; you could say the same thing of a Word or PDF document that incorporates ASCII art. I am referring to the fact that more and more people are reading documents on cell-phones and other small devices. According to analysts, this will be the most popular platform for reading material from the Internet within a few years. But among what audience? End-users at large, yes, I can certainly believe that. But techies, especially of sufficient caliber to even *want* to read the IETF's output, let alone participate in creating it? Very doubtful. I don't think we'll be giving up our laptops, never mind large monitors, any time soon. Phones and tablets are for content *consumption*. We are content *creators*, be it programs, documents, or whatever. That's an entirely different set of hardware requirements. When was the last time you saw a program or document or anything else of significant size, written using a phone, or even a tablet? -Dave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
Naah. We should update the 72-character ASCII limit to 40-characters. Not only will that work for all of these mobile devices, it will work on a TRS-80, too. On Nov 27, 2011, at 3:20 AM, Yaakov Stein wrote: Dave I agree that we are thinking as content creators, and that is the problem. The requirement is not that we will be able to write a new document in 50 years in the same format. The requirement is that we should be able to read the documents written 50 years before. The problem about ASCII art is not simply the monospacing. The main problem is the line wrapping. I have tried many times to look at ASCII art on iPhones, iPods, and even small pads. Once you zoom down sufficiently to get the lines not to break, the characters are no longer readable. For a screen size of about 60 mm, 80 character lines means that the characters are only 0.75mm in width. Even assuming a short figure that could be viewed rotated (width 110 mm) each character width would be only slightly more than the 1 mm needed for viewing, and less than the 1.5 mm needed for actual reading. Put in another way, high-end cellphone screens presently have 640 pixel widths. For 80 character layouts, this translates to 8 pixels per character plus inter-character spacing, or about 6 pixel character widths. Even were they visible (and each pixel is less than 1/10 of a mm!) this would mean very low quality fonts - 5*7 was the lowest quality used by old dot-matrix printers. And modern software is not optimized for readability at that font resolution. So, if we expect people to be able to read our documents in 5 years, let alone 50, we need to stop using ASCII art. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave Aronson Sent: Sunday, November 27, 2011 00:10 To: IETF Discussion Subject: Re: discouraged by .docx was Re: Plagued by PPTX again On Sat, Nov 26, 2011 at 15:52, Yaakov Stein yaako...@rad.com wrote: ASCII is already unreadable on many popular devices Oh? For what reason? Sorry, I'm still using an incredibly stupid phone, so I may be behind the curve on such changes. As far as I've seen in my limited exposure, any difficulty is usually because it's often not linewrapped well (or at all), forcing a lot of horizontal scrolling, especially after being forced to be big enough to be legible on tiny screens not held right up to the face. That's rather inconvenient, but still a far cry from unreadable -- plus it's a problem with the reader program (being too featureless to rewrap the text), not anything inherent in the format. ASCII *artwork*, yes, that often gets ruined by the refusal of many programs to allow the user to display content in a monospaced font. But that's not because it's in plain ASCII; you could say the same thing of a Word or PDF document that incorporates ASCII art. I am referring to the fact that more and more people are reading documents on cell-phones and other small devices. According to analysts, this will be the most popular platform for reading material from the Internet within a few years. But among what audience? End-users at large, yes, I can certainly believe that. But techies, especially of sufficient caliber to even *want* to read the IETF's output, let alone participate in creating it? Very doubtful. I don't think we'll be giving up our laptops, never mind large monitors, any time soon. Phones and tablets are for content *consumption*. We are content *creators*, be it programs, documents, or whatever. That's an entirely different set of hardware requirements. When was the last time you saw a program or document or anything else of significant size, written using a phone, or even a tablet? -Dave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. [1] Try this link: http://ietf.implementers.org/rfc5928.txt. The mime type should be text/lp. On 11/27/2011 12:20 AM, Yaakov Stein wrote: Dave I agree that we are thinking as content creators, and that is the problem. The requirement is not that we will be able to write a new document in 50 years in the same format. The requirement is that we should be able to read the documents written 50 years before. The problem about ASCII art is not simply the monospacing. The main problem is the line wrapping. I have tried many times to look at ASCII art on iPhones, iPods, and even small pads. Once you zoom down sufficiently to get the lines not to break, the characters are no longer readable. For a screen size of about 60 mm, 80 character lines means that the characters are only 0.75mm in width. Even assuming a short figure that could be viewed rotated (width 110 mm) each character width would be only slightly more than the 1 mm needed for viewing, and less than the 1.5 mm needed for actual reading. Put in another way, high-end cellphone screens presently have 640 pixel widths. For 80 character layouts, this translates to 8 pixels per character plus inter-character spacing, or about 6 pixel character widths. Even were they visible (and each pixel is less than 1/10 of a mm!) this would mean very low quality fonts - 5*7 was the lowest quality used by old dot-matrix printers. And modern software is not optimized for readability at that font resolution. So, if we expect people to be able to read our documents in 5 years, let alone 50, we need to stop using ASCII art. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave Aronson Sent: Sunday, November 27, 2011 00:10 To: IETF Discussion Subject: Re: discouraged by .docx was Re: Plagued by PPTX again On Sat, Nov 26, 2011 at 15:52, Yaakov Stein yaako...@rad.com wrote: ASCII is already unreadable on many popular devices Oh? For what reason? Sorry, I'm still using an incredibly stupid phone, so I may be behind the curve on such changes. As far as I've seen in my limited exposure, any difficulty is usually because it's often not linewrapped well (or at all), forcing a lot of horizontal scrolling, especially after being forced to be big enough to be legible on tiny screens not held right up to the face. That's rather inconvenient, but still a far cry from unreadable -- plus it's a problem with the reader program (being too featureless to rewrap the text), not anything inherent in the format. ASCII *artwork*, yes, that often gets ruined by the refusal of many programs to allow the user to display content in a monospaced font. But that's not because it's in plain ASCII; you could say the same thing of a Word or PDF document that incorporates ASCII art. I am referring to the fact that more and more people are reading documents on cell-phones and other small devices. According to analysts, this will be the most popular platform for reading material from the Internet within a few years. But among what audience? End-users at large, yes, I can certainly believe that. But techies, especially of sufficient caliber to even *want* to read the IETF's output, let alone participate in creating it? Very doubtful. I don't think we'll be giving up our laptops, never mind large monitors, any time soon. Phones and tablets are for content *consumption*. We are content *creators*, be it programs, documents, or whatever. That's an entirely different set of hardware requirements. When was the last time you saw a program or document or anything else of significant size, written using a phone, or even a tablet? -Dave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7SYzsACgkQ9RoMZyVa61eSRACfQsLQvu0pa/gR/LTNlGiMBpIH /w0AoINZZMQGcPqUzn9QK/nlQR/w/oUq =2eH4 -END PGP SIGNATURE- ___ Ietf mailing list
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
--On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. Out of curiosity (and again my better judgment about getting further involved in this discussion), why do you think text/lp is needed and not text/plain; charset=US-ASCII; format=lp ? (please read RFC 3676 before answering -- it is not clear to me that format=fixed would not do as well, possibly supplemented by an additional line length parameter. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On Sun, Nov 27, 2011 at 03:20, Yaakov Stein yaako...@rad.com wrote: The requirement is not that we will be able to write a new document in 50 years in the same format. The requirement is that we should be able to read the documents written 50 years before. The problem about ASCII art is not simply the monospacing. The main problem is the line wrapping. (snip what was essentially my original inconvenient but a far cry from unreadable scenario) It might make sense to limit based on that, if such small screens were the only ones that we expect people with an interest in our documents, to have easy access to. However, the trend is not *only* towards small screens, but also a *multitude* of screens. (Some are even getting *larger*, such as the monitors used by . . . our typical audience.) The presence of the newer smaller screens is a red herring, so long as the older larger ones are still around -- and I expect them to still be around forever, if for no other reason than exactly what you describe! -Dave -- LOOKING FOR WORK! What: Ruby (on/off Rails), Python, other modern languages. Where: Northern Virginia, Washington DC (near Orange Line), and remote work. See: davearonson.com (main) * codosaur.us (code) * dare2xl.com (excellence). Specialization is for insects. (Heinlein) - Have Pun, Will Babble! (Aronson) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On Sun, Nov 27, 2011 at 08:17, Eric Burger ebur...@standardstrack.com wrote: Naah. We should update the 72-character ASCII limit to 40-characters. Not only will that work for all of these mobile devices, it will work on a TRS-80, too. But that's still too big for even present-day iPod Nanos. Their screens are just over an inch wide. Clearly we need to wrap at no more than about 25 characters. For future-proofing (when people have their (ahem) audio devices that just happen to also have semi-legible screens, embedded into literal thumbnails) we ought to reduce it to ten. -Dave -- LOOKING FOR WORK! What: Ruby (on/off Rails), Python, other modern languages. Where: Northern Virginia, Washington DC (near Orange Line), and remote work. See: davearonson.com (main) * codosaur.us (code) * dare2xl.com (excellence). Specialization is for insects. (Heinlein) - Have Pun, Will Babble! (Aronson) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2011 10:36 AM, John C Klensin wrote: --On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. Out of curiosity (and again my better judgment about getting further involved in this discussion), why do you think text/lp is needed and not text/plain; charset=US-ASCII; format=lp ? Did not think of that, that's better IMO. Apache can do this (the link I gave in a previous email is now returning text/plain; format=lp; charset=us-ascii). But this creates practical issues. My browser is not capable of assigning a specific helper to text/plain; format=lp, say /usr/bin/qrfcview (i.e. different from text/plain; format=fixed which in my case would be assigned to /usr/bin/gvim). An Android app would have the same issue as I guess many other platforms. It is the display application that will have to use this parameter to select the display mode, so instead of having an additional program per platform that displays the text/lp type, we will need to modify all applications that can render text/plain so they can correctly interpret the format=lp parameter. (please read RFC 3676 before answering -- it is not clear to me that format=fixed would not do as well, possibly supplemented by an additional line length parameter. What would be missing is an indication that only a fixed font must be used. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7SjXcACgkQ9RoMZyVa61ctQwCgp5s/U1a5h/8B1bUM+1iTY6P6 I2UAnRvf4qeSRwwmzBP3XRVX5raLMdcI =XIXx -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2011 11:20 AM, Marc Petit-Huguenin wrote: On 11/27/2011 10:36 AM, John C Klensin wrote: --On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. Out of curiosity (and again my better judgment about getting further involved in this discussion), why do you think text/lp is needed and not text/plain; charset=US-ASCII; format=lp ? Did not think of that, that's better IMO. Apache can do this (the link I gave in a previous email is now returning text/plain; format=lp; charset=us-ascii). http://ietf.implementers.org/mime/rfc5928.txt now returns text/lp http://ietf.implementers.org/format/rfc5928.txt now returns text/plain;format=lp - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7SjvwACgkQ9RoMZyVa61dwmQCaAhj6WDUNR3Zvv04jSA2Xs65y 2LcAn3vLq1/LOUxyfTCpkHzPKvHfj42f =ba/+ -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
--On Sunday, November 27, 2011 11:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: On 11/27/2011 10:36 AM, John C Klensin wrote: --On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. Out of curiosity (and again my better judgment about getting further involved in this discussion), why do you think text/lp is needed and not text/plain; charset=US-ASCII; format=lp ? Did not think of that, that's better IMO. Apache can do this (the link I gave in a previous email is now returning text/plain; format=lp; charset=us-ascii). But this creates practical issues. My browser is not capable of assigning a specific helper to text/plain; format=lp, say /usr/bin/qrfcview (i.e. different from text/plain; format=fixed which in my case would be assigned to /usr/bin/gvim). An Android app would have the same issue as I guess many other platforms. This (IMO, deficient) issue with browsers refusing to differentiate / dispatch on parameters is the traditional issue with such parameters. The choice then becomes one between fix the obscenity browsers and propagate media subtypes when parameters would do. I obviously have a preference, but it may not be practical/realistic. It is the display application that will have to use this parameter to select the display mode, so instead of having an additional program per platform that displays the text/lp type, we will need to modify all applications that can render text/plain so they can correctly interpret the format=lp parameter. Yep, although that modification would serve us well in lots of other ways, IMO. (please read RFC 3676 before answering -- it is not clear to me that format=fixed would not do as well, possibly supplemented by an additional line length parameter. What would be missing is an indication that only a fixed font must be used. But RFC 3636 says (Section 3) Text/Plain is usually displayed as preformatted text, often in a fixed font.. That is clearly a lot short of a requirement but, if one were going to use a line length parameter, one could specify that it implies a fixed-width font or display system (or name it something that would make that more clear). I'm willing to write up either an extension/update to RFC3676 or a new subtype if there is enough expression of interest (not just the two of us) to indicate that such a proposal would be likely to go somewhere. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2011 11:38 AM, John C Klensin wrote: --On Sunday, November 27, 2011 11:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: On 11/27/2011 10:36 AM, John C Klensin wrote: --On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. Out of curiosity (and again my better judgment about getting further involved in this discussion), why do you think text/lp is needed and not text/plain; charset=US-ASCII; format=lp ? Did not think of that, that's better IMO. Apache can do this (the link I gave in a previous email is now returning text/plain; format=lp; charset=us-ascii). But this creates practical issues. My browser is not capable of assigning a specific helper to text/plain; format=lp, say /usr/bin/qrfcview (i.e. different from text/plain; format=fixed which in my case would be assigned to /usr/bin/gvim). An Android app would have the same issue as I guess many other platforms. This (IMO, deficient) issue with browsers refusing to differentiate / dispatch on parameters is the traditional issue with such parameters. The choice then becomes one between fix the obscenity browsers and propagate media subtypes when parameters would do. I obviously have a preference, but it may not be practical/realistic. It is the display application that will have to use this parameter to select the display mode, so instead of having an additional program per platform that displays the text/lp type, we will need to modify all applications that can render text/plain so they can correctly interpret the format=lp parameter. Yep, although that modification would serve us well in lots of other ways, IMO. (please read RFC 3676 before answering -- it is not clear to me that format=fixed would not do as well, possibly supplemented by an additional line length parameter. What would be missing is an indication that only a fixed font must be used. But RFC 3636 says (Section 3) Text/Plain is usually displayed as preformatted text, often in a fixed font.. That is clearly a lot short of a requirement but, if one were going to use a line length parameter, one could specify that it implies a fixed-width font or display system (or name it something that would make that more clear). That would work too. I added a third URL that returns text/plain;format=fixed;line-length=72 http://ietf.implementers.org/fixed/rfc5928.txt I'm willing to write up either an extension/update to RFC3676 or a new subtype if there is enough expression of interest (not just the two of us) to indicate that such a proposal would be likely to go somewhere. john - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7SlCoACgkQ9RoMZyVa61c4twCgpONWZDAtNdLObMMCbIhJ0tBV CboAoJEqk3z5QuBopwDdCwSTtEgAbpjZ =ZxUz -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
On 27 November 2011 20:38, John C Klensin john-i...@jck.com wrote: I'm willing to write up either an extension/update to RFC3676 or a new subtype if there is enough expression of interest (not just the two of us) to indicate that such a proposal would be likely to go somewhere. As Gmail web UI user I'm interested in any attempts to get the concept of monospaced to the attention of Google engineers. So far a user script (or of course a MUA such as TB) do the trick for me after Gmail killed its monospaced lab some years ago. Use simple words (4 or less characters) in short sentences (no commas, semicolons, dashes, only MUSTard and periods), this is a very advanced topic for folks who never used command lines or punched cards. -Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
--On Saturday, November 26, 2011 12:11 +0100 t.petch daedu...@btconnect.com wrote: Could we also say 'No' to .docx, another incomprehensible format designed to persuade us to take time out, spend money and upgrade all and sundry? I notice some ADs/WG chairs using this and while it gets converted to good ole ASCII when it is archived, I would like to be able to read it earlier in the process. FWIW, I think that, if we are going to start banning proprietary formats, it makes lots more sense to ban _all_ proprietary formats, not just picking and choosing among proprietary formats that are, e.g., more recent or less frequently reverse-engineered than others. So, yes, let's ban pptx, docx, ppt, doc, non-standardized forms of PDF, GIF, ... That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8. That wouldn't bother me much, but be careful what you wish form. john john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 11/26/11 11:43 AM, John C Klensin wrote: --On Saturday, November 26, 2011 12:11 +0100 t.petch daedu...@btconnect.com wrote: Could we also say 'No' to .docx, another incomprehensible format designed to persuade us to take time out, spend money and upgrade all and sundry? I notice some ADs/WG chairs using this and while it gets converted to good ole ASCII when it is archived, I would like to be able to read it earlier in the process. FWIW, I think that, if we are going to start banning proprietary formats, it makes lots more sense to ban _all_ proprietary formats, not just picking and choosing among proprietary formats that are, e.g., more recent or less frequently reverse-engineered than others. So, yes, let's ban pptx, docx, ppt, doc, non-standardized forms of PDF, GIF, ... That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8. That wouldn't bother me much, but be careful what you wish form. HTML is not on that list? Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
FWIW, I think that, if we are going to start banning proprietary formats, it makes lots more sense to ban _all_ proprietary formats, not just picking and choosing among proprietary formats that are, e.g., more recent or less frequently reverse-engineered than others. So, yes, let's ban pptx, docx, ppt, doc, non-standardized forms of PDF, GIF, ... I gather that you consider ECMA-376 and ISO/IEC 29500 formats to be proprietary. On the other hand, the definition of GIF is in a 20 year old document published by a predecessor of AOL, which includes a widely ignored trademark license requirement and an infamous patent. Hmmn. Since apparently some formats specified in ECMA and ISO standards are proprietary, while some that are privately defined and encumbered with trademark and patent restrictions are not, could someone provide a concise description of how I can recognize a non-proprietary format? R's, John PS: I'm not denying that docx and pptx can be unpleasant to deal with, although LibreOffice hides a lot of the unpleasantness. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On Sat, Nov 26, 2011 at 6:11 AM, t.petch daedu...@btconnect.com wrote: I notice some ADs/WG chairs using this and while it gets converted to good ole ASCII when it is archived, I would like to be able to read it earlier in the process. To allow people to read versions of documents throughout the development process, export to ASCII/PDF could be suggested/encouraged/required when versions of documents are shared with others. Given a dozen authors, one may find a dozen different authoring environments using a half-dozen or more word processing, markup, or typesetting applications. Even with that diversity, all of the documents can (likely) be distilled down into a tidy set of PDF/A files. If interoperability is required for shared editing of documents, then I agree that formats like ASCII or plain HTML might be more widely supported than a format such as Word binary (.doc) or OOXML, but for just shared viewing of documents, I believe that PDF/A will serve very well. --R ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 11/26/2011 10:50 AM, Peter Saint-Andre wrote: That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8. That wouldn't bother me much, but be careful what you wish form. HTML is not on that list? No doubt it should be, but which version, exactly? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 11/26/2011 11:23 AM, John Levine wrote: I gather that you consider ECMA-376 and ISO/IEC 29500 formats to be proprietary. John, Citing open specs is relevant and probably important, but this being the IETF, it is always trumped by interoperability concerns. In this case, we've seen references to /continuing/ interoperability problems when trying to use docx. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
I gather that you consider ECMA-376 and ISO/IEC 29500 formats to be proprietary. In this case, we've seen references to /continuing/ interoperability problems when trying to use docx. I wouldn't disagree, but if we mean easy to interoperate, let's say so. Word 97-2003 format is totally proprietary, but is now sufficiently widely reverse engineered that it interoperates pretty well. On the other hand, ODF format is well documented and interoperates well among different software that support it, but since old versions of Microsoft Office don't support it, we get complaints. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On 11/26/2011 11:51 AM, John R. Levine wrote: I gather that you consider ECMA-376 and ISO/IEC 29500 formats to be proprietary. In this case, we've seen references to /continuing/ interoperability problems when trying to use docx. I wouldn't disagree, but if we mean easy to interoperate, let's say so. Word 97-2003 format is totally proprietary, but is now sufficiently widely reverse engineered that it interoperates pretty well. On the other hand, ODF format is well documented and interoperates well among different software that support it, but since old versions of Microsoft Office don't support it, we get complaints. For a production requirement, such as being discussed here, the requirement should only call for use of extremely well-established data representations, where 'extremely well-established' means highly stable and massively widespread for a significant number of years. We expect our own use to be for many years and adopting something that is still in the flush of transition is extremely unwise. Equally, the extent to which we worry about archaic software is relevant, but can be marginal for specific cases. The world being imperfect, interoperability will never be perfect. So we have to look at the degree of it that exists and decide whether it is enough. For example, do we want to worry about packages that are perhaps more than 15 years old and don't support a particular representation? Is there enough use of such old software to be a real concern? Enough is, of course, the critical word. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
--On Saturday, November 26, 2011 19:23 + John Levine jo...@iecc.com wrote: FWIW, I think that, if we are going to start banning proprietary formats, it makes lots more sense to ban _all_ proprietary formats, not just picking and choosing among proprietary formats that are, e.g., more recent or less frequently reverse-engineered than others. So, yes, let's ban pptx, docx, ppt, doc, non-standardized forms of PDF, GIF, ... I gather that you consider ECMA-376 and ISO/IEC 29500 formats to be proprietary. On the other hand, the definition of GIF is in a 20 year old document published by a predecessor of AOL, which includes a widely ignored trademark license requirement and an infamous patent. Hmmn. Indeed. If you reread what I wrote, I was not suggesting permitting GIF (for the reasons you identify-- the thing is proprietary no matter how often reverse-engineered and abused. As far as ECMA-378 and ISO/IEC 29500 are concerned, the process by which those standards were created was itself, in your words, infamous. But, if taken seriously, they permit docx and _not_ .doc. That is precisely where my be careful what you wish for comment originated. PS: I'm not denying that docx and pptx can be unpleasant to deal with, although LibreOffice hides a lot of the unpleasantness. And anyone who uses those formats a lot from Office and is either unlucky or knows what to look for, could, the last I checked, rather easily create documents with which LibreOffice will not cope effectively. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: discouraged by .docx was Re: Plagued by PPTX again
That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8. That wouldn't bother me much, but be careful what you wish form. What we have been told is that the rationale behind the use of ASCII and several other formats is that they will remain readable on devices that will be used X years hence. ASCII is already unreadable on many popular devices and in a few years will be no better than old versions of word. I am referring to the fact that more and more people are reading documents on cell-phones and other small devices. According to analysts, this will be the most popular platform for reading material from the Internet within a few years. The ASCII art used in RFCs becomes hopelessly mangled and unreadable, while the rest of the text is merely hard to read. On the other hand, were the figures to be in any format that preserves their integrity, one would see a small depiction that could be enlarged as necessary. So I suggest removing ASCII from the list, as ASCII art will not be readable on mainstream devices in the near future. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On Sat, Nov 26, 2011 at 08:52:20PM +, Yaakov Stein wrote: ASCII is already unreadable on many popular devices and in a few years will be no better than old versions of word. I am referring to the fact that more and more people are reading documents on cell-phones and other small devices. According to analysts, this will be the most popular platform for reading material from the Internet within a few years. The ASCII art used in RFCs becomes hopelessly mangled and unreadable, while the rest of the text is merely hard to read. On the other hand, were the figures to be in any format that preserves their integrity, one would see a small depiction that could be enlarged as necessary. If you can pan and scan a complex PDF file, you can pan and scan ASCII art. Furthermore, ASCII text has the benefit that you can much more easily reflow the text portions of the document. If I only had a small screen device, and I had my choice between an unreflowable PDF file, and a sufficiently smart ASCII reader that would allow me to switch back and forth between reflowed ASCII text, and a pan and scan mode for ASCII art, the ASCII document would be ***far*** more readable on a small screen than the aforementioned PDF document. - Ted So I suggest removing ASCII from the list, as ASCII art will not be readable on mainstream devices in the near future. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: discouraged by .docx was Re: Plagued by PPTX again
On Sat, Nov 26, 2011 at 15:52, Yaakov Stein yaako...@rad.com wrote: ASCII is already unreadable on many popular devices Oh? For what reason? Sorry, I'm still using an incredibly stupid phone, so I may be behind the curve on such changes. As far as I've seen in my limited exposure, any difficulty is usually because it's often not linewrapped well (or at all), forcing a lot of horizontal scrolling, especially after being forced to be big enough to be legible on tiny screens not held right up to the face. That's rather inconvenient, but still a far cry from unreadable -- plus it's a problem with the reader program (being too featureless to rewrap the text), not anything inherent in the format. ASCII *artwork*, yes, that often gets ruined by the refusal of many programs to allow the user to display content in a monospaced font. But that's not because it's in plain ASCII; you could say the same thing of a Word or PDF document that incorporates ASCII art. I am referring to the fact that more and more people are reading documents on cell-phones and other small devices. According to analysts, this will be the most popular platform for reading material from the Internet within a few years. But among what audience? End-users at large, yes, I can certainly believe that. But techies, especially of sufficient caliber to even *want* to read the IETF's output, let alone participate in creating it? Very doubtful. I don't think we'll be giving up our laptops, never mind large monitors, any time soon. Phones and tablets are for content *consumption*. We are content *creators*, be it programs, documents, or whatever. That's an entirely different set of hardware requirements. When was the last time you saw a program or document or anything else of significant size, written using a phone, or even a tablet? -Dave -- LOOKING FOR WORK! What: Ruby (on/off Rails), Python, other modern languages. Where: Northern Virginia, Washington DC (near Orange Line), and remote work. See: davearonson.com (main) * codosaur.us (code) * dare2xl.com (excellence). Specialization is for insects. (Heinlein) - Have Pun, Will Babble! (Aronson) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
