> ... and don't get me started on LaTeX.
I am not sure what problems you had with LaTeX, but as someone who has
written thousands of pages using TeX,
I can't imagine anything better for professional document preparation.
On the other hand, the learning curve is relatively steep,
and its full powe
On 2009-7-5, at 16:20, Carsten Bormann wrote:
Would it help to simply call it 1.34 now?
(Then it would be picked up by distributions and packaging services
such as macports, and people could stop installing by hand.)
+1
I maintain the fink package for xml2rfc, and the committers asked me
to
On 6 jul 2009, at 09.01, Yaakov Stein wrote:
... and don't get me started on LaTeX.
I am not sure what problems you had with LaTeX, but as someone who has
written thousands of pages using TeX,
I can't imagine anything better for professional document preparation.
On the other hand, the learni
Hi,
On 2009-7-5, at 16:24, Iljitsch van Beijnum wrote:
My apologies for the subject line. I'm very disappointed that the
silent majority of draft authors isn't speaking up. I can't imagine
that the vast majority of draft authors has absolutely no problems
with XML2RFC. So I'm assuming they've be
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 and even
Lars Eggert wrote:
Hi,
On 2009-7-5, at 16:24, Iljitsch van Beijnum wrote:
My apologies for the subject line. I'm very disappointed that the
silent majority of draft authors isn't speaking up. I can't imagine
that the vast majority of draft authors has absolutely no problems
with XML2RFC. So I'm
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
On Mon Jul 6 08:46:24 2009, Julian Reschke wrote:
Also, we should keep in mind that xml2rfc can refer both to a
specific XML vocabulary, and a set of tools.
The vocabulary is relatively straightforward, and has been extended
by both MTR and others. At some point of time, we may want to work
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
Colin Perkins wrote:
I have no significant problems using xml2rfc, and find it easier to
write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or
Microsoft Word.
+1
... and I am quite happy to use the online compiler.
Stewart
___
Ietf
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 artwork,
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
Iljitsch,
On Sun, 2009-07-05 at 15:24 +0200, Iljitsch van Beijnum wrote:
> My apologies for the subject line. I'm very disappointed that the
> silent majority of draft authors isn't speaking up. I can't imagine
> that the vast majority of draft authors has absolutely no problems
> with XML2R
Shane Kerr wrote:
...
I had my first experience with xml2rfc recently, and I largely agree.
It's easy to totally screw up a document by misplaced XML, xml2rfc
Yes.
doesn't handle non-ASCII very well (important for some names), the error
That's an IETF doc format restriction, not an xml2rfc
I *strongly* support "please don't ever *mandate* it [XML2RFC]".
Although, I'm perfectly happy using the obscure syntax of nroff (when
combined with a set of macros I received from George Swallow about 10-12
years ago). I produced a couple of drafts using xml and decided that
nroff was much easie
On Sun, Jul 05, 2009 at 03:20:20PM +0200, Carsten Bormann wrote:
> To me, 1.34pre3 appears to be exactly as stable as 1.33 (modulo the
> instability inevitably introduced by the 5378 train wreck).
I have actually run into a somewhat cryptic error message (which I was
unable to reproduce on earli
> My apologies for the subject line. I'm very disappointed that the
> silent majority of draft authors isn't speaking up. I can't imagine
> that the vast majority of draft authors has absolutely no problems
> with XML2RFC. So I'm assuming they've been ignoring the thread,
> hopefully the new subjec
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 explanator
Lars> since you asked: I have absolutely no problems with xml2rfc.
I find that xml2rfc takes too much control over the boilerplate and the
references to be a really useful tool. I dropped it after one attempt.
However, many of my colleagues use it, and as a result I've gotten many
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
On Jul 6, 2009, at 15:28, Andrew Sullivan wrote:
I have actually run into a somewhat cryptic error message (which I was
unable to reproduce on earlier releases, but which I was also unable
to reproduce consistently anyway), and I've seen some other reports of
issues with 1.34pre3, so it appears
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
+1!!
Carsten Bormann wrote:
> 1.34pre3 is certainly working for people doing drafts these days.
> 1.33, however, is utterly useless!
>
> Ship it.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Eric Rosen wrote:
Lars> since you asked: I have absolutely no problems with xml2rfc.
I find that xml2rfc takes too much control over the boilerplate and the
references to be a really useful tool.
Given how extensive and strong the support for using it is, your assertion is
demons
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.
http://www.ietf.org/ietf/1id-g
> I can't imagine that the vast majority of draft authors has
> absolutely no problems with XML2RFC.
This author has plenty of problems with xml2rfc. But then, I have
plenty of problems with nroff, despite having used it regularly since
I used it to write my thesis in the 1970s, and with MS Word d
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 f
Yaakov Stein wrote:
>
> > ... and don't get me started on LaTeX.
>
> I am not sure what problems you had with LaTeX, but as someone who has
> written thousands of pages using TeX,
> I can't imagine anything better for professional document preparation.
I bought the TeXbook in 1989 and liked it,
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 roya
Martin Rex wrote:
...
Personally I don't like XML at all, and the IETF should NEVER standardize
on a particular tool, if any, but only on a very restricted subset of
XML tags, if any. (So that tools more mainstream languages can be
produced and used).
...
Could you please elaborate what you me
Julian Reschke wrote:
>
> Martin Rex wrote:
> > ...
> > Personally I don't like XML at all, and the IETF should NEVER standardize
> > on a particular tool, if any, but only on a very restricted subset of
> > XML tags, if any. (So that tools more mainstream languages can be
> > produced and used).
Martin Rex wrote:
Something that is sufficiently simple and clear that you can
read and understand its semantics while knowing little about XML
and that one is able to write a discrete parser in a more mainstream
programming languange and NOT use any weird and incompatibly-revved
XML-libraries.
Marshall Rose wrote:
julian, bill - i thought we were waiting on another revision for
boilerplate changes? is that imminent?
Some changes are upcoming.
One was made by the RFC Editor on July, 1st (moving abstract in front of
the boiler plate).
There was also disagreement on where to move t
Hadriel is right... I quit using xmlmind (never installed on the new
machine) because I should not be focusing on formatting nonsense when I
should be focusing on generating the correct content. Getting the arcane
systax correct always takes me half a day because I am not constantly
writing drafts.
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 Mon, Jul 6, 2009 at 12:18 AM, Lars Eggert wrote:
> since you asked: I have absolutely no problems with xml2rfc.
>
> I used to edit in nroff, which wasn't compatible with my brain, and I used
> Joe's Word template, which works OK, but I prefer something ASCII-based for
> collaborative editing (f
41 matches
Mail list logo
