On 2 jul 2009, at 10:47, Yaakov Stein wrote:
Due to his diminished eyesight he can't handle the text
of the document he is co-authoring without significant preprocessing.
Ok if we're going to have this discussion again:
PDF is a way to display documents on the screen the same way that
would
On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnum wrote:
> A much better solution would be HTML, if it's sufficiently constrained. HTML
> allows for the reflowing of text, solving issues with text and screen sizes.
> It's also extremely widely implemented, so it's easy to display reasonably
> w
Tim Bray wrote:
On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnum wrote:
A much better solution would be HTML, if it's sufficiently constrained. HTML
allows for the reflowing of text, solving issues with text and screen sizes.
It's also extremely widely implemented, so it's easy to displa
On 2 jul 2009, at 17:05, Stewart Bryant wrote:
A much better solution would be HTML
This seems obviously true everywhere outside the IETF mailing list.
The showstopper has always been with figures which need to do in
separate files. How do you manipulate the collection of files as a
Iljitsch,
That "box" shows up as complete gibberish in a plain-text mail reader
(pine in my case), which sort of proves the point about ASCII. What
you sent was certainly not ASCII.
Ole
Ole J. Jacobsen
Editor and Publisher, The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972 M
Iljitsch van Beijnum wrote:
On 2 jul 2009, at 17:05, Stewart Bryant wrote:
A much better solution would be HTML
This seems obviously true everywhere outside the IETF mailing list.
The showstopper has always been with figures which need to do in
separate files. How do you manipulate th
On 7/2/09 at 4:05 PM +0100, Stewart Bryant wrote:
Tim Bray wrote:
On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van
Beijnum wrote:
A much better solution would be HTML, if it's sufficiently constrained.
Or, gee, we could generalize to a very constrained XML
format.ohwait
I certai
On 3 jul 2009, at 0:35, Pete Resnick wrote:
A much better solution would be HTML, if it's sufficiently
constrained.
Or, gee, we could generalize to a very constrained XML format
XML isn't a display format.
As Dave put it, the current RFC format is "unfriendly, unnecessary,
possibly unet
Iljitsch van Beijnum wrote:
On 3 jul 2009, at 0:35, Pete Resnick wrote:
A much better solution would be HTML, if it's sufficiently
constrained.
Or, gee, we could generalize to a very constrained XML format
XML isn't a display format.
As Dave put it, the current RFC format is "unfriendly,
On 3 jul 2009, at 13:13, Stewart Bryant wrote:
That is an author centric view. It is far more important to take a
reader centric view.
Do we have any objective information on what format produced the
clearest information transfer in the reader.
Well, readers can't read what authors can't
Iljitsch van Beijnum wrote:
On 3 jul 2009, at 13:13, Stewart Bryant wrote:
That is an author centric view. It is far more important to take a
reader centric view.
Do we have any objective information on what format produced the
clearest information transfer in the reader.
Well, readers can
As always when this discussion occurs, there are at least three
different issues swirling around:
1. ASCII-only vs. UTF-8
2. Plain text vs. higher-level formatting, for text flow and
readability
3. Whether it is a good idea to include high-quality pictures in RFCs
There are not the same is
Stewart Bryant wrote:
>
> That is an author centric view. It is far more important to take a
> reader centric view.
I must dissent.
Reader-centric views belong to publishing entities that generate
income (whether by purchase, subscription, or advertising). There have
always been book pub
On 7/3/09 at 10:16 AM +0200, Iljitsch van Beijnum wrote:
On 3 jul 2009, at 0:35, Pete Resnick wrote:
A much better solution would be HTML, if it's sufficiently constrained.
Or, gee, we could generalize to a very constrained XML format
XML isn't a display format.
And how is this responsiv
John Leslie wrote:
Stewart Bryant wrote:
That is an author centric view. It is far more important to take a
reader centric view.
I must dissent.
Reader-centric views belong to publishing entities that generate
income (whether by purchase, subscription, or advertising). There ha
On Jul 3, 2009, at 8:07 AM, Doug Ewell wrote:
As always when this discussion occurs, there are at least three
different issues swirling around:
1. ASCII-only vs. UTF-8
2. Plain text vs. higher-level formatting, for text flow and
readability
3. Whether it is a good idea to include high-
Pete
Getting rid of a page-layout format as our authoritative form is
primary. Using characters that do not occur in English is next down
the list. Everything else is extra.
Surely maximizing the probability of correct understanding
by the reader is primary. Everything else is just a mechanism.
Pete Resnick wrote:
Getting rid of a page-layout format as our authoritative form
is primary. Using characters that do not occur in English is next down
the list. Everything else is extra.
What is primary is to ensure that the revisable form can be easily read 30 years
from now when the
Douglas Otis wrote:
Reliance upon open source tools ensures the original RFCs and ID can
be maintained by others, without confronting unresolvable
compatibility issues.
Whether a tool is open source or not has nothing to do with how many
people know how to use it. Are you talking about mai
> Last but not least, just filter out anything between < and > and
> replace a few &xxx; sequences and you're back to plain text. We could
> probably even format RFCs such that if you remove the HTML, you're
> left with the current ASCII format.
You seemed to have missed the point.
Almost a
Yaakov Stein wrote:
You seemed to have missed the point.
Almost all RFCs have ASCII art in them,
and although perhaps not absolutely needed for correct implementation
they are necessary to comprehend the document.
When you improperly break lines these figures are irreversibly corrupted,
and i
On 5 jul 2009, at 15:04, Yaakov Stein wrote:
Last but not least, just filter out anything between < and > and
replace a few &xxx; sequences and you're back to plain text. We could
probably even format RFCs such that if you remove the HTML, you're
left with the current ASCII format.
You seemed
On Sun, Jul 5, 2009 at 6:27 AM, Melinda Shore wrote:
> Right now ascii text is probably the most widely-supported
> display format.
This statement is violently counter-intuitive and shouldn't be
accepted unsupported by evidence.
- ASCII is not usable for the languages of a large majority of the
Tim Bray wrote:
On Sun, Jul 5, 2009 at 6:27 AM, Melinda Shore wrote:
Right now ascii text is probably the most widely-supported
display format.
This statement is violently counter-intuitive and shouldn't be
accepted unsupported by evidence.
- ASCII is not usable for the languages of a large maj
Tim Bray wrote:
Right now ascii text is probably the most widely-supported display
format.
- ASCII is not usable for the languages of a large majority of the
world's population.
I suspect Melinda meant to say "plain text," and wasn't intending to mix
up the "ASCII vs. Unicode" debate with
On Sun, Jul 5, 2009 at 9:05 AM, Melinda Shore wrote:
> You're heading into new territory, here.
No, I disagreed with an unqualified assertion you made using the
extremely well-defined term"ASCII". As others have pointed out,
progress is being impeded by the conflation of a bunch of different
iss
Tim Bray wrote:
I don't think that the second part of your assertion is correct. I'm
not trying to be difficult. I introduce by example the huge number of
mobile devices that handle HTML effortlessly and IETF legacy ASCII not
at all. Also, the large number of standard office printers that p
On Sun, Jul 5, 2009 at 9:02 PM, Doug Ewell wrote:
> Tim Bray wrote:
>
>> I introduce by example the huge number of mobile
>> devices that handle HTML effortlessly and IETF legacy ASCII not at all.
>> Also, the large number of standard office printers that print HTML
>> instantly and correctly at
OK, here is what happens on my netbook using your method.
Original
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Length |R|T| Transport flags | Res |
+-+-+-+-+-+-+-+-+-+-+
On Sun, 2009-07-05, Yaakov Stein wrote:
> OK, here is what happens on my netbook using your method.
> Original
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Type |Length |R|T|
On 6 jul 2009, at 8:53, Yaakov Stein wrote:
OK, here is what happens on my netbook using your method.
What I see :
0 1 2 3 4 5 6 7 8 9 0
1 2 3 4 5 6 7 8 9 0 1 2
3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+
Hm, it's not supposed to break lines between and even
Tim Bray wrote:
On Sun, Jul 5, 2009 at 9:05 AM, Melinda Shore wrote:
You're heading into new territory, here.
No, I disagreed with an unqualified assertion you made using the
extremely well-defined term"ASCII".
Sure, you are. You're implying that there are characters
we want to display that
Melinda Shore wrote:
...
I don't think that the second part of your assertion is correct. I'm
not trying to be difficult. I introduce by example the huge number of
mobile devices that handle HTML effortlessly and IETF legacy ASCII not
at all.
I've never run into a device that can't display
On 6 jul 2009, at 12:08, Melinda Shore wrote:
Plus, there appears to be a certain amount
of whimsy involved with rendering HTML and displays can be
inconsistent, which 1) is one of the complaints about the
current format, and 2) is undesirable for the display of
technical specifications.
I dis
Iljitsch van Beijnum wrote:
...
This is the part that would be easy to fix by adopting a very basic
flavor of HTML. This would give us line wrap and the ability to use
tables, but we'd lose the headers/footers. ASCII art could still be used
...
Headers/footers will work just fine with a HTML
> huge number of mobile devices that handle HTML effortlessly and IETF
> legacy ASCII not at all
HTML is a good presentation format, but as an archival format it seems to
leave a lot to be desired, as the included links always seem to go stale.
Also, I don't think that the notions
Eric Rosen wrote:
huge number of mobile devices that handle HTML effortlessly and IETF
legacy ASCII not at all
HTML is a good presentation format, but as an archival format it seems to
leave a lot to be desired, as the included links always seem to go stale.
...
But that's a problem
On Jul 3, 2009, at 3:16 PM, Doug Ewell wrote:
Douglas Otis wrote:
Reliance upon open source tools ensures the original RFCs and ID
can be maintained by others, without confronting unresolvable
compatibility issues.
Whether a tool is open source or not has nothing to do with how many
p
--On Sunday, July 05, 2009 12:05 -0400 Melinda Shore
wrote:
>...
> You're heading into new territory, here. Right now
> IETF documents are written in English and they're
> displayable on a wider variety of hardware than HTML
> is. As I mentioned in the mail to which you're responding,
> I thi
On 7 jul 2009, at 12:25, John C Klensin wrote:
The questions, or at least a subset of them, are
important. But we never manage to reach consensus, partially I
think because we make different assumptions about what is
important, and that wastes a lot of time.
If we really want to make progress
Iljitsch van Beijnum wrote:
If we really want to make progress here it's not going to happen by
reaching rough consensus after a long discussion, but by a (very)
small group of people getting together and coming up with something
that improves upon the current situation for (pretty much) ever
--On Tuesday, July 07, 2009 12:49 +0200 Iljitsch van Beijnum
wrote:
> If we really want to make progress here it's not going to
> happen by reaching rough consensus after a long discussion,
> but by a (very) small group of people getting together and
> coming up with something that improves upo
On 7 jul 2009, at 22:42, John C Klensin wrote:
The "good" thing is that the current situation leaves so much
to be desired that this should actually be doable.
I do not believe that we can reach agreement on even the last
statement. I think this discussion shows that our starting
assumptions
On Tue, Jul 7, 2009 at 1:42 PM, John C Klensin wrote:
> I do not believe that we can reach agreement on even the last
> statement.
I am afraid that you may be correct. I am flabbergasted that consensus
on the superior usability of HTML over IETF legacy plain-text (all
other related issues aside)
> This is clearly correct but many of us feel that correct display
> in a browser is of higher utility to a greater number of potential
> spec users.
This seems to follow the currently popular "all the world is a browser"
philosophy. I actually prefer plain-text for lots of uses, including email.
--On Tuesday, July 07, 2009 14:12 -0700 Tim Bray
wrote:
>...
>> We draw some comfort from
>> the facts that it does not have to be interpreted by programs
>> for display,
>
> I really hope you didn't mean what that sentence apparently
> says. No file may be displayed without the invention of
Hi,
> You're heading into new territory, here. Right now
> IETF documents are written in English and they're
If you allow a bit of nitpicking here: they cannot be written in all the
labels the English language has to offer, and thus they can only be
written in a *subset* of English. So a devil's
> "Naïve" is a perfectly valid English word. (If your mail reader doesn't
> display this correctly: that's an i with two dots on top instead of one)
> Likewise is "coup d'état" an English word (e with accent). All loan
> words from French, but nontheless English words.
Yes, but in importing such w
--On Tuesday, July 07, 2009 23:01 +0200 Iljitsch van Beijnum
wrote:
>...
> (We have a saying in Dutch: "the soup is never eaten quite as
> hot as it is served" = people are generally more reasonable
> than their intial positions suggest.)
Experience with the recurrence of this particular topic
On Jul 3, 2009, at 08:07, Doug Ewell wrote:
As always when this discussion occurs, there are at least three
different issues swirling around:
1. ASCII-only vs. UTF-8
2. Plain text vs. higher-level formatting, for text flow and
readability
3. Whether it is a good idea to include high-qua
I just *knew* it was a mistake to "Leave this thread for later ..."
On 3 Jul 2009, at 18:04, Pete Resnick wrote:
On 7/3/09 at 10:16 AM +0200, Iljitsch van Beijnum wrote:
On 3 jul 2009, at 0:35, Pete Resnick wrote:
A much better solution would be HTML, if it's sufficiently
constrained.
Or, ge
"Doug Ewell" writes:
> Douglas Otis wrote:
>
>> Reliance upon open source tools ensures the original RFCs and ID can
>> be maintained by others, without confronting unresolvable
>> compatibility issues.
>
> Whether a tool is open source or not has nothing to do with how many
> people know how to
Byung-Hee HWANG wrote:
Already, above, Douglas pointed out for your comments correctly. RFC
format is different from a market share format by the purpose. Do you
have been think about the word "compatibility" and "standard"? Here is
IETF, not a market.. ;;
This thread has been headed down t
On Jul 12, 2009, at 4:42 PM, Doug Ewell wrote:
This thread has been headed down the wrong path from the outset, as
soon as Tony Hain wrote on July 1:
An alternative would be for some xml expert to fix xml2rfc to parse
through the xml output of Word. If that happened, then the
configurati
On 13 jul 2009, at 21:56, Douglas Otis wrote:
Visual Basic would represent a more likely tool, since it is already
supported by the Word application.
Only in some versions. In the latest MacOS version it's not supported.
This makes one wonder whether there could be a better way.
I think a
Douglas Otis wrote:
...
Use of xml2rfc conversions has uncovered some odd quirks. The tool does
not cache bibliographic database selections. Either this works on-line,
or the entire database needs to be local. Not to diminish the service
offered by Carl Malamud, occasional sporadic connecti
Well one approach would be to simply write a spec for using MIME as an
archive format for HTML and associated documents as has been supported
in Internet Explorer for a decade.
MHT is a very simple format that uses IETF standards in a very obvious
way. We could probably get Firefox to add support
Douglas Otis wrote:
... The concern related to the use of the Word input format, which
has changed in 97, 00, 02, 03, 07, and is likely again in 10, remains
that of security. Changes are not always apparent, and even format
documentation can not be relied upon when details related to active
On Jul 13, 2009, at 7:58 PM, Doug Ewell wrote:
Why on Earth would someone use Visual Basic within Word to write a
utility to convert Microsoft Word ***XML*** documents to an IETF-
acceptable format, when there are much better tools for processing
XML?
For a third-party application to inter
Doug Otis wrote:
...
On Jul 13, 2009, at 1:10 PM, Julian Reschke wrote:
The "experimental" version (http://xml.resource.org/experimental.html)
is as stable as predecessor versions; the main reason it hasn't been
released is that the authors (IMHO) expected more boilerplate changes
to occur.
On 14 jul 2009, at 11:20, Doug Otis wrote:
For a third-party application to interpret the changing Word
document format, even in XML form, would require extensive and
ongoing support.
In principle, yes. In practice this would probably not be a huge deal
compared to what needs to happen to
61 matches
Mail list logo
