Subject: Plagued by PPTX again

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Nov 2011 15:24:20 +1300

Please can everybody who doesn't upload PDF to the meeting materials page
at least take care to upload PPT instead of PPTX?

Not everybody has paid the ransom necessary to open PPTX files.

-- 
Regards
   Brian Carpenter

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Nov 2011 04:40:22 +0200

> Not everybody has paid the ransom necessary to open PPTX files.

The latest LibreOffice (and I think also OpenOffice) supports Microsoft XML formats, so the ransom isn't that high.

---

From: David Morris <[email-masked]>
Date: Mon, 14 Nov 2011 18:45:32 -0800 (PST)

> The latest LibreOffice (and I think also OpenOffice) supports Microsoft XML formats, so the ransom isn't that high.

The ransom is in time, etc. to prepare your system to open MS .*x files 
for those of us to refuse to adopt Office 2007 for UI etc.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 Nov 2011 22:01:38 -0500

> at least take care to upload PPT instead of PPTX?

As a chair, I convert PPT and PPTX to PDF first, and always upload the
PDF.  (And I ask participants to send me PDF in the first place.)

Some people prefer to send PPT(X) because they want to do fancy
animations.  I try to discourage that, unless they can really make the
case that the animations make things significantly clearer.  So far,
no one has even tried to convince me.

Barry

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Nov 2011 22:28:12 -0500

>>>>> "Brian" == Brian E Carpenter <Brian> writes:
    Brian> Please can everybody who doesn't upload PDF to the meeting
    Brian> materials page 
    Brian> at least take care to upload PPT instead of PPTX?

    Brian> Not everybody has paid the ransom necessary to open PPTX files.

+1 for me too.

I did convert the ones I are about at:
  http://junk.sandelman.ca/junk/ietf82/

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 14 Nov 2011 20:18:22 -0800

> Brian E Carpenter wrote:
> Please can everybody who doesn't upload PDF to the meeting
> materials page at least take care to upload PPT instead of PPTX?

+1

Michel.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 15 Nov 2011 05:20:23 +0000

> at least take care to upload PPT instead of PPTX?

Noted - we'll ask for PDF next time.

Please do note that the final proceedings will be in PDF format, though.

Ray

---

From: Bob Hinden <[email-masked]>
Date: Tue, 15 Nov 2011 16:26:39 +0800

+1

Bob

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Ray Bellis <[email-masked]>
Date: Tue, 15 Nov 2011 09:55:39 +0000

The Datatracker does officially support PPTX, so I don't believe it's unreasonable to use it.  If you don't like that policy, I'm not sure where you would take that up.

It also hadn't occurred to me that people might actually prefer PPT over the more open PPTX format.

I've also noticed that you can get problems when exporting to PDF using Office for Mac 2008.  It mangles ligatures when you copy&paste the PDF contents into something else.

Ray

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Nov 2011 18:13:54 +0800

> I've also noticed that you can get problems when exporting to PDF using Office for Mac 2008.  It mangles ligatures when you copy&paste the PDF contents into something

Yes… This part is REALLY annoying… 

Wanting to be a good jabber scribe, I try insert the slide titles into the jabber room so that folk can follow along at home….

Cutting and pasting from PDFs exported by Office (including on Windows) gives me things like: "Algorithm*MigraFon*Documents*"

Sure, I can type / retype the slide tutles, but I tpye raelly pooorly...

W

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Nov 2011 13:13:11 +0200

> It also hadn't occurred to me that people might actually prefer PPT over the more open PPTX format.

It may be open, but there are fewer implementations. Yes, Open/Neo/LibreOffice supports it, but those presentations run much slower than equivalent PPT.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Nov 2011 01:11:47 +1300

>> The Datatracker does officially support PPTX, so I don't believe it's unreasonable to use it.  If you don't like that policy, I'm not sure where you would take that up.

I missed the discussion of that change.

>> It also hadn't occurred to me that people might actually prefer PPT over the more open PPTX format.

I haven't fallen for the notion that OOXML is open. I saw too much of
that particular sausage been forced through the ISO sausage machine.
It's just a pragmatic issue for me - PPT was successfully reverse
engineered many years ago.

I will update my OpenOffice to see if it really handles PPTX properly,
when I get a chance.

> Cutting and pasting from PDFs exported by Office (including on Windows) gives me things like: "Algorithm*MigraFon*Documents*"

I don't know the Mac situation, but this isn't an uncommon class of
problem; I see it quite often in random PDF documents. Nothing is perfect.

One approach is to "print" the document via a virtual PostScript printer
to a .ps file and then convert the .ps to .pdf using ghostscript. That usually
seems to produce sane PDF.

> Sure, I can type / retype the slide tutles, but I tpye raelly pooorly...

;-)

   Brian

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Nov 2011 07:46:21 -0500

> The Datatracker does officially support PPTX, so I don't believe it's
> unreasonable to use it.

By "suipport" it, you mean "accept it and convert it to something
else," a meaning of "support" with which I'm unfamiliar.  I'd say
"tolerate".  What's worse is that if you post PPT/X, it gets converted
not to PDF, but to HTML, which I find awkward for slides (it's harder
to download a presentation as a whole in a convenient form).  That's
why I do the PDF conversion up front.

Barry

---

From: Ray Bellis <[email-masked]>
Date: Tue, 15 Nov 2011 13:19:47 +0000

On 15 Nov 2011, at 20:46, Barry Leiba wrote:

> "tolerate".

Well, "support" may have been a little strong - specifically the meeting materials page says:

"You can only upload a presentation file in txt, pdf, doc, or ppt/pptx. System will not accept presentation files in any other format."

> What's worse is that if you post PPT/X, it gets converted

Yes, that _is_ a good reason to convert to PDF up front, ligature problems notwithstanding.

Ray

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 15 Nov 2011 12:14:04 -0500

Should the system reject PPTX files ? If people can't read them, why
are we accepting them ?

Marshall

---

From: todd glassey <[email-masked]>
Date: Tue, 15 Nov 2011 09:23:56 -0800

> Should the system reject PPTX files ? If people can't read them, why

Because the world has evolved since Office v0 was released unlike the IETF.

PPTX is Office 2007 format and there are formal readers and format API's 
for office so that this is a no brainer.

http://www.microsoft.com/download/en/details.aspx?id=6

Todd
>
>
> On Tue, Nov 15, 2011 at 3:26 AM, Bob Hinden<[email-masked]>  wrote:

-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Nov 2011 19:28:54 +0100 (MET)

todd glassey wrote:
> Marshall Eubanks wrote:

I would appreciate if that datatracker simply rejected PPTX on upload.

