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
Lets unpack this argument:
In the serious publishing world there are editors who review prose and
nit pick. Therefore all nit picking is evidence of serious publishing
and all criticism comes from 'unpublishable wankers'.
As a matter of record I am a published author, my editors at Addison
--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 Jul 5, 2009, at 05:02, Phillip Hallam-Baker wrote:
On Jun 29, 2009, at 16:22, Phillip Hallam-Baker wrote:
It is not the height of the barrier, it is the perception that
people are making nit-picking objections for the sake of rubbing
people's noses in the fact that they can decide where
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
Paul
It appears that people have forgotten that, when needed for clear artwork, RFCs
can be published in PDF format. This has been done in the past, and can be done
again in the future. If WGs are not doing some work because of fear of not
having it published as an RFC because of the
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
We know this, the problem is that you cannot publish a standards
track document in this format.
Stewart
This is not quite true... at least, it never used to be true. The
restriction is/was that only the .txt version is normative; a .pdf
version is non-normative and intended for
At 6:56 AM -0700 7/6/09, Bob Braden wrote:
This is not quite true... at least, it never used to be true. The restriction
is/was that only the .txt version is normative; a .pdf version is
non-normative and intended for explanatory material.
This is my understanding as well (I can't find an RFC
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
Paul,
Section 2.4 of 2223bis
(www.rfc-editor.org/rfc-editor/instructions2authors.txt) says:
The ASCII plain text version (and its .txt.pdf facsimile) is
always the official specification, and it must adequately and
completely define the technical content.
...
Paul is correct. I-D Submission in quite intentionally less strict.
I have been out of the office and away from email for the last week,
and as a result, I have not fully caught up on this thread. However,
there are some things that seem to need clarification.
Stefan Winter wrote:
Plain ASCII makes work on drafts which
deal with internationalisation very hard. I have just uploaded a draft
with an example second-level domain containing the German small u-Umlaut
[U+00FC] as input to an algorithm.
Sorry, in fact
Martin Rex wrote:
Some more thoughts about this:
As long as the IETF want to continue publishing standards in the one
single language English, it should restrict the character sets in
the texts (and the examples) to ASCII.
Text? Yes. Examples? Contact info? No.
non-ASCII letters are a royal
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
To save time, I would suggest adopting the Patent Office rules on
Perpetual Motion. People advocating for a change to facilitate figures
(or to allow complicated math, such as tensor analysis) should have an
existence proof, i.e., a document that requires the change to be
published.
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
At 4:12 PM +0300 7/5/09, Yaakov Stein wrote:
If I remember correctly, draft-ash-alt-formats gave such examples.
G.805 diagrams were needed for some of the PWE and MPLS work,
but could not be put in the desired format.
I personally started writing up a description of a packet loss concealment
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
Hi,
What I hear in these discussions can get translated into a lot of it
would be nice and
little if any it is essential that.
Changes to existing procedures tend to get driven by it is essential
that, which is my point.
A working group saying that
the existing format restrictions are
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
Stefan Winter wrote:
I'll have a go at it (I am not a working group, but I hope you allow me
to express my opinion anyway). Plain ASCII makes work on drafts which
deal with internationalisation very hard. I have just uploaded a draft
with an example second-level domain containing the German
Martin Rex wrote:
Stefan Winter wrote:
I'll have a go at it (I am not a working group, but I hope you allow me
to express my opinion anyway). Plain ASCII makes work on drafts which
deal with internationalisation very hard. I have just uploaded a draft
with an example second-level domain
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 09-07-02 1:00 AM, Randy Presuhn randy_pres...@mindspring.com wrote:
One of the advantages of nroff input is that it *is* human readable. (To me
it seems much easier to read than HTML, but that's not the issue here.)
To generate formatted output (in a variety of possible formats) the
On 2009-07-01 22:38 Martin Rex said the following:
While I participated IETF Meetings in 1995-98, I often used pstools to
create printed copies (2-up) of RFCs and Internet Drafts for reading
while travelling and during meetings (didn't have a laptop).
I used a wrapping perl-script
...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda
Shore
Sent: Thursday, July 02, 2009 02:23
To: Randy Presuhn
Cc: IETF Discussion Mailing List
Subject: Re: More liberal draft formatting standards required
Randy Presuhn wrote:
I don't know. I prefer vi.
You can run nroff
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
to be a step in the wrong
direction.
Y(J)S
-Original Message-
From: Douglas Otis [mailto:do...@mail-abuse.org]
Sent: Thursday, July 02, 2009 08:19
To: alh-i...@tndh.net
Cc: 'Theodore Tso'; Yaakov Stein; 'IETF Discussion Mailing List'
Subject: Re: More liberal draft formatting standards required
Douglas Otis dotis at mail dash abuse dot org wrote:
Word's closed code is continuously changing. Availability of this
closed application depends upon OS compatibility and version
regressions. Both are moving targets. In addition, Word formats
permit inclusion of potentially destructive
Doug Ewell wrote:
Douglas Otis dotis at mail dash abuse dot org wrote:
Word's closed code is continuously changing. Availability of this
closed application depends upon OS compatibility and version
regressions. Both are moving targets. In addition, Word formats
permit inclusion of
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
At 10:19 PM -0700 7/1/09, Douglas Otis wrote:
for wanting more than just plain text documents is to permit
inclusion of charts, graphs, and tables, for a visual society
It seems to me that where this discussion has faltered before is
on whether this is, in fact, a requirement. In the past,
On Jul 2, 2009, at 12:16 PM, Ted Hardie wrote:
At 10:19 PM -0700 7/1/09, Douglas Otis wrote:
for wanting more than just plain text documents is to permit
inclusion of charts, graphs, and tables, for a visual society
It seems to me that where this discussion has faltered before is
on
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 Jul 2, 2009, at 9:22 AM, Marshall Eubanks wrote:
On Jul 2, 2009, at 12:16 PM, Ted Hardie wrote:
At 10:19 PM -0700 7/1/09, Douglas Otis wrote:
for wanting more than just plain text documents is to permit
inclusion of charts, graphs, and tables, for a visual society
It seems to me that
To save time, I would suggest adopting the Patent Office rules on
Perpetual Motion. People advocating for a change to facilitate figures
(or to allow complicated math, such as tensor analysis) should have an
existence proof, i.e., a document that requires the change to be
published. (A
On Jul 2, 2009, at 2:01 PM, Stewart Bryant wrote:
To save time, I would suggest adopting the Patent Office rules on
Perpetual Motion. People advocating for a change to facilitate
figures (or to allow complicated math, such as tensor analysis)
should have an existence proof, i.e., a
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
Hi -
From: Stefan Santesson ste...@aaa-sec.com
To: Donald Eastlake d3e...@gmail.com; IETF Discussion Mailing List
ietf@ietf.org
Sent: Wednesday, July 01, 2009 3:42 PM
Subject: Re: More liberal draft formatting standards required
How do you translate the .nroff formatted document
The TXT versions do not print on my printer and have not printed
reliably on any printer I have ever owned.
I discovered by accident that, on my machine, simply opening a
text version in Microsoft Word gives a document which prints
properly, page breaks and all. (10 point Courier I think.)
Oh and please no more of the thousand years nonsense. If mankind can
decipher Linear-B after three millenia on the basis of two shopping
lists and an op-ed piece then there is never going to be any problem
with PDF or HTML. The idea that we would lose the ability to process
those formats is simply
To respond to the original question.
For what it is worth, I have written a simple and free tool in java for
editing (and viewing) drafts using nroff, which I find a lot easier and
convenient than XML.
It's available from: http://aaa-sec.com/nroffedit/index.html
Source is available upon
On Wed, Jul 01, 2009 at 09:00:48AM +0300, Yaakov Stein wrote:
I would not be surprised if with my next machine I would find it impossible
to print correctly using any of the standard utilities provided,
and that I would be forced to write a program to do so.
The machine after that will
Hallam-
Baker; IETF Discussion Mailing List
Subject: Re: More liberal draft formatting standards required
On Wed, Jul 01, 2009 at 09:00:48AM +0300, Yaakov Stein wrote:
I would not be surprised if with my next machine I would find it
impossible
to print correctly using any of the standard
I just do my drafts in nroff and edit with emacs.
Donald
=
Donald E. Eastlake 3rd
d3e...@gmail.com
On Wed, Jul 1, 2009 at 2:22 AM, Stefan Santessonste...@aaa-sec.com wrote:
To respond to the original question.
For what it is worth, I have written a simple and
Theodore Tso wrote:
On Wed, Jul 01, 2009 at 09:00:48AM +0300, Yaakov Stein wrote:
I would not be surprised if with my next machine I would find it impossible
to print correctly using any of the standard utilities provided,
and that I would be forced to write a program to do so.
The
How do you translate the .nroff formatted document to a readable text
document?
Can emacs do that for you?
/Stefan
On 09-07-01 9:10 PM, Donald Eastlake d3e...@gmail.com wrote:
I just do my drafts in nroff and edit with emacs.
Donald
=
Donald E. Eastlake 3rd
Hi -
From: Stefan Santesson ste...@aaa-sec.com
To: Donald Eastlake d3e...@gmail.com; IETF Discussion Mailing List
ietf@ietf.org
Sent: Wednesday, July 01, 2009 3:42 PM
Subject: Re: More liberal draft formatting standards required
How do you translate the .nroff formatted document
Randy Presuhn wrote:
I don't know. I prefer vi.
You can run nroff on a buffer inside of both vi and emacs
and get the output in another buffer.
I've read internet drafts on a variety of handheld devices,
from the old Sharp Wizards to Palm Pilots to a Blackberry,
and I very much appreciate
Martin Rex wrote:
While I participated IETF Meetings in 1995-98, I often used pstools to
create printed copies (2-up) of RFCs and Internet Drafts for reading
while travelling and during meetings (didn't have a laptop).
I used a wrapping perl-script because it was a little difficult
to cope with
On Jul 1, 2009, at 10:58 AM, Tony Hain wrote:
An alternative would be for some xml expert to fix xml2rfc to parse
through the xml output of Word. If that happened, then the
configuration options described in RFC 3285 would allow for wysiwyg
editing, and I would update 3285 to reflect the
On 29 jun 2009, at 23:32, Andrew Sullivan wrote:
On Mon, Jun 29, 2009 at 01:37:31PM -0700, David Morris wrote:
1000 years from now, it will certainly be easier to recover content
from
an ascii 'file' than an html, xml, or pdf 'file' created now. It is
probably an unjustified assumption that
The TXT versions do not print on my printer and have not printed
reliably on any printer I have ever owned.
I discovered by accident that, on my machine, simply opening a
text version in Microsoft Word gives a document which prints
properly, page breaks and all. (10 point Courier I think.)
1 - 100 of 114 matches
Mail list logo
