Subject: More liberal draft formatting standards required

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 28 Jun 2009 18:33:16 +0200

Hi,

XML2RFC isn't working for me.

For instance, We are now required to use boilerplate that the  
"official" version of XML2RFC doesn't recognize so it's necessary to  
use a beta version that is even more undocumented than the regular  
undocumentedness of the "official" version of XML2RFC. Of course such  
things tend to only surface the day of the cutoff.

I used to write drafts by hand sometimes in the past, but this is also  
very hard, because today's tools just don't have any notion of hard  
line endings, let alone with spaces at the beginning of all lines and  
hard page breaks (at places that make no sense in an A4 world, too).

This is getting worse because the checks done on IDs upon submission  
are getting stricter and stricter.

See http://www.educatedguesswork.org/movabletype/archives/2007/11/curse_you_xml2r.html 
  for a long story that I mostly agree with.

As such, I want to see the following:

- the latest boilerplate is published in an easy to copy&paste format
- drafts may omit page breaks
- drafts may omit indentation and hard line breaks
- no requirements for reference formats

Note that this is for drafts in general. If the RFC editor wishes to  
impose stricter formatting rules I can live with that.

Please don't reply with helpful hints on how to work with XML2RFC.  
Even with a perfect XML2RFC I would still be forced to create XML,  
which is something I desperately long to avoid.

---

From: John C Klensin <[email-masked]>
Date: Sun, 28 Jun 2009 18:34:25 -0400

While I use xml2rfc and do so reasonably happily, a few comments 
below...

--On Sunday, June 28, 2009 6:33 PM +0200 Iljitsch van Beijnum 
<[email-masked]> wrote:

> "official" version of XML2RFC doesn't recognize so it's
>...
> I used to write drafts by hand sometimes in the past, but this
> is also very hard, because today's tools just don't have any
> notion of hard line endings, let alone with spaces at the
> beginning of all lines and hard page breaks (at places that
> make no sense in an A4 world, too).

Gee.  I've had few of those problems when I edit with emacs or 
its clones.  I guess that doesn't qualify as "today's tools" in 
your book but, if so, your issue is much broader than xml2rfc.

> This is getting worse because the checks done on IDs upon
> submission are getting stricter and stricter.
>...

Agree that it is a problem if it is not readily available in 
that form.  But the Trustees seem to be too busy creating new 
policies.

> - drafts may omit page breaks

While I've stopped noticing whether the non-requirement is being 
enforced, to my knowledge, page breaks have _never_ been 
required in I-Ds.  The problem is that the Secretariat likes (or 
has been told to) published a page count as part of the I-D 
announcement and that they can't figure out the page count 
without page breaks.  On would think that they could get a good 
approximation by scanning the document counting lines as well as 
looking for page breaks to count, noticing that there are no 
page breaks, and dividing the line count by 56, but, for some 
reason, that has been considered too hard for a decade or so.

> - drafts may omit indentation and hard line breaks

Indentation should not (ever) have been a problem with I-Ds.

Line breaks are because a situation in which some documents have 
them and others interfere with a different set of reading (and 
printing) tools.  Just as you want to be able to say "I want to 
be able to submit drafts without using xml2rfc to format them", 
I want to be able to say "I don't want my drafts to require 
processing through some display formatter before I can read them 
or have a discussion with someone else that includes references 
to "Line M of Paragraph 2 of Section 5.2".   I also note that 
some of us are very dependent of diffs and the like which also 
depend on well-defined lines.  So your soft line break 
requirement is the one that strikes me as completely 
unreasonable.

> - no requirements for reference formats

To the best of my knowledge, this has never been a requirement 
for I-Ds and the posting tools don't check it.  I'd be happier 
if xml2rfc permitted me to write something like:

 <reference anchor="FooBar" status="later" />

and have it generate
   [FooBar] ... to be supplied ...

and/or
 <reference anchor="FooBaz" status="incomplete">
   <t>whatever notes I want to write to myself, potentially with
    embedded cref elements </t>
 </reference>

I'd be happy to have either of the above generate warnings, but 
they should not prevent the document from compiling.  On the 
other hand, I've figured out how to get around that sort of 
thing, so I've never considered it very important.

> Note that this is for drafts in general. If the RFC editor
> wishes to impose stricter formatting rules I can live with
> that.