It is several mangnitudes more efficient to have the uploaded simply
select a different option on save rather than to bother dozens of
consumers with having to spend hours and/or $$ to obtain a computing
environment that is capable of visualizing PPTX.

> http://www.microsoft.com/download/en/details.aspx?id=6

And where is the download URL for an officially *FREE* license
of Microsoft Windows that is a prerequisite for this player?

While I do have OpenOffice on about half of my dozen computing environments,
none of them is sufficiently "new" to process PPTX.  I'm a developer
and need my time for work, rather than constantly wrangling of software
updates of software that I hardly use myself, like OpenOffice.

-Martin

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Nov 2011 19:47:14 +0100

> of Microsoft Windows that is a prerequisite for this player?

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11575

"Free" as in "120 days" and "you can install a PPT viewer" and
you need "a player" for their "virtual hard disk" image format.

While I hate "anything pdf" I fear that this solution only to
"play" PPT(X) would be *much* worse.  Untested simpler idea:

If you accept to get a Google docs account all these horrible
document formats could be stored as Google docs in the cloud
and shared with everybody using a "compatible browser" (as
temporarily defined by Google, not necessarily IE6/7 or FF3).

-Frank

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Nov 2011 18:52:56 +0000

> updates of software that I hardly use myself, like OpenOffice.

I agree.  OOo has only supported pptx for the last 3 years, and you're
right that it's totally unrealistic to expect that everyone upgrade any of
their installations within this sort of time-frame.

Personally, I'm pretty upset that I can't display any of these new-fangled
formats on my VT52.  I put this down to sheer bloody-mindedness on the part
of the IETF.

Nick

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Nov 2011 20:33:36 +0100 (MET)

> you need "a player" for their "virtual hard disk" image format.

You mean free as in
Expires: This image will shutdown and become completely unusable on November 17, 2011.

This is for the 366 MB Windows XP image, the others are 
completely out of question due to their size.

Btw. the Vista and Win7 image are more like 60 days rather than 120 days:

  Note: You may be required to activate the OS as the product
  key has been deactivated. [...] You can activate up to two rearms
  (type slmgr rearm at the command prompt) which will extend the
  trial for another 30 days.

If downloading and running several hundred megabytes is considered
an option, then you will be *MUCH* better of with a Linux Live-CD
like Knoppix 6.7.0 at 700MByte for the CD, which includes LibreOffice 3.3.3
that seems capable of opening PPTX.

But still, that is a lot of work that needs a lot of space, and
while this may work on an x86 or x64 PC or sufficiently powerful
notebook, it may work between hardly to not-at-all for much more
constrained gadgets (tablets) because of cpu type, hdd/sdd/flash
capacity and main memory size.

> "play" PPT(X) would be *much* worse.

No, it would be *MUCH* better.  If you want movies, upload them
to youtube.  Using PDFs for the datatracker is *MUCH* better
(and it is much more likely that it can still be looked
 at in 15 years, whereas support for any particular PPT-Format seems
 to be less than 10 years.)

> Untested simpler idea:

If anything, then the datatracker should automatically convert
any uploaded PPT to PDF itself.  And those that do not like the particular
conversion performed by datatracker would be free to perform
their prefererred conversion to PDF prior to uploading.

-Martin

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 15 Nov 2011 11:35:05 -0800

>>>>> On Tue, 15 Nov 2011 09:23:56 -0800, todd glassey <[email-masked]> said:

tg> PPTX is Office 2007 format and there are formal readers and format
tg> API's for office so that this is a no brainer.

Great.  I do note that .odp is no where on the accepted list that people
have been posting (granted, I'm lazy, so I haven't checked the list
myself).  Can we get the OO suite formats accepted too?  It seems silly
we're allowing .pptx and similar MS branded files, but not accepting
.odp and other files.

OO/Libre has been around far longer than recent 2007 and even older MS
updates, so lets accept them as valid document types as well.  They
certainly work on more platforms that the .ppt and similar formats.

So, IMHO *either* we accept only .pdf or we accept a whole lot more.
Yes, I could go down the road of "ok, then we can use magic point, and
all sorts of other ones too".  Yes, we could...  but they're not nearly
as popular.  But I'd argue .odp is certainly as popular in this crowd,
if not more so, than .ppt.

-- 
Wes Hardaker
SPARTA, Inc.

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Nov 2011 20:40:00 +0100 (MET)

Nick Hilliard wrote:
> Martin Rex wrote:

Correct.  "Upgrading" an installation takes me a full week until it
works as smoothly as the original working environment.  I don't have
more than one week per year available for such waste, and about
10 different productive computing environment, which results in
a useful lifetime of a work environment of 10 years.

> formats on my VT52.  I put this down to sheer bloody-mindedness on the part

It would be a pretty bad idea for the IETF to join the planned obsolescence
choir for computing environments so that any Tablet you buy today will
be unable to visualize stuff that will be uploaded to the IETF datatracker
in late 2014.

-Martin

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Nov 2011 22:00:22 +0100

> Expires: This image will shutdown and become completely unusable

Yes, or rather, EAGAIN on November 18, that should give you the
next 120 days period for XP images.  AFAIK the Vista images are
more flexible...

> This is for the 366 MB Windows XP image

...small caveat, the purpose of this image is to test Web pages
for IE6.  They can ditch it as soon as they realize that this is
in conflict with their own "phase out IE6" policy.  If you happen
to have an unused W2K key you could find W2K images via YouTube.

I'm too lazy to type all "security considerations" for the W2K
image approach, but W2K can install and run a PPT viewer.  FWIW
it can also install and run Adobe Reader 8 as PDF viewer.  Don't
try Adobe Reader 9 with only 256K virtual RAM.

> like Knoppix 6.7.0 at 700MByte for the CD, which includes
> LibreOffice 3.3.3 that seems capable of opening PPTX.

Sure, if you like that better go for it.  I went the opposite way,
I removed LibreOffice from a collection of "portable apps" (for a
definition of portable related to "W2K or XP or better 32bit NT"),
and I uninstalled a free "MS Office Live 10" shipped with my Win 7
box, because simple DOC(X) and PPT(X) viewers are faster and even
can "print as XPS" (if I want to keep the rendered output).

But XPS is unsuited for W2K, therefore I guess it is hopeless for
other platforms including Debian (Knoppix/Ubuntu/...).

>  at in 15 years, whereas support for any particular PPT-Format
>  seems to be less than 10 years.)

Slides are IMO not really "movies", at least not the simple slides
used for IETF presentations.  On YouTube you'd get Flash or some
HTML5 video format, folks unhappy with PPT(X) might not be happier
with this approach.

