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
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
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
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
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
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 dotis at mail dash abuse dot org 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
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,
Doug Ewell d...@ewellic.org writes:
Douglas Otis dotis at mail dash abuse dot org 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
Byung-Hee HWANG bh at izb dot knu dot ac dot kr 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
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
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 words
--On Tuesday, July 07, 2009 23:01 +0200 Iljitsch van Beijnum
iljit...@muada.com 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
--On Sunday, July 05, 2009 12:05 -0400 Melinda Shore
melinda.sh...@gmail.com 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
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
Iljitsch van Beijnum iljitsch at muada dot com 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
--On Tuesday, July 07, 2009 12:49 +0200 Iljitsch van Beijnum
iljit...@muada.com 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
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 Klensinjohn-i...@jck.com 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
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.
I
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 pre and
Tim Bray wrote:
On Sun, Jul 5, 2009 at 9:05 AM, Melinda Shoremelinda.sh...@gmail.com wrote:
You're heading into new territory, here.
No, I disagreed with an unqualified assertion you made using the
extremely well-defined termASCII.
Sure, you are. You're implying that there are characters
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
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
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 dotis at mail dash abuse dot org 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
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 all
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
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 Shoremelinda.sh...@gmail.com 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
Tim Bray wrote:
On Sun, Jul 5, 2009 at 6:27 AM, Melinda Shoremelinda.sh...@gmail.com 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
Tim Bray tbray at textuality dot com 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
On Sun, Jul 5, 2009 at 9:05 AM, Melinda Shoremelinda.sh...@gmail.com wrote:
You're heading into new territory, here.
No, I disagreed with an unqualified assertion you made using the
extremely well-defined termASCII. As others have pointed out,
progress is being impeded by the conflation of a
Tim Bray tbray at textuality dot com 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
On Sun, Jul 5, 2009 at 9:02 PM, Doug Ewelld...@ewellic.org wrote:
Tim Bray tbray at textuality dot com 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
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
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
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
Stewart Bryant stbry...@cisco.com 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
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
John Leslie wrote:
Stewart Bryant stbry...@cisco.com 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
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
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
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
Douglas Otis dotis at mail dash abuse dot org 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
On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnumiljit...@muada.com 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
Tim Bray wrote:
On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnumiljit...@muada.com 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
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
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
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
Beijnumiljit...@muada.com wrote:
A much better solution would be HTML, if it's sufficiently constrained.
Or, gee, we could generalize to a very constrained XML
59 matches
Mail list logo
