- Original Message -
From: Julian Reschke julian.resc...@gmx.de
To: Yaakov Stein yaako...@rad.com
Cc: John C Klensin john-i...@jck.com; ietf ietf@ietf.org
Sent: Monday, November 28, 2011 6:07 PM
On 2011-11-26 21:52, Yaakov Stein wrote:
That leaves ASCII, a few forms of PDF, and RFC
On 2011-11-29 09:32, t.petch wrote:
...
You will be aware of the recent threads on apps-discuss about MIME types (of
...
Internet Media Types :-)
...
which the text/plain you mention is one) which concluded, AFAICS, that there is
no rationale why a (top level) type should or should not
- Original Message -
From: Julian Reschke julian.resc...@gmx.de
To: Yaakov Stein yaako...@rad.com
Cc: John C Klensin john-i...@jck.com; ietf ietf@ietf.org
Sent: Monday, November 28, 2011 6:07 PM
On 2011-11-26 21:52, Yaakov Stein wrote:
That leaves ASCII, a few forms of PDF, and
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
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
That would work too. I added a third URL that returns
text/plain;format=fixed;line-length=72
http://ietf.implementers.org/fixed/rfc5928.txt
That is the worst option for my two devices.
On both devices the line wraps distort the tables beyond recognition.
Y(J)S
On 2011-11-26 21:52, Yaakov Stein wrote:
That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8.
That wouldn't bother me much, but be careful what you wish form.
What we have been told is that the rationale behind the use of ASCII and
several other formats
is that they will
On 2011-11-27 09:20, Yaakov Stein wrote:
Dave
I agree that we are thinking as content creators, and that is the problem.
The requirement is not that we will be able to write a new document in 50 years
in the same format.
The requirement is that we should be able to read the documents written
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/28/2011 01:52 AM, Yaakov Stein wrote:
Marc
I opened the link on two different devices,
to see how the tables rendered.
On one (iPod touch with Safari), it worked reasonably.
The only problem was that the table columns were skewed
due
On 2011-11-27 17:20, Marc Petit-Huguenin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The problem here is that RFC and Internet-Drafts are not plain ASCII. They are
technically in a special format that I would call line-printer ready text
file, and ASCII is the encoding, not the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/28/2011 01:58 AM, Yaakov Stein wrote:
That would work too. I added a third URL that returns
text/plain;format=fixed;line-length=72
http://ietf.implementers.org/fixed/rfc5928.txt
That is the worst option for my two devices.
On both
On Mon, Nov 28, 2011 at 06:12:42PM +0100, Julian Reschke wrote:
What's important is that things that *should* work well on small
displays, such a reflowing prose paragraphs, and re-pagination, do
so. This is where text/plain fails big (and HTML does not).
That's more of an attribute of the
On 2011-11-28 18:21, Ted Ts'o wrote:
On Mon, Nov 28, 2011 at 06:12:42PM +0100, Julian Reschke wrote:
What's important is that things that *should* work well on small
displays, such a reflowing prose paragraphs, and re-pagination, do
so. This is where text/plain fails big (and HTML does not).
Hacking text display applications when HTML was designed for it already and
most RFC's natively generate HTML (xml2rfc), do we really have a problem to
solve?
On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote:
On 2011-11-28 18:21, Ted Ts'o wrote:
On Mon, Nov 28, 2011 at 06:12:42PM +0100,
On 2011-11-28 18:46, Eric Burger wrote:
Hacking text display applications when HTML was designed for it already and
most RFC's natively generate HTML (xml2rfc), do we really have a problem to
solve?
...
If all documents were submitted in xml2rfc format (or something equally
expressive): not
On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote:
It requires a format that does allow reflowing and repagination. HTML does,
PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not).
text/plain is what we use, and that's a problem that'll need to be solved.
In practice,
On 2011-11-28 19:24, Theodore Tso wrote:
On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote:
It requires a format that does allow reflowing and repagination. HTML does,
PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not).
text/plain is what we use, and that's a problem
--On Monday, November 28, 2011 18:27 +0100 Julian Reschke
julian.resc...@gmx.de wrote:
That's more of an attribute of the text reader than any thing
else. I've had readers that reflow text just fine --- far
better than PDF, at any rate.
It requires a format that does allow reflowing and
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.
On 2011-11-28 20:29, John C Klensin wrote:
--On Monday, November 28, 2011 18:27 +0100 Julian Reschke
julian.resc...@gmx.de wrote:
That's more of an attribute of the text reader than any thing
else. I've had readers that reflow text just fine --- far
better than PDF, at any rate.
It
On 2011-11-28 20:44, Martin Rex wrote:
...
The real problem is buggy software for displaying on small displays.
Reflowing ASCII is *no* problem whenever ASCII text is reflowable
at all. It can be done in 1-2 KByte of code. Displaying HTML or XML
But our format currently is not reflowable.
On Mon, Nov 28, 2011 at 09:03:02PM +0100, Julian Reschke wrote:
No, it just shows that our format has been optimized for a use case
which almost nobody cares about anymore.
Perhaps because no one actually reads RFC's on these small devices,
and so we've been trolled by a master into worrying
On Mon, Nov 28, 2011 at 15:26, Ted Ts'o ty...@mit.edu wrote:
plain text works just *fine* on a desktop machines, which is what
implementors of network protocols generally use.
That's what I've been trying to tell them -- but some people love to
engineer so much that they don't know when to
Julian Reschke wrote:
On 2011-11-28 20:44, Martin Rex wrote:
...
The real problem is buggy software for displaying on small displays.
Reflowing ASCII is *no* problem whenever ASCII text is reflowable
at all. It can be done in 1-2 KByte of code. Displaying HTML or XML
But our format
On 2011-11-28 22:09, Martin Rex wrote:
Julian Reschke wrote:
On 2011-11-28 20:44, Martin Rex wrote:
...
The real problem is buggy software for displaying on small displays.
Reflowing ASCII is *no* problem whenever ASCII text is reflowable
at all. It can be done in 1-2 KByte of code.
Perhaps because no one actually reads RFC's on these small devices,
and so we've been trolled by a master into worrying about a use case
which isn't really a problem.
I, for one, regularly (attempt to) read RFCs and other standards on small
devices.
I do this because I have stopped shlepping
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
Naah. We should update the 72-character ASCII limit to 40-characters. Not
only will that work for all of these mobile devices, it will work on a TRS-80,
too.
On Nov 27, 2011, at 3:20 AM, Yaakov Stein wrote:
Dave
I agree that we are thinking as content creators, and that is the problem.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The problem here is that RFC and Internet-Drafts are not plain ASCII. They are
technically in a special format that I would call line-printer ready text
file, and ASCII is the encoding, not the format. What is needed is:
- - A mime-type for
--On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin
petit...@acm.org wrote:
The problem here is that RFC and Internet-Drafts are not plain
ASCII. They are technically in a special format that I would
call line-printer ready text file, and ASCII is the
encoding, not the format.
On Sun, Nov 27, 2011 at 03:20, Yaakov Stein yaako...@rad.com wrote:
The requirement is not that we will be able to write a new document in 50
years in the same format.
The requirement is that we should be able to read the documents written 50
years before.
The problem about ASCII art is
On Sun, Nov 27, 2011 at 08:17, Eric Burger ebur...@standardstrack.com wrote:
Naah. We should update the 72-character ASCII limit to 40-characters. Not
only will that work for all of these mobile devices, it will work on a
TRS-80, too.
But that's still too big for even present-day iPod
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/27/2011 10:36 AM, John C Klensin wrote:
--On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin
petit...@acm.org wrote:
The problem here is that RFC and Internet-Drafts are not plain
ASCII. They are technically in a special
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/27/2011 11:20 AM, Marc Petit-Huguenin wrote:
On 11/27/2011 10:36 AM, John C Klensin wrote:
--On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin
petit...@acm.org wrote:
The problem here is that RFC and Internet-Drafts are not
--On Sunday, November 27, 2011 11:20 -0800 Marc Petit-Huguenin
petit...@acm.org wrote:
On 11/27/2011 10:36 AM, John C Klensin wrote:
--On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin
petit...@acm.org wrote:
The problem here is that RFC and Internet-Drafts are not
plain
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/27/2011 11:38 AM, John C Klensin wrote:
--On Sunday, November 27, 2011 11:20 -0800 Marc Petit-Huguenin
petit...@acm.org wrote:
On 11/27/2011 10:36 AM, John C Klensin wrote:
--On Sunday, November 27, 2011 08:20 -0800 Marc
On 27 November 2011 20:38, John C Klensin john-i...@jck.com wrote:
I'm willing to write up either an extension/update to RFC3676 or
a new subtype if there is enough expression of interest (not
just the two of us) to indicate that such a proposal would be
likely to go somewhere.
As Gmail web
- Original Message -
From: Michel Py mic...@arneill-py.sacramento.ca.us
To: Brian E Carpenter brian.e.carpen...@gmail.com; John Levine
jo...@iecc.com
Cc: ietf@ietf.org
Sent: Wednesday, November 16, 2011 4:09 AM
I think all of you guys are getting a little too serious about this
thing.
--On Saturday, November 26, 2011 12:11 +0100 t.petch
daedu...@btconnect.com wrote:
Could we also say 'No' to .docx, another incomprehensible
format designed to persuade us to take time out, spend money
and upgrade all and sundry?
I notice some ADs/WG chairs using this and while it gets
On 11/26/11 11:43 AM, John C Klensin wrote:
--On Saturday, November 26, 2011 12:11 +0100 t.petch
daedu...@btconnect.com wrote:
Could we also say 'No' to .docx, another incomprehensible
format designed to persuade us to take time out, spend money
and upgrade all and sundry?
I notice
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,
On Sat, Nov 26, 2011 at 6:11 AM, t.petch daedu...@btconnect.com wrote:
I notice some ADs/WG chairs using this and while it gets converted to good
ole ASCII when it is archived, I would like to be able to read it
earlier in the process.
To allow people to read versions of documents throughout
On 11/26/2011 10:50 AM, Peter Saint-Andre wrote:
That leaves ASCII, a few forms of PDF, and RFC 5198-conforming
UTF-8. That wouldn't bother me much, but be careful what you
wish form.
HTML is not on that list?
No doubt it should be, but which version, exactly?
d/
--
Dave Crocker
On 11/26/2011 11:23 AM, John Levine wrote:
I gather that you consider ECMA-376 and ISO/IEC 29500 formats to be
proprietary.
John,
Citing open specs is relevant and probably important, but this being the IETF,
it is always trumped by interoperability concerns.
In this case, we've seen
I gather that you consider ECMA-376 and ISO/IEC 29500 formats to be
proprietary.
In this case, we've seen references to /continuing/ interoperability problems
when trying to use docx.
I wouldn't disagree, but if we mean easy to interoperate, let's say so.
Word 97-2003 format is totally
On 11/26/2011 11:51 AM, John R. Levine wrote:
I gather that you consider ECMA-376 and ISO/IEC 29500 formats to be
proprietary.
In this case, we've seen references to /continuing/ interoperability problems
when trying to use docx.
I wouldn't disagree, but if we mean easy to interoperate,
--On Saturday, November 26, 2011 19:23 + John Levine
jo...@iecc.com wrote:
FWIW, I think that, if we are going to start banning
proprietary formats, it makes lots more sense to ban _all_
proprietary formats, not just picking and choosing among
proprietary formats that are, e.g., more
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
On Sat, Nov 26, 2011 at 08:52:20PM +, Yaakov Stein wrote:
ASCII is already unreadable on many popular devices
and in a few years will be no better than old versions of word.
I am referring to the fact that more and more people are reading
documents on cell-phones and other small
On Sat, Nov 26, 2011 at 15:52, Yaakov Stein yaako...@rad.com wrote:
ASCII is already unreadable on many popular devices
Oh? For what reason? Sorry, I'm still using an incredibly stupid
phone, so I may be behind the curve on such changes. As far as I've
seen in my limited exposure, any
50 matches
Mail list logo