> any uploaded PPT to PDF itself.

Well, I'd prefer PPT if only PPT and PDF are offered for viewing,
and I'd prefer anything based on W3C XHTML 1.0 without scripts.

-Frank

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Nov 2011 21:18:48 +0000

>>>While I do have OpenOffice on about half of my dozen computing environments,
[...]
> more than one week per year available for such waste.

Ok, so let me get this right: 12 computing environments, all of which are
out of date by at least 3 years, and you can only afford one week every
year for managing updates - which is enough time to update exactly one
installation.  And because of this awkward situation you find yourself in,
you feel that the IETF should hold off supporting a 5 year old file format,
supported by the majority of computers in the world?

Please excuse my naivety.  I'm new around here.

Nick

---

From: Melinda Shore <[email-masked]>
Date: Tue, 15 Nov 2011 12:29:39 -0900

> Please excuse my naivety.  I'm new around here.

That sort of sarcasm has a tendency not to work out in the
longer run.

Anyway, my personal preference (since that's what we're all
asserting) is to use a format supported by a wider variety
of tools, and that appears to be pdf.  But that said, if we
want a soupy format that supports animation and splashy
backgrounds and WYSYWIG editing and all the stuff we've
been conditioned to love, why not go with a something like ODF -
the tools really are free and it's supported on a wider
variety of platforms.  That is to say, it seems possible to
me that OpenOffice may not be the workaround, but rather
the solution.

Melinda

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Nov 2011 05:31:27 +0800

> me that OpenOffice may not be the workaround, but rather

Perhaps folks will write HTML5 apps for all that splashy stuff. :)

/psa

---

From: Robinson Tryon <[email-masked]>
Date: Tue, 15 Nov 2011 17:03:04 -0500

> Please excuse my naivety.  I'm new around here.

I'm not exactly sure of all of the IETF procedures for such things,
but how about coming up with a simple policy about file formats?

Something like this:

-------

In the interest of
1) Facilitating work
2) Making its work available to as wide an audience as possible, and
3) Lowering barriers to participation...

...the IETF tries to the best of its ability to use open file formats
unencumbered by royalties, patents, trade secrets, and other legal or
obfuscation muck that gets in the way of participation by all persons.
Whenever possible, formats are chosen that do not limit access due to
financial ability or physical impairment.

One of the simplest formats of all, plain text, has served the IETF
and other groups for decades. Keeping the simplicity and open nature
of that format in mind, the IETF's League of Extraordinary File
Formatters [or whatever committee you dream up] may choose other file
formats to be used for interchange.

Whenever preparing files to share with others, please consider making
the content in the files available in multiple formats. For now, the
following formats are considered "Generally Regarded As Safe (GRAS)":

- plain text (encoding?)
- PDF (with restrictions)
- HTML (some version, no scripting?)
- JPG, PNG
- Ogg Vorbis
- Ogg Theora
- [ Etc... ]

If you wish to make a document available in a format not in the
current GRAS list, please make a version of that document available in
a GRAS format (marked as a translation). Make sure that the
GRAS-formatted document retains as much of the content and other
information from the original document as possible. If content or
functionality are lost, please document the differences in an
accompanying document "<translated filename>_lost-in-translation.txt"

For example:

  my-lovely-presentation_v1.0.ppt
  my-lovely-presentation_v1.0-translation.pdf
  my-lovely-presentation_v1.0-translation.pdf_lost-in-translation.txt

To make it possible for people to view the GRAS file formats, we have
assembled a list of compatible software for multiple operating
systems:

[ put in a table of free/Free software for each OS here ]

-----

To maximize compatibility, it could be prudent for the IETF to only
choose file formats that are (as Nick mentions above) 5 years old or
older. Of course, there could be exceptions on a case-by-case basis.

Would the creation of some such spec/committee be helpful?

-- Robinson

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Nov 2011 22:13:45 +0000

> That sort of sarcasm has a tendency not to work out in the

no, probably not.  It's just that I've been hearing the same complaint
about unwillingness to upgrade to widely-supported file / display / etc
formats for as long I've been dabbling on the internet.  The complaint lost
its rustic charm a long time ago, if it ever had any.  The world moves on.

The thing is, pptx is very widely supported and has been widely supported
for several years.  And no matter how much we all dislike upgrading our
desktops, I'm finding it really hard to sympathise with people complaining
about a format which is already supported or can trivially be supported by
the 94%-odd of all office/productivity suite installations in the world.
If this is peoples' position, why not revert to ascii7 for everything?  Is
it really _that_ hard to upgrade to OOo 3.x?  Or to install the office-xml
binary shim set for office 2003?

Incidentally, I am not a supporter of free-for-all file format support, but
solely because of posterity support:  the ietf archives will be of interest
to historians one day, and there is no better way to make it difficult to
analyse things than by accepting a multitude of file formats, some of which
change rapidly or have bizarrely different and incompatible implementations
(e.g. odf).

Nick

---

From: Melinda Shore <[email-masked]>
Date: Tue, 15 Nov 2011 13:30:41 -0900

> change rapidly or have bizarrely different and incompatible implementations

Librarian, here.  As a fan of the unusual argument I love the
suggestion that future researchers will have an easier time with
undocumented, proprietary formats, and therefore in the present
day we should all be required to run behemothware so that we can
be able to look at slides loaded with the sort of Features that
Tufte warned us about.  Odd to see an IETF participant arguing
against interoperability, BTW.

Anyway, I remain unconvinced.

Melinda

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2011 17:53:11 -0500

>>>>> "Nick" == Nick Hilliard <[email-masked]> writes:
    Nick> I agree.  OOo has only supported pptx for the last 3 years,
    Nick> and you're right that it's totally unrealistic to expect that
    Nick> everyone upgrade any of 
    Nick> their installations within this sort of time-frame.

So, it's not available on Ubuntu LTS desktop.

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 15 Nov 2011 17:07:02 -0600

On 11/15/2011 04:53 PM, Michael Richardson wrote:
>
>>>>>> "Nick" == Nick Hilliard<[email-masked]>  writes:

Ubuntu 10.04 is the most recent LTS release, and certainly includes 
OpenOffice. It includes version 3.2.0 in fact.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Nov 2011 23:10:47 +0000

> against interoperability, BTW.

That sort of sarcasm has a tendency not to work out in the longer run.

Oh wait, didn't someone else say that already? :-)

In fact, I deleted a paragraph that I had written about accepting multiple
formats and converting everything into a common format, simply because the
IETF does that already with pdf.  Possibly deleting this didn't help the
email context.