Good.  Because they certainly will.  Note also that there is a 
potential difference between a working draft that you are 
sharing with friends or a WG and incrementally developing and a 
draft that the IESG is willing to look at or put out for Last 
Call.  Certainly it would be reasonable to subject the latter to 
requirements that more closely resemble the RFC ones than it is 
for the former.

>...

    john

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 29 Jun 2009 16:07:18 +0200

On 29 jun 2009, at 0:34, John C Klensin wrote:

> I've had few of those problems when I edit with emacs or its  
> clones.  I guess that doesn't qualify as "today's tools" in your  
> book but, if so, your issue is much broader than xml2rfc.

There are probably IETF contributors who are younger than emacs.

Although I am reasonably familiar with a couple of old school text  
editors (vi and pico), as far as I am aware those don't handle hard  
line endings transparently, which is the ultimate source of most of  
the problems.

> The problem is that the Secretariat likes (or has been told to)  
> published a page count as part of the I-D announcement and that they  
> can't figure out the page count without page breaks.

They could publish a word count instead. In most areas of writing word  
counts are used to evaluate the length of a text.

> printing) tools.  Just as you want to be able to say "I want to be  
> able to submit drafts without using xml2rfc to format them", I want  
> to be able to say "I don't want my drafts to require processing  
> through some display formatter

It's true that you can't load a text file without hard line breaks in  
a browser and have the browser wrap the lines. However, printing a  
draft or RFC requires processing today as the page break characters no  
longer seem to work these days. With soft line breaks you can easily  
load the text into an editor and print from there.

> before I can read them or have a discussion with someone else that  
> includes references to "Line M of Paragraph 2 of Section 5.2".   I  
> also note that some of us are very dependent of diffs and the like  
> which also depend on well-defined lines.  So your soft line break  
> requirement is the one that strikes me as completely unreasonable.

Well, creating line breaks is not exactly rocket science so it should  
be easy enough to create a tool that breaks lines in a consistent way.  
However, once the lines are broken editing and printing become harder  
so I think the "official" version of a draft should have unbroken lines.

> I'd be happier if xml2rfc permitted me to write something like:

> <reference anchor="FooBar" status="later" />

Yes, this is the problem with XLM2RFC. It's trying to be way too  
smart, usually unsuccessfully. So now I have to remember that I need  
to call an experimental draft "exp", while just typing "experimental"  
would be so much easier. Or it insists that it knows how to create my  
full name from my first and last names, but of course it doesn't know  
that in Dutch a last name on its own starting with "van" has the V  
capitalized ("Van Beijnum") but if there are initials or first names  
it's lower case ("I. van Beijnum"). Life is too short to battle with  
your tools.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 28 Jun 2009 13:45:21 -0400

I remain heartily fed up that the HTML versions of documents that I
know were submitted with XML source are not available, nor is the XML
source.

The TXT versions do not print on my printer and have not printed
reliably on any printer I have ever owned.

I know that some UNIX folk just love to rub the noses of the rest of
us in this dog poop but it gets tiresome. Just because it works for
some people does not mean that it is the best way to do things.

The W3C has worked out how to print professional looking standards in
a format that we can safely assume will be readable for the next
thousand years at least. We will lose the ability to read bits long
before we lose the ability to read HTML, or for that matter reverse
engineer PDF.

On Sun, Jun 28, 2009 at 12:33 PM, Iljitsch van
Beijnum<[email-masked]> wrote:
> For instance, We are now required to use boilerplate that the "official"
> version of XML2RFC doesn't recognize so it's necessary to use a beta version
> that is even more undocumented than the regular undocumentedness of the
> "official" version of XML2RFC. Of course such things tend to only surface
> the day of the cutoff.
>
> I used to write drafts by hand sometimes in the past, but this is also very
> hard, because today's tools just don't have any notion of hard line endings,
> let alone with spaces at the beginning of all lines and hard page breaks (at
> places that make no sense in an A4 world, too).
>
> This is getting worse because the checks done on IDs upon submission are
> getting stricter and stricter.
>
> See
> http://www.educatedguesswork.org/movabletype/archives/2007/11/curse_you_xml2r.html for
> a long story that I mostly agree with.
>
> Note that this is for drafts in general. If the RFC editor wishes to impose
> stricter formatting rules I can live with that.
>
> Please don't reply with helpful hints on how to work with XML2RFC. Even with
> a perfect XML2RFC I would still be forced to create XML, which is something
> I desperately long to avoid.
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Tim Bray <[email-masked]>
Date: Mon, 29 Jun 2009 11:56:58 -0700

> reliably on any printer I have ever owned.

Yes, and that history goes back a couple of decades for me.

> some people does not mean that it is the best way to do things.

Hey, I'm as Unix-y a person as there is, and simultaneously as fierce
a despiser as you can find of 80-character 66-line hard-to-read
impossible-to-print ignores-decades-of-advances-in-publishing-tech
i18n-oblivious ASCIIlicious IETF worst practices.

Another data point, by the way.  I am a major consumer of the Internet
through a mobile device (an Android phone in my case, but whatever).
RFCs are essentially unusable on this device in the legacy text
format, but work fine in xml2rfc-generated HTML.

I think that in the big picture, usability on a mobile device is
several times as important as usability on the hypothetical
ASCII-capable line printer that presumably must have once existed
somewhere.

> before we lose the ability to read HTML, or for that matter reverse

Yes, although I wouldn't recommend adopting their publishing system.
Can we please join the current millennium?  I'd be happy to help.

 -Tim

---

From: David Morris <[email-masked]>
Date: Mon, 29 Jun 2009 13:37:31 -0700 (PDT)

> Yes, and that history goes back a couple of decades for me.

Probably says more about ones skills than either the printers one uses or 
ASCII as a document interchange format.

I'm sure reading an RFC on a mobile device is important to the community 
as a whole. Not!

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 'software' available 1000 years 
from now will be able to render today's html, xml, or pdf.

The more tools required to access binary content, the more opportunities 
for access denied. ASCII has the advantage that many programs can provide 
adequate access to data encoded in ASCII. It also has the advantage that 
authors don't feel compelled to create pretty documents which may increse 
the visual appeal but do nothing to enhance the content. On the other 
hand, more advanced formats allow for decent technical drawings and
electronic references to related content.

Striking the right balance between the efficiencies of minimalist 
formatting and the capabilities of richer formatting will be a 
difficult challenge. A primary requirement should be maintaining access in 
the widest possible set of computing environments. The adoption of modern 
technologies is not in and of itself justification for change.

David Morris

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Jun 2009 17:32:40 -0400

> from now will be able to render today's html, xml, or pdf.

I am not sure I agree with this assertion.  In 1000 years, I have
every hope that some versions of PDF will be widely usable; but the
currently prescribed format of electronic versions of RFCs I think is
already obsolete, and will be unreadable in 1000 years.

PDF/A-1 is an ISO standard preferred by the U.S. Library of Congress
for page-oriented textual (or primarily textual) documents "when
layout and visual characteristics are more significant than logical
structure."
(http://www.digitalpreservation.gov/formats/fdd/fdd000125.shtml,
visited 2009-06-29)  One could construct a reasonable argument that in
the case of RFCs, the layout and visual characteristics are _not_ more
siginficant than logical structure.  But under the current publication
regime, they are in fact more significant: we have significant rules
for publication about the exact "page" layout, the number of lines,
the margins, the headers and footers, and even what "character"
(i.e. line-printer character) ends a page.  We have practically no
guidance about the logical structure of documents, except that if the
document is a given number of pages, it needs a table of contents.
Whether the logical structure of the document ought to be of higher
concern in relation to the publication form is a topic argued
elsewhere in this thread.  I want to pay attention to whether PDF will
be usable in 1000 years.

The Library of Congress, and librarians generally, take archival
formats terribly seriously.  There is just about no hope of dislodging
the MARC standard, for instance, even though every librarian I ever
spoke to in my admittedly brief library career granted that MARC is
miserably adapted to relational databases (which hadn't been invented
when MARC was settled upon).  The reason MARC can't be replaced is
because that's the format they picked, and so everything has to work
around it.  Period.  The technology it was invented around was
obsolete before the standard even got widely adopted?  Too bad.  This
is an _archival_ format, and therefore it Will Not Change.  All future
technology will simply be specified to use it.  And it is so
specified: one library automation system I knew of when I last looked
at this (nearly 10 years ago, mind) stored every MARC record in BLOBs,
and just did everything up in the application.  Everyone except the
sales people thought this a miserable hack, but the MARC format was
preserved.  Thus do relational theorists go slowly insane.