My point was merely that no file format is ideal: ascii7 has elegant
simplicity but hobbles presentation format style.  PDF is widely supported,
and I am informed that PDF/A is considered suitable for long-term
preservation (thanks R.P. for pointing this out offline).  However, pdf is
a monstrous bag of horrors internally and forensic historians of the future
will not necessarily love us for it, particularly if they are picking apart
corrupted pdfs with some of the more exotic constructions.  Full
documentation is available for Microsoft doc/docx/ppt/pptx formats,
regardless of your assertion that these are undocumented - and the xml
versions are slightly less godawful than the binary formats.  ODF is
documented badly enough to the extent that incompatible but compliant
versions exist.  Take your pick.

FWIW, my preference would be to accept current common formats on the
datatracker, including pptx/docx/etc, to convert them immediately to some
form of lowest common denominator (e.g. pdf, with all the information loss
that that entails) and then to post the original format for current
consumption, the converted format for posterity, and if possible a text
format version.  But that's more work than the (reasonable) current ietf
position of just publishing PDFs.

Re: Tufte, I often wonder if he doesn't have a feline mass grave in his
back yard for all the stultifyingly awful ppts imposed upon bored audiences
over the years.

Nick

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Nov 2011 01:10:29 +0100 (MET)

> supported by the majority of computers in the world?

What is much more important is that the data formats used by the
IETF will still be fully supported in 15-20 years.  For a new,
and more so a proprietary data format, it takes at least 5 years
to figure out whether it is widely adopted and will be supported
at least 15-20 years into the future.

None of my working environments is actually out of date -- or they
would not be working environments.

Our customers are actually paying a lot of money to get our software
supported on platforms for more than 10 years (2-3 years in development
plus 10 years in full support, and a few more years).

The code that I develop (middleware stuff: gss-api,tls,pkix,cms) is compiled
for a variety of platforms (SunOS 5.8-5.11, AIX 4.3.3-6.1,
HP-UX 11.0-11.31, Linux SLES 7-11, OS/390 10.00-20.00, MS Windows 5.0-6.1,
plus a few that we will discontinue end of 2013, including OSF/1.)

Home and Laptop is 3xWinXP,Linux-32,Linux-64,Win7-64
At work it is XP,XP-64,SunOS,Linux-32,Linux-64,Win7-32

Every data or file format that I can use on only a small subset of
my work environments in a royal PITA to deal with.  PDF is OK,
PPT is bad, PPTX is horrible.

-Martin

---

From: "John Levine" <[email-masked]>
Date: 16 Nov 2011 00:56:27 -0000

>and more so a proprietary data format, ...

I'm confused.  When you say a proprietary data format, I presume you
mean Microsoft's closed and undocumented PPT format, as opposed to
PPTX which is ISO/IEC Standard 29500.  So you're arguing that
everyone should move to the standard PPTX.

Or did you mean something else?

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Nov 2011 14:35:08 +1300

> Or did you mean something else?

John,

You seem to assume that OOXML is a fully defined open standard whereby
anybody can take the ISO/IEC document and implement a fully interoperable
product. From what I know about the technical objections that were raised
and ignored in the ISO/IEC equivalent of Last Call, that may not be the
case. (I don't claim technical expertise in this area, however.)

The same objection wouldn't apply, for example, to PDF/A.

   Brian

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2011 05:03:44 +0200

> environment that is capable of visualizing PPTX.

I agree in principle, but I have just converted a .pptx presentation (with some animations that will be lost) into PDF.

The PPTX was 250K, the PDF is 2MB. 8 times as much. I know that bandwidth is cheap and all, but I really don't like the inefficiency.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 15 Nov 2011 19:09:46 -0800

I think all of you guys are getting a little too serious about this
thing.

Here's my take: even in a 100% Microsoft shop, .pptx is a pain as much
as .xlsx and .docx. And yes, I know about the free
"fileformatconverters.exe", thank you very much. It does not work on my
Microsoft cell phone that does not read .pptx, but does read .ppt.

.pptx is a pain in the arse. I don't care if it's standard, legally
standard, IETF approved, de-facto standard, or anything. Even if one is
using a newer version of PowerPoint, one can "save as" .ppt.

.pptx is just like HTML in a mailing list: just say no.

Michel.

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Nov 2011 06:41:50 +0100 (MET)

> Or did you mean something else?

PPTX is still proprietary.
That things is so insanely huge and complex that hardly
anyone can create an interoperable implementation.

Microsoft regularly failed to created compatible implementations
of their earlier DOC and PPT formats in later Office releases,
so I would actually be surprised if they succeeded for this
monster called ISO/ETC 29500.

-Martin

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 16 Nov 2011 07:47:28 +0000

> 3) Lowering barriers to participation...

Right. We are talking about presentation slides,
not about something that absolutely has to readable years hence.

So the slides need to be in a format that
1) the chairs can display on their computers
2) the great majority of people who may be remotely participating can read on whatever up-to-date device they have
3) is relatively compact so that remote participants can download on-the-fly

Sounds like pptx to me...

and please do NOT consider another XML markup scheme and special IETF tools to create slides !!!

Y(J)S

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Nov 2011 17:31:58 +0100 (MET)

> not about something that absolutely has to readable years hence.

You seem to not understand this:
http://www.ietf.org/about/note-well.html

It definitely *IS* highly important that this information
is readable in 10+ years.

I do know that there are folks whose primary purpose is to produce
pretty slides to impress bigwigs during a short span of attention,
and where it a regular custom that the slides become entirely
useless after the meeting.  In the IETF, however, there is an
important difference with information being published, going
on public record, and becoming an IETF contribution.

-Martin

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 17 Nov 2011 14:06:22 +0000

Martin

Where does the "note well" say that any contribution needs to be readable 10 years hence ?

It says that if you submit/say something that it is under the IPR stipulations,
and it says that the participant is deemed to have accepted rules of practice
including that what is said/submitted may be made public.

It does not say that everything that I say in a session must be transcribed and saved in ASCII, 
and what I present in slides is no different from what I say.

Y(J)S

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 18:32
To: Yaakov Stein
Cc: [email-masked]; [email-masked]
Subject: Re: Plagued by PPTX again

-Martin

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 17 Nov 2011 08:38:40 -0600

Hi, Yaakov,

I'm not the right guy to answer this, but I believe the right guy would 
say that when we are asked for evidence about prior art, it would be 
more helpful if you could actually read the presentations from the 
working group meeting where somebody's invention was discussed by other 
people three years before the data of the "invention".

I'm not defending that POV, only repeating what I believe the answer to be.

Spencer

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 17 Nov 2011 14:54:34 +0000

If we are deposed we may need to deliver up everything we have, as we have it.