If librarians have picked PDF/A-1 as an electronic format that they're
going to use -- particularly, if LC has picked it -- then I have every
confidence that the format will be supported somewhere for roughly as
long as there remain readers on Earth.  I am more concerned, in fact,
about widespread inability to read than I am about librarians stopping
support of some archival format they selected.  They are way more
serious about keeping old archival formats working than the IETF has
even been about making FTP continue to work everywhere.

ASCII, on the other hand, doesn't meet any of the librarians'
criteria, and never did.  It is too restrictive even to deal with
non-American titles in the library catalogue (e.g. books priced in
pounds sterling), never mind to deal with non-English titles.  ASCII
was a bugbear in library automation systems from the very beginning.
Certainly, files of supposedly plain text containing the occasional
control character used to format pages for a specific line printer
that was once attached to some ancient computer system on the Internet
is not an archival format that any responsible librarian would sign up
for.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Jun 2009 15:01:43 -0700

>know were submitted with XML source are not available, nor is the XML

The original thread is about Internet Draft submission, not RFC publication format. The two topics are completely disjoint in the IETF procedures.

--Paul Hoffman, Director
--VPN Consortium

---

From: james woodyatt <[email-masked]>
Date: Mon, 29 Jun 2009 15:26:19 -0700

On Jun 29, 2009, at 15:01, Paul Hoffman wrote:
>
> The original thread is about Internet Draft submission, not RFC  
> publication format. The two topics are completely disjoint in the  
> IETF procedures.

Disagree.  The two topics are intimately related by their functions in  
IETF policy and process.

Internet Drafts are our slushpile.  It the manuscript format required  
by the RFC Editor does not closely match the manuscript format  
required for consideration as an Internet Draft, then we will only be  
making the task of reviewing the slush and preparing manuscripts for  
publication all the more difficult for ourselves.

Do we really want to loosen *only* the I-D submission requirements and  
not the RFC Editor requirements as well?  I don't think so.  We would  
only want to do that because we think we're not getting enough slush  
to review, and we're worried that we might be losing valuable  
contributions because the barrier to submit is too high.

Honestly, is that *really* the problem IETF is facing?

(Note well: I am not expressing an opinion about whether IETF should  
or should not change its archival format.  I'm still forming an  
opinion about that.  This message is about editorial process.)

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 30 Jun 2009 10:43:17 +0200

> already obsolete, and will be unreadable in 1000 years.

My original message was about problems _creating_ a certain format.  
But this is of course related to _reading_ a format.

Don't underestimate how quickly formats go away. Anyone here try to  
open a Wordperfect document recently?

Assuming that in 1000 years people still understand English and can  
still read latin script, it's trivial to decode a plain ASCII file.  
HTML is only slightly more difficult: just remove everything between <  
and > and you have something that's mostly readable. With XML you  
should be able to recover most of the text, but I'm pretty sure in  
1000 years nobody is going to understand what <rfc ipr="trust200902"  
category="exp"> means. Not exactly sure what the insides of a PDF file  
look like, but I'll go on a limb and say that it won't be possible to  
get anything useful out of a PDF file without software that  
understands PDF. I don't think that will be around in 1000 years.  
However, because PDF unambiguously maps to an image it should be  
possible to convert from PDF to other image formats without losing any  
content. (And then a decade or two later run OCR on that to retreive  
the original text...)

So I'd say that if we want to change our archival format a carefully  
documented subset of HTML would probably be a good choice. This is  
easy to display on a variety of screen sizes and prints reasonably  
without effort, can be made to print very well with additional tools.  
It has a lot more structure than flat text so scraping tools could  
potentially be more effective than today's, especially considering  
that old RFCs weren't formatted as rigorously as recent ones.

PDF would be a disaster because it's not compatible with text-only  
displays, not compatible with any scraping tools, can't be viewed  
without non-trivial software and doesn't scale to display size.

> pounds sterling), never mind to deal with non-English titles.

Last time I checked RFCs were free and in English...

Consider this: even if we could use non-latin scripts for author names  
in RFCs, would that be a good idea?

Back to my original problem: although there are tons of modern tools  
that create HTML, they usually create completely unstructured and very  
messy HTML that would be unusable for archiving or pretty much  
anything else. With a modern word processor you can basically create  
an unstructured and unformatted ASCII file without even line and page  
breaks, or create something highly structured that requires conversion  
tools to create something that looks like draft format.

We've really painted ourselves in a corner here.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 30 Jun 2009 09:51:44 +0100

> 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.)
Maybe not a purists' solution, but good enough to allow me to
move on.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 30 Jun 2009 12:38:55 +0200

> reliably on any printer I have ever owned.
just an aside:

the way I've found that works reliably these days for printing I-Ds and 
RFCs is to load them into OpenOffice's editor (oowriter) and use "print" 
from there.

Somehow, OpenOffice managed to understand the formfeed character.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 30 Jun 2009 14:46:51 +0200

On 30 jun 2009, at 12:38, Harald Alvestrand wrote:

> the way I've found that works reliably these days for printing I-Ds  
> and RFCs is to load them into OpenOffice's editor (oowriter) and use  
> "print" from there.

> Somehow, OpenOffice managed to understand the formfeed character.

On the Mac you can still use lpr <file> but unfortunately the  
formfeeds get lost when you do that. Pages also doesn't recognize  
them. But Textedit does if you use format -> wrap to page. However,  
the lines probably don't fit anymore after that, fix this by making  
the document rich text and selecting a 10 point fixed width font.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Jun 2009 09:16:37 -0400

Iljitsch van Beijnum wrote:
> On the Mac you can still use lpr <file> but unfortunately the formfeeds 
> get lost when you do that. 

I use enscript.

Melinda

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 29 Jun 2009 17:36:41 -0400

Please do not insult other people's abilities. The fact that some of
us can find something more fun to do than get a document without
embeded form feeds to print properly does not mean that we are less
expert than you.

If a grad student handed me a paper to review formatted in RFC format
I would hand it straight back and tell him to work out how to use Word
or HTML. Here we have a lot of people wasting cycles over precise
adherence to a formatting standard that is rubbish.

If we are going to accept a crappy TXT format then stop griping about
the details.

There is a particular view that computing and computer expertise is
some kind of exclusive priesthood and that the objective of those
learned in the craft should be to preserve the obscurity and thus the
value of those skills.

It is a shortsighted view. The best way to maximize the value of a
computing skill is to render it obsolete. Cobol programmers make more
than C++ Jockeys who make more than folk who program in modern
languages like Java, C# and C.

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 too ridiculous for words.

On Mon, Jun 29, 2009 at 4:37 PM, David Morris<[email-masked]> wrote:
> I'm sure reading an RFC on a mobile device is important to the community as
> a whole. Not!
>
> 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 'software' available 1000 years from now will be
> able to render today's html, xml, or pdf.
>
> The more tools required to access binary content, the more opportunities for
> access denied. ASCII has the advantage that many programs can provide
> the visual appeal but do nothing to enhance the content. On the other hand,
> more advanced formats allow for decent technical drawings and
> Striking the right balance between the efficiencies of minimalist formatting
> and the capabilities of richer formatting will be a difficult challenge. A
> primary requirement should be maintaining access in the widest possible set
> of computing environments. The adoption of modern technologies is not in and
> of itself justification for change.
>
> David Morris

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 29 Jun 2009 19:22:00 -0400

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 to put the bar.

If this was about really about quality or readability I would be a lot
more sympathetic. But when a draft is rejected because xml2rfc
produces a txt file that is rejected because some nit-picker does not
quite like the exact TXT format then the whole process is bogus.

Just make xml2rfc the default input format and let the secretariat use
the perl script of their choice to produce the output versions.

Just make sure that one of those output versions is HTML.

On Mon, Jun 29, 2009 at 6:26 PM, james woodyatt<[email-masked]> wrote:
>> publication format. The two topics are completely disjoint in the IETF
>> procedures.
>
> Disagree.  The two topics are intimately related by their functions in IETF
> policy and process.
>
> Internet Drafts are our slushpile.  It the manuscript format required by the
> RFC Editor does not closely match the manuscript format required for
> consideration as an Internet Draft, then we will only be making the task of
> reviewing the slush and preparing manuscripts for publication all the more
> difficult for ourselves.
>
> Do we really want to loosen *only* the I-D submission requirements and not
> the RFC Editor requirements as well?  I don't think so.  We would only want
> to do that because we think we're not getting enough slush to review, and
> we're worried that we might be losing valuable contributions because the
> barrier to submit is too high.
>
> (Note well: I am not expressing an opinion about whether IETF should or
> should not change its archival format.  I'm still forming an opinion about
> that.  This message is about editorial process.)
>
>
> --

---

From: james woodyatt <[email-masked]>
Date: Tue, 30 Jun 2009 13:15:31 -0700

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 to put the bar.