We are under no obligation to deliver blue sheets in ASCII readable form
(in fact, I doubt we could reliably read all the email addresses),
or transcribe audio recordings,
or to translate digital presentations into particular formats.

And in any case, were we to be requested to produce a particular format,
the legal types would want a Microsoft format, not xml or ASCII art.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Thursday, November 17, 2011 16:39
To: [email-masked]
Subject: Re: Plagued by PPTX again

Hi, Yaakov,

Spencer

---

From: "t.petch" <[email-masked]>
Date: Sat, 26 Nov 2011 12:11:04 +0100

----- Original Message -----
From: "Michel Py" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>; "John Levine"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 16, 2011 4:09 AM

> .pptx is just like HTML in a mailing list: just say no.

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.

Tom Petch

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Nov 2011 13:43:44 -0500

--On Saturday, November 26, 2011 12:11 +0100 "t.petch"
<[email-masked]> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 26 Nov 2011 11:50:29 -0700

> UTF-8.   That wouldn't bother me much, but be careful what you

HTML is not on that list?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "John Levine" <[email-masked]>
Date: 26 Nov 2011 19:23:24 -0000

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

---

From: Robinson Tryon <[email-masked]>
Date: Sat, 26 Nov 2011 14:26:01 -0500

> ole ASCII when it is archived, I would like to be able to read it

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

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 26 Nov 2011 11:26:28 -0800

> HTML is not on that list?

No doubt it should be, but which version, exactly?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 26 Nov 2011 11:33:35 -0800

On 11/26/2011 11:23 AM, John Levine wrote:
> 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

---

From: "John R. Levine" <[email-masked]>
Date: 26 Nov 2011 14:51:32 -0500

> In this case, we've seen references to /continuing/ interoperability problems 

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, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 26 Nov 2011 12:00:27 -0800

On 11/26/2011 11:51 AM, John R. Levine wrote:
> 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

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Nov 2011 15:28:28 -0500

--On Saturday, November 26, 2011 19:23 +0000 John Levine
<[email-masked]> 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

---

From: Yaakov Stein <[email-masked]>
Date: Sat, 26 Nov 2011 20:52:20 +0000

> 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

---

From: Ted Ts'o <[email-masked]>
Date: Sat, 26 Nov 2011 17:07:09 -0500

On Sat, Nov 26, 2011 at 08:52:20PM +0000, Yaakov Stein wrote:
> 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

---

From: Dave Aronson <[email-masked]>
Date: Sat, 26 Nov 2011 17:10:12 -0500

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

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

---

From: "John Levine" <[email-masked]>
Date: 27 Nov 2011 00:20:31 -0000

>art.

I've been doing some experiments trying to make RFCs and I-D's
readable on my Kindle.  It has native support for some reflowable
formats (AZW and MOBI), and PDF.  Amazon provides conversion software
that turns several other formats into their flavor of MOBI, and a
conversion service in which you e-mail documents to an address
assigned to your Kindle, and they convert them to versions that appear
on your device via a wireless network connection.  You can also plug
it into your PC as a USB disk and copy MOBI, AZW, and PDF files to it.

The conversion service will accept text documents, but the results of
sending an RFC or I-D through it are too painful to read other than in
utter desperation, not just the ASCII art but the scrambled text.

The device renders PDF page images quite well, but since the screen is
so small, the text is too small to read.  There's an option to select
a rectangle and expand it, but the rectangle doesn't cover an entire
line and you have to move it back and forth for every line which is
slow and painful.  You can turn the Kindle sideways, it rescales PDFs
to the width of the screen, and you can use the up and down buttons.
That is large enough to read, although still pretty small.  I would
have to say that PDF support is better than text, but still pretty
poor.  If you have PDFs with a native 4x6 page size, they look great,
but you need to have your document in some other format that can be
reformatted and printed to small page size PDFs.

The conversion service and software handle a reasonable subset of
HTML, so I tried running the XML source for I-Ds through saxon or the
new xml2rfc, and then converting that to a Kindle native format.  That
works well, text nicely reflowed, ASCII art preserved as a block, and
links to other sections and documents even work.  I now use those as
working versions of my I-D's.

I haven't tried other e-readers, but the MOBI format is not unlike
ePub format, so I expect the results would be similar.

This tells me that it would be really nice to have a meta-format
(probably xml2rfc, since it exists, and it's ASCII underneath so under
even the worst scenarios the content is still accessible) that we can
render into formats that work on whatever devices we use to read stuff.

R's,
John

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 27 Nov 2011 08:20:19 +0000

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: [email-masked] [mailto:[email-masked]] 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

-Dave

---

From: Eric Burger <[email-masked]>
Date: Sun, 27 Nov 2011 08:17:45 -0500

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.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 27 Nov 2011 08:20:13 -0800

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.

> size, written using a phone, or even a tablet?

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Nov 2011 13:36:45 -0500

--On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin
<[email-masked]> 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:
> 
> - - 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

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

---

From: Dave Aronson <[email-masked]>
Date: Sun, 27 Nov 2011 13:38:40 -0500

> 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

---

From: Dave Aronson <[email-masked]>
Date: Sun, 27 Nov 2011 13:40:06 -0500

On Sun, Nov 27, 2011 at 08:17, Eric Burger <[email-masked]> 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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 27 Nov 2011 11:20:25 -0800

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

> would not do as well, possibly supplemented by an additional

What would be missing is an indication that only a fixed font must be used.

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 27 Nov 2011 11:26:53 -0800

> 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

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Nov 2011 14:38:15 -0500

--On Sunday, November 27, 2011 11:20 -0800 Marc Petit-Huguenin
<[email-masked]> 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
>>> - - 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.
>> 
> 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" 
>> 

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 27 Nov 2011 11:49:00 -0800

> 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

- -- 
Marc Petit-Huguenin

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 27 Nov 2011 21:17:58 +0100

> just the two of us) to indicate that such a proposal would be

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

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 27 Nov 2011 17:35:33 -0500

.epub   I went over that months ago.  EPUB 3.0 looks very functional. HTML 5
basis with LZW compression. 

http://idpf.org/epub/30

Is this conversation evidence of global warming?  Some of my daffodils and
narcissus are actually blooming here Northern Virginia. I usually thought
that the rants over file formats were a natural IETF springtime discussion. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John
Levine
Sent: Saturday, November 26, 2011 7:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: reading on small devices, was discouraged by .docx

[RS> ] Calibre is your friend. 

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 27 Nov 2011 22:50:37 -0500

On Sat, Nov 26, 2011 at 12:00:27PM -0800, Dave CROCKER wrote:
> 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.