In the more traditional publishing milieus of which I'm aware, that  
sort of perception is the shibboleth that separates the serious  
writers from the unpublishable wankers.  Prospective authors who  
express a sense of entitlement to the submission of their manuscripts  
in formats that don't meet the requirements of the editors who review  
them are usually encouraged to start their own publishing outfits and  
see if they can do it all better by themselves.

Occasionally, this encouragement is even delivered without the use of  
coarse language.

We participants are our own acquisitions editors here, of course, so  
the height of the barrier is what we should be thinking about.  It  
makes sense to me that we should be automating the mechanical  
screening of manuscripts coming into the slushpile so that they meet  
the machine-scriptable subset of the requirements of the RFC Editor as  
closely as possible.

Are there any nitpicks the draft submission service enforces that  
aren't really RFC Editor requirements?  What are they?  Let's fix  
those.  What I don't want to see is a lot of drafts start piling up  
without even coming close to meeting the *mechanical* requirements of  
the RFC Editor, much less the more difficult syntax requirements of  
the working natural language we've chosen.  It won't help anyone if we  
allow authors to defer the process of cleaning up the formatting and  
boilerplate of a draft until late enough in the review cycle that  
major reformatting deltas look to the differencing tools like all-new  
content.

> If this was about really about quality or readability I would be a  
> lot more sympathetic. But when a draft is rejected because xml2rfc  
> produces a txt file that is rejected because some nit-picker does  
> not quite like the exact TXT format then the whole process is bogus.

For my part, I haven't any serious complaints about the status quo  
(plenty of unserious ones, but no serious ones).  The process works  
well enough for me-- modulo the limitations imposed by our choice of  
archival format, and my general complaints about the open usability  
issues of XML2RFC on which I mostly agree with EKR, and on which I'm  
no more prepared to do anything about than either he or Iljitsch seems  
to be.

So long as we are not discussing any proposals to *change* the set of  
approved archival formats, I'll continue to be happy-- nay, very  
impressed, actually-- with how well XML2RFC meets our needs, despite  
the its obvious warts.

If we decide to open another discussion about new archival formats,  
then I'll be interested to follow along, but archival formats aren't  
on the table here-- at least, I hope not.

-----
Shorter james: I'm far from convinced that changing the draft  
submission server to be more lenient is the best way to address the  
deficiencies in the software we're using, and I also think that  
opening a new discussion about archival formats will mean unleashing a  
yet another force-ten maelstrom of controversy that I'd prefer to  
observe from a very, very safe distance, i.e. one measured in parsecs.

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 1 Jul 2009 09:00:48 +0300

>Maybe not a purists' solution, but good enough to allow me to

Until about 5 years ago I could open an RFC or ID in a simple text editor
and press print. But I no longer have a "simple" editor on my machine.
The closest I have is Microsoft's "Notepad" which defaults to larger fonts and margins.
It breaks every line into 1 1/2 lines, making the text close to unreadable,
and the printout about 3 times the number of pages.

I use Word sometimes, but I need to do more work.

After forcing the file to be opened in Word,
I have to perform a "select all" and change the font to Courier
and the size to 10. (If I don't change the font to a monospace one
all the artwork is undecipherable.)

Then I have to make the top margin smaller - the default top margin
makes a break just before the footer, so that a print out has every other page
containing only a footer at the top and otherwise blank
(the page break IS understood).

I used to be able to go into page preview mode and fix things up for printing
in a WYSIWYG fashion, but that no longer works in the newer version of Word.

So, the argument that the format we use is future proof is still holding up.
I indeed CAN still print an RFC on my machine, 
but it does take a lot of work.

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 probably not have any languages I know,
and I hope that the IETF will be able to provide (free of charge)
a viewer with printing option.

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 1 Jul 2009 09:08:06 +0300

>those formats is simply too ridiculous for words.

Of course we can still decipher Linear-B - it's in Unicode http://unicode.org/charts/PDF/U10000.pdf .

If it were in ASCII art I am sure that no-one would have been able to figure it out.

Y(J)S

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 01 Jul 2009 08:22:59 +0200

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 request.

/Stefan

On 09-06-28 6:33 PM, "Iljitsch van Beijnum" <[email-masked]> wrote:

> http://www.educatedguesswork.org/movabletype/archives/2007/11/curse_you_xml2r.
> html