Like, for instance, a page-layout format that depends on the physical
medium (apprently one current on a line printer some time in the
distant past) in order to establish things like word wrapping?

When we start to have a serious discussion about coping with the
IETF's own ridiculous formatting rules (which are not "plain ASCII",
before anyone starts with that self-evidently false line of argument),
then I will have sympathy for arguments that we should start making
rules about what we can accept.  As long as we're so conservative in
what we send that our output is, in its official form, unreadable on
2/3 of the computers I regularly use, I think we should be extremely
liberal in what we accept.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Mon, 28 Nov 2011 05:59:51 +0000

Do we have an official web page listing the timings of the "ASCII text RFC" discussions? It ought to tell us something about the state of the IETF...

-- Christian Huitema

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 28 Nov 2011 09:52:21 +0000

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:[email-masked]] 
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]

- -- 
Marc Petit-Huguenin

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 28 Nov 2011 09:58:19 +0000

> 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

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 28 Nov 2011 10:02:50 +0000

The time interval between ASCII text threads seems to be decreasing over time.

Perhaps when half of the traffic on the discussion list is related to this question
something will finally be done.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Monday, November 28, 2011 08:00
To: Richard Shockey; 'John Levine'; [email-masked]
Cc: [email-masked]
Subject: RE: reading on small devices, was discouraged by .docx

-- Christian Huitema

---

From: Ole Jacobsen <[email-masked]>
Date: Mon, 28 Nov 2011 02:45:09 -0800 (PST)

We, the RSOC, think this might be a good, simple first task for the 
new RFC Series Editor ;-)

ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj
Skype: organdemo

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Nov 2011 09:28:21 -0500

--On Monday, November 28, 2011 02:45 -0800 Ole Jacobsen
<[email-masked]> wrote:

> We, the RSOC, think this might be a good, simple first task
> for the  new RFC Series Editor ;-)

Especially given that, while we left omniscience off the public
requirements list, we expect any RSE appointee to demonstrate it
:-)

I got curious last night and ran a small experiment with a
fairly recent RFC that was published in PDF, as well as ASCII,
form to preserve some slideware.  The published PDF form of that
document simply does not contain sufficient information to
create PDF/A.  An process that tried to create PDF/A from the
PDF of the RFC would fail unless the RFC Editor could supply a
great deal of missing information, presumably by magic or some
similar process (most PDF processors I've encountered don't even
permit that information to be patched in from out-of-band
information, but there are exceptions.  In any event, lots of
work, not a mechanical converstion process.

Probably the original source docs contained the relevant
information (they probably do) but, once the files were
converted to PDF (however that was done), the information was
done and PDF/A creation is not possible without out-of-band
information or magical or supernatural intervention.

I then repeated the experiment with the first RFC in the
archives to be published in PS form (later converted to PDF).
That document, RFC 12, is five pages long.  The first (very
short) page is text, the others are a series of hand-written
drawings.  It does convert to PDF/A.  Interestingly, while the
PS and PDF files on the RFC Editor site are well over a megabyte
in size, the PDF/A (profile 1b) files (I converted both the
original Postscript and the RFC Editor's PDF and got slightly
different results) are about 382 KB in size.

On the other hand, I tried the PDF file out on one of those
small-screen devices and discovered that it preserved the page
format exactly-- by showing pages of the document reduced to
show one page per screen, no scrolling.  The resolution isn't up
to it even if my aging eyes are, so that is no solution either.

   john

>> Perhaps when half of the traffic on the discussion list is
>> related to this question something will finally be done.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Nov 2011 18:07:28 +0100

On 2011-11-26 21:52, Yaakov Stein wrote:
> ...

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Nov 2011 18:12:42 +0100

> 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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 28 Nov 2011 09:15:17 -0800

> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Nov 2011 18:15:25 +0100

On 2011-11-27 17:20, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 28 Nov 2011 09:19:38 -0800

> 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

---

From: Ted Ts'o <[email-masked]>
Date: Mon, 28 Nov 2011 12:21:07 -0500

On Mon, Nov 28, 2011 at 06:12:42PM +0100, Julian Reschke wrote:
> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Nov 2011 18:27:35 +0100

> I've had readers that reflow text just fine --- far better than PDF,

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

---

From: Eric Burger <[email-masked]>
Date: Mon, 28 Nov 2011 12:46:29 -0500

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:

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

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 28 Nov 2011 12:45:30 -0500

Hi,

Obviously, the key evolution is greater competition and market of display 
devices, i.e. lack of a standard perhaps and patent restrictions which 
promotes the propensity to just use HTML and HTML5 with OS file association 
shell launching. This is especially the case since the 2006/2007 EOLAS 
patents for embedded object rendering changed the industry landscape in this 
area. Frivolous or not,  the patents were reaffirmed (Microsoft lost) and 
EOLAS has been very aggressive about it with all major end-user client 
device vendors.

Of course, once upon a time, the devices were limited in their dimensions, 
standards on rendering and most people had  "PCs" where it wasn't an issue 
for publishers of information.  For text/ansi,  the old punch card 80 or 132 
columns carried on to all devices.  Scan Line pitches for FAX machines, 
Displays were well defined and I don't think it has changed even today, but 
then again I am not an expert with it comes to needs of the Asian market. 
What dimensions do they need for norminal viewing of iconic images good for 
the human eye?

Personally, it is still too early to get all nuts about how documents should 
be published with the moving target of small device and its changing display 
rendering technologies. I also think it is unreasonle for people who are now 
with smaller devices on a greater percentage of their time to mandate 
changes to a world that is still using larger or normal standard display 
devices.  If these people have a problem reading on their iPAD or mobile 
device, they should had realize it was not going to be always ergonomically 
pleasant to them.

Sure, the purest can say - "Everyone should use a standard, multiversal (not 
universal) META format and everyone should be using document creation and 
viewing tools."    But thats always the case when someone gets comfortable 
within his own universe. He wants it to be everyone elses universe as well, 
or more appropriately, he believes it is already is!

Just the other day, an old customer came out of the wood works and now 
wanted his old printed manuals to be viewable via his iPAD, so he now 
demanded a PDF we redo the manuals for PDF output.  When told we long 
migrated and converted the old Word Docs to HTML and CHM files, he said "My 
iPAD doesn't support CHM."  Go Figure.

In my view,  we will never eliminate people who will always or mostly use 
text based communications. Not everyone is going to use GUI document 
creations all the time.  For me, it is highly unproductive when over 99% of 
my communications is in text.  I don't need to add a PICTURE and when I do, 
it is done on the basis that everyone else will be able read it - if they 
wanted to  But I am not going to waste time trying to limit or restrict 
dimensions because there might be people who has using smaller devices. 
Thats their problem.

My view.

----- Original Message ----- 
From: "Yaakov Stein" <[email-masked]>
To: "Christian Huitema" <[email-masked]>; "Richard Shockey" 
<[email-masked]>; "'John Levine'" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 28, 2011 5:02 AM
Subject: RE: reading on small devices, was discouraged by .docx

> Do we have an official web page listing the timings of the "ASCII text 
> RFC" discussions? It ought to tell us something about the state of the 
> IETF...
>
> -- Christian Huitema
>
>
>
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Nov 2011 19:08:38 +0100

> 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

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 28 Nov 2011 19:20:52 +0100

Hi,

I just came across this (very long) thread started by Brian's post, and since
(as Robinson Tryon mentioned in a post already) libreoffice can convert
both .ppt and .pptx to .pdf, I've now set up the tools servers to convert
any .ppt and .pptx to .pdf as soon as they see them.

This means that .pdf versions of powerpoint slides in the future should be
available at the tools servers a little while (less than an hour) after upload.
You'll find them linked in to the WG agenda pages, see for instance this page

  http://tools.ietf.org/wg/abfab/agenda

where the abfab-3.pdf and abfab-4.pdf were originally submitted as .pptx

I've set the converter ('unoconv', which uses libreoffice) up to convert to
PDF/A, but the converter doesn't always fully succeed in producing valid PDF/A
(also mentioned by Robinson in one of his posts) -- the result still works fine
in the viewer I've tested, though.

Best regards,

	Henrik

---

From: Theodore Tso <[email-masked]>
Date: Mon, 28 Nov 2011 13:24:23 -0500

> 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 t…

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

---

From: Robinson Tryon <[email-masked]>
Date: Mon, 28 Nov 2011 13:50:54 -0500

> any .ppt and .pptx to .pdf as soon as they see them.

Great!

> in the viewer I've tested, though.

I filed a bug with LibreOffice about the single file that didn't
export as valid PDF/A, and I'm hopeful the underlying problem will be
fixed soon. If you're seeing other files that don't validate as PDF/A,
or that don't export cleanly as PDF at all, feel free to send me
links/notes on the problems. I'd like to see the PDF export be as
smooth and correct as possible.

Thanks,
-- Robinson

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 28 Nov 2011 10:58:13 -0800

Hi -

> From: "John C Klensin" <[email-masked]>
> To: "Ole Jacobsen" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, November 28, 2011 6:28 AM
...
> to it even if my aging eyes are, so that is no solution either.

In a way, this discussion seems akin to complaints that
it's hard to read RFCs when they're punched onto ticker tape.

I think the discussion of ASCII art and tables is a bit of a red
herring - at those dimensions, the key value of artwork, giving
the user an opportunity to absorb both the gestalt and the
details in a single glance, is lost.  Likewise tables, either
shrunk to illegibility or reduced to one-cell-at-a-time scan
for such a display, lose much of their value for organizing
information and revealing patterns.

15 or 20 years ago, I might have been able to use one of those
small-screen devices.  Nowadays - no way.  If things are
displayed large enough to be legible the amount of vertical
scrolling makes reading anything longer than one (short)
sentence painfully slow.

But here's a solution: let's just wait a few more years, and
the folks who are currently so enthusiastic about using
these gizmos to read RFCs will have been compelled
by their own aging eyes to move on to something else.

Randy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Nov 2011 20:04:35 +0100

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

Ok, so it works well except when it does not. Not convinced.

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Nov 2011 14:29:41 -0500

--On Monday, November 28, 2011 18:27 +0100 Julian Reschke
<[email-masked]> 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

---

From: Martin Rex <[email-masked]>
Date: Mon, 28 Nov 2011 20:44:19 +0100 (MET)

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

> be too wide in other format, such as SVG.

Not always, but often.

> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Nov 2011 20:53:52 +0100

> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Nov 2011 21:03:02 +0100

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

> the browser with a scroll bar).

Use a proper browser (-> Firefox), and make sure to do print preview.

> 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

---

From: Ted Ts'o <[email-masked]>
Date: Mon, 28 Nov 2011 15:26:38 -0500

> 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

---

From: "John Levine" <[email-masked]>
Date: 28 Nov 2011 20:36:27 -0000

>which isn't really a problem.

I read I-D's on my Kindle, when I can get the XML so I can turn it
into something legible.  I'd read RFCs on it if there were a
reasonable way to do so.

I'm 57 years old and quite nearsighted, so my near-geezer opinion
is that the option to change the text size and have the text reflow
and still look OK is very useful.

R's,
John

---

From: Dave Aronson <[email-masked]>
Date: Mon, 28 Nov 2011 15:39:47 -0500

On Mon, Nov 28, 2011 at 15:26, Ted Ts'o <[email-masked]> 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

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 28 Nov 2011 21:42:32 +0100

Hi John,

On 2011-11-28 19:40 John C Klensin said the following:
> 
> 
> --On Monday, November 28, 2011 19:20 +0100 Henrik Levkowetz
> <[email-masked]> wrote:
> 
>> ...
>> I've set the converter ('unoconv', which uses libreoffice) up
>> to convert to PDF/A, but the converter doesn't always fully
>> succeed in producing valid PDF/A (also mentioned by Robinson
>> in one of his posts) -- the result still works fine in the
>> viewer I've tested, though.
> 
> Henrik,
> 
> This is wonderful.  Many thanks.
> 
> One small suggestion, partially prompted by my attempts to
> convert PDF and Postscript RFCs to PDF/A: when the converter
> cannot or does not succeed in producing valid PDF/A, could that
> fact be logged in some accessible place?

I would if I could; the problem is that the converter produces a
pdf document without giving any indication that the result won't
validate as PDF/A -- it's only when trying it with one of the online
validators that I get a message that it fails validation.  If at
some point I find a (free) command-line validator, I can however
easily run it on the existing corpus and get the desired information.

> If, at some point in
> the future, we decided to push PDF/A harder, it would be handy
> to know what existing files needed attention and why, rather
> than having to discover that the hard way.

Understood, but right now the only avenue open to me for this is
manual checking with one of the online validators :-(

> Also, mostly out of curiosity, does "unoconv" produce profile 1a
> or profile 1b?

The validator tells me that the files which validate does so against
both A-1a and A-1b, which if I understand things correctly indicate
that it's 1a-compliant, since 1b is a subset of 1a.  This also
matches what libreoffice is supposed to produce.

Best regards,

	Henrik

>     again thanks,

---

From: Martin Rex <[email-masked]>
Date: Mon, 28 Nov 2011 22:09:06 +0100 (MET)

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

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

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

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Nov 2011 10:14:08 +1300

Henrik,

On 2011-11-29 07:20, Henrik Levkowetz wrote:
> Hi,
> 
> I just came across this (very long) thread started by Brian's post, 

I apologise to everybody. I should know better by now than to mention
anything to do with document format on this list.

> and since

Superb. We don't deserve you, Henrik. Thankyou.

   Brian

---

From: Robinson Tryon <[email-masked]>
Date: Mon, 28 Nov 2011 16:19:24 -0500

On Mon, Nov 28, 2011 at 3:42 PM, Henrik Levkowetz <[email-masked]> wrote:
> that it's 1a-compliant, since 1b is a subset of 1a.

For those who like to geek-out on the details:

http://www.pdfa.org/2011/08/improved-pdfa-1b/

Level A conformance is the superset of PDF/A-1b. Over and above the
features offered by level B, level A offers the following features
that are important for providing accessible content....Any
PDF/A-1a-compliant file is also a valid PDF/A-1b file, and all
variants are based on PDF 1.4 (the PDF version that was introduced
with Acrobat 5).

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 28 Nov 2011 22:22:03 +0100

Hi John,

On 2011-11-28 21:50 John C Klensin said the following:
> 
> 
> --On Monday, November 28, 2011 21:42 +0100 Henrik Levkowetz
>>> cannot or does not succeed in producing valid PDF/A, could
>>> that fact be logged in some accessible place?
>>
>> I would if I could; the problem is that the converter produces
>> a pdf document without giving any indication that the result
>> won't validate as PDF/A
> 
> That is what I believe is called "broken".  I hope someone can
> make a problem report.

Yes.  I suspect the authors of the software aren't aware of the
problem.  Robinson Tryon has now filed a ticket with LibreOffice
about it, though; and I've provided him with another sample which
fails validation.

>> -- it's only when trying it with one
>> of the online validators that I get a message that it fails
>> validation.  If at some point I find a (free) command-line
>> validator, I can however easily run it on the existing corpus
>> and get the desired information.
> 
> If the best (or only) way to handle this is via pos-production
> validation, then we can presumably do that at any time... and
> validators will probably get better over time too.  

Ack.

> Suggestion withdrawn. 
> 
> thanks for considering it.

Certainly!

>>> Also, mostly out of curiosity, does "unoconv" produce profile
>>> 1a or profile 1b?
>>
>> The validator tells me that the files which validate does so
>> against both A-1a and A-1b, which if I understand things
>> correctly indicate that it's 1a-compliant, since 1b is a
>> subset of 1a.  This also matches what libreoffice is supposed
>> to produce.
> 
> Yes.  Without going down that rathole, I think (haven't studied
> the issue closely enough to be confident) A-1b would be good
> enough for our purposes so it may be vaguely possible that the
> files actually are 1b-conformant.  Not worth worrying about
> until and unless we are ready to get really serious about this,
> establish specific norms, etc.    I don't see that happening
> really soon despite the recent discussions.

You may be right.

Best regards,

	Henrik

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 28 Nov 2011 16:25:56 -0500

[RS> ]  So should we suspend the discussion until then? :-) Personally I'm
waiting for the iPad 3 with a retina display. :-)  That should be available
sometime in the springtime and we can take up the subject then as we
traditionally do. 

Randy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Nov 2011 22:48:46 +0100

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

>   * reflowing ascii arts makes the information incomprehensible

That's why you need markup so the browser knows what is what.

>     information up to incomprehensibility

That's why you need markup so the browser knows what is what.

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

>     with a fixed-width font by default)

I disagree, but that's another thing HTML allows you to control.

> to make this work on smartphones and pads--so unless one is stuck in

So go ahead, do it. I don't mean to be rude but telling people that it's 
simple doesn't help. Do it.

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

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

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

> Last time I checked, the IETF was about "Engineering".

Yes, but that's not an excuse for being the only org unable to publish 
in a usable format.

> into comments from ISO X.something).

I do that sometimes as well. Eclipse will reformat these, thankfully. 
That being said, I don't believe that's use case we should optimize for. 
Nor is printing, btw. What's important is *reading*, because that's what 
these documents are for.

Best regards, Julian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Nov 2011 11:00:38 +1100

> into something legible.  I'd read RFCs on it if there were a

Apart from the ascii art, the Kindle does reasonably well in landscape
orientation.  Now if there was just some fixed width fonts on the Kindle
the ascii art would also be ok.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 29 Nov 2011 07:25:51 +0000

> 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

---

From: "t.petch" <[email-masked]>
Date: Tue, 29 Nov 2011 09:22:28 +0100

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: "Richard Shockey" <[email-masked]>; "'John Levine'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 28, 2011 6:59 AM

> Do we have an official web page listing the timings of the "ASCII text RFC"
discussions? It ought to tell us something about the state of the IETF...

If you want a change from the topic you mention, I commend to you a thread that
started as "Plagued by PPTX again" and has forked into a number of interesting
strands, among which you will find
- the proprietary PPTX format is not as widely supported amongst IETF users as
its proponents might imagine and the IETF would work better if its proponents
desisted from its use; this problem might be ameliorated by setting tools to
convert it automatically into a more widely supported one
- the proprietary DOCX format is not as widely supported amongst IETF users as
its proponents might imagine and the IETF would work better if its proponents
desisted from its use; this problem has already been recognised to the extent
that tools convert it automatically into a more widely supported format
- modern devices with narrow displays  and poor resolution give users a
presentation problem that it is worth the IETF's while investigating more
closely, a change to media types being one possible outcome

All-in-all, one of the more interesting times to track the IETF list.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Tue, 29 Nov 2011 09:32:11 +0100

----- Original Message -----
From: "Julian Reschke" <[email-masked]>
To: "Yaakov Stein" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; "ietf" <[email-masked]>
Sent: Monday, November 28, 2011 6:07 PM
> If *we* don't get this right, how can we expect anybody else to get it

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 mmmm/...x is not; but
we aren't, which to me points to a lack of success of that particular piece of
technology.

Tom Petch

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Nov 2011 11:27:10 +0100

> You will be aware of the recent threads on apps-discuss about MIME types (of

"Internet Media Types" :-)

> 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

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Nov 2011 13:40:26 -0500

Henrik,

fact be logged in some accessible place?  If, at some point in

    again thanks,
     john

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Nov 2011 15:50:50 -0500

Suggestion withdrawn. 

best,
   john

---

From: [email-masked]
Date: Tue, 29 Nov 2011 09:18:31 -0800 (PST)

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 30 Nov 2011 07:10:51 +0900

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