Subject: Re: More liberal draft formatting standards required

From: Theodore Tso <[email-masked]>
Date: Wed, 1 Jul 2009 09:22:55 -0400

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

There may be specific deficiencies with specific operating systems
that no longer no how to print ASCII documents, in which case IETF
might need to provide (or at least point to) a viewer/editor with a
printing option.  As it stands today there are plenty of simple text
editors that are available for Windows; they aren't provided by the OS
provider, so they're not installed by default, but they certainly
exist --- and, due to the simplicity of the RFC series' archival
format, they certainly would not be hard to provide.

						- Ted

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 1 Jul 2009 10:58:57 -0700

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 xml output process. I realize that is a vendor specific
option, but it happens to be a widely available one.

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Theodore Tso
> Sent: Wednesday, July 01, 2009 6:23 AM
> To: Yaakov Stein
> Cc: Dearlove, Christopher (UK); Iljitsch van Beijnum; Phillip Hallam-
> Baker; IETF Discussion Mailing List
> Subject: Re: More liberal draft formatting standards required
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 1 Jul 2009 15:10:27 -0400

I just do my drafts in nroff and edit with emacs.

Donald
=============================
 Donald E. Eastlake 3rd
 [email-masked]

On Wed, Jul 1, 2009 at 2:22 AM, Stefan Santesson<[email-masked]> wrote:
> 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:
>
>> 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: Martin Rex <[email-masked]>
Date: Wed, 1 Jul 2009 22:38:32 +0200 (MEST)

> format, they certainly would not be hard to provide.

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 some documents (varying page lengths and no page feed
control character, plus occasionally Word-corrupted quote characters).

Maybe the IETF could provide a conversion page on their Web-Server
that can convert RFCs and Internet Drafts on the fly from their
original ASCII-form into page-formatted PDF files, something like
you post an URL in a Form, it gives you back a PDF.

On my office PC, I use the same simple text-editor for reading
RFCs and I-Ds that I use for EMail/C/Perl/shell/config, and I
do appreciate the original ASCII format of IETF documents.

The ASCII format significantly facilitates quoting paragraphs
from the document in Email discussion, and that is particularly
helpful during development/discussion of I-Ds.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 02 Jul 2009 00:42:23 +0200

How do you translate the .nroff formatted document to a readable text
document?

Can emacs do that for you?

/Stefan

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Jul 2009 16:00:56 -0700

Hi -

> From: "Stefan Santesson" <[email-masked]>
> To: "Donald Eastlake" <[email-masked]>; "IETF Discussion Mailing List" <[email-masked]>
> Sent: Wednesday, July 01, 2009 3:42 PM

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 freely-
available groff program works well.

> Can emacs do that for you?

I don't know.  I prefer vi.

Randy

---

From: Melinda Shore <[email-masked]>
Date: Wed, 01 Jul 2009 19:23:09 -0400

> 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 having a lowest-common-denominator
document format.  The only drawback has been the fixed line
length - it can be slightly annoying for text but it renders
ascii graphics completely useless on a narrower screen.  On
balance I think it's a reasonable tradeoff, though.  And
personally, I'm grateful that such a wide variety of tools
can be used to generate conforming drafts - I think that it
helps keep the process just a little more open.

Melinda

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Jul 2009 06:44:05 +0200

Martin Rex wrote:
> ...

The HTML versions generated on tools.ietf.org already have page breaks; 
so you can simply print from the browser to a PDF printer driver.

BR, Julian

---

From: Douglas Otis <[email-masked]>
Date: Wed, 1 Jul 2009 22:19:05 -0700

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 xml output process.  
> I realize that is a vendor specific option, but it happens to be a  
> widely available one.

Reasons for wanting more than just plain text documents is to permit  
inclusion of charts, graphs, and tables, for a visual society.  A safe  
way to provide this type of output using stable open-source code would  
be with roff preprocessors, like eqn, pic, tbl.

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 scripts within highly  
flexible and obfuscating structures.   troff normally outputs .ps and  
is supported by various utilities like X viewers in open source.  Unix  
based OSs like OSX and Linux still support this document format, where  
grohtml can generate HTML output. The disadvantage of using the roff  
approach has been a lack of IETF boilerplate pre-processors.  Merging  
XML structures could be combined with powerful roff presentation  
utilities to generate IETF documents.

In many respects, roff offers simpler and proven stable formats.  The  
present xml2rfc utilities do not offer wysiwyg.   Combining custom pre- 
processors and visualization utilities, the roff suite offers greater  
security, stability and versatility for all OSes and media  
presentations types, along with iterative wysiwyg modes of operation.   
There would be little difference using roff tools from using xml2rfc,  
however the results could show a marked visual improvement.  A desire  
for security might even foster a resurgence in roff tools to leverage  
proven and stable document generation.

Everything old is new again.

-Doug

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 02 Jul 2009 09:26:24 +0200

> available groff program works well.

Yes, and that is what I used for many many years until I got tired of saving
to a temporary files and to use command line in endless iterations until I
got all page breaks and other formatting exactly as I wanted them.

I always wanted a tool where I could have the .nroff version and the text
version in two parallel windows, to immediately see the effect of any
changes in .nroff, hence I wrote my own. Mostly for the fun of it. But the
more I use that feature, the more I learned to like it end depend on it.

/Stefan

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 02 Jul 2009 10:39:36 +0200

> you post an URL in a Form, it gives you back a PDF.

Yes. Something like this already exists, has been available as an online
service since 2005, and was created explicitly to help people print documents:

  http://tools.ietf.org/pdf/

Regards,

	Henrik

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 2 Jul 2009 11:47:27 +0300

Have a look at Dave Mills recent remarks on the NTP list :
https://lists.ntp.org/pipermail/ntpwg/2009-June/001519.html

Due to his diminished eyesight he can't handle the text
of the document he is co-authoring without significant preprocessing.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

Melinda

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 2 Jul 2009 11:01:51 +0200

> 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 appear on paper. Since screen and paper have different  
limitations, that usually entails pretty significant compromises. It's  
also extremely hard to build home grown tools to scrape PDF files.  
Even copy/paste from PDF is a challenge. So making PDF the  
authoritative version (let alone the only version) we create more  
problems than we solve. Exit PDF.

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 well without special tools. It also  
allows for semantic tagging, allowing for easy scraping.

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.

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 2 Jul 2009 12:05:29 +0300

The limitations of ASCII format have been discussed here numerous times.
For example, see the lengthy thread last year on draft-ash-alt-formats (now expired).

Many people have proposed modern approaches that comply with the constraints.
Going back a generation or two to nroff seems to me to be a step in the wrong direction.

Y(J)S

-----Original Message-----
From: Douglas Otis [mailto:[email-masked]] 
Sent: Thursday, July 02, 2009 08:19
To: [email-masked]
Cc: 'Theodore Tso'; Yaakov Stein; 'IETF Discussion Mailing List'
Subject: Re: More liberal draft formatting standards required

-Doug

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 2 Jul 2009 07:08:50 -0600

Douglas Otis <dotis at mail dash abuse dot org> wrote:

> flexible and obfuscating structures...

I didn't hear anyone ask to make evil Word from evil Microsoft the 
standard format for I-Ds and RFCs.  I did hear a suggestion to enhance 
xml2rfc so it can interpret the XML generated by evil Word.  The 
resulting code generated by xml2rfc would presumably have all of the 
evilness purged.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Jul 2009 15:28:46 +0200

> resulting code generated by xml2rfc would presumably have all of the 

Just because xml2rfc happens to use a base XML format doesn't mean it 
can be easily changed to use a different XML vocabulary.

A conversion tool (reading Word, generating xml2rfc XML source) would 
make more sense, IMHO. That being said, I looked at this several years 
ago, and the 2003 Word XML format was a pain to process, and also lacks 
much of the interesting stuff (such as blbliographical information).

BR, Julian

---

From: Tim Bray <[email-masked]>
Date: Thu, 2 Jul 2009 07:46:08 -0700

On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnum<[email-masked]> 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
> well without special tools. It also allows for semantic tagging, allowing
> for easy scraping.

This seems obviously true everywhere outside the IETF mailing list.

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

Yes and no.  Yes, removing markup leaves useful text, but no, it
wouldn't be anything like the line-broken, paginated,
headered-and-footered, legacy text format.  -Tim

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 02 Jul 2009 16:05:55 +0100

> 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 single object?

At least with pdf you know you have the whole thing.

Stewart

---

From: Ted Hardie <[email-masked]>
Date: Thu, 2 Jul 2009 09:16:37 -0700

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, multiple
people have argued that switching to a mode in which understanding
the figures is necessary to understanding the protocol would
be a step away from clarity, searchability, and inclusiveness.
We have agreed to do it in some places in the past, but I
believe there has been no previous rough consensus that it
should be the default.

If we are going to re-run this discussion, can we first check
on the consensus on this requirement?  If we don't agree
here, the chance of this run concluding seems no better than
any of the previous runs at the problem.  The discussion
just fragments into tool use, printer capabilities, and various
distractions.

			regards,
				Ted Hardie

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 2 Jul 2009 12:22:42 -0400

On Jul 2, 2009, at 12:16 PM, Ted Hardie wrote:

> on whether this is, in fact, a requirement.

You are exactly correct, and I can recall several interminable  
discussions of this.

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 document that left the IETF to be published elsewhere  
for this reason would also do.)

Regards
Marshall

> In the past, multiple

Regards
Marshall Eubanks
CEO / AmericaFree.TV

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 2 Jul 2009 18:54:45 +0200

On 2 jul 2009, at 17:05, Stewart Bryant wrote:

>>> A much better solution would be HTML

> separate  files. How do you  manipulate the collection of files as a  
> single object?

Multiple files seems problematic.

However, we can stick with ASCII art even if we adopt HTML.

┏ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━━━━━━━━━━━┯━━━━━━━━━━━┓
    ┃ An influx of a (hopefully limited) set │ of unicode symbols┃
    ┃ could allow for more expressiveness in │ this area.        ┃
     
┗ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━ 
━━━━━━━━━━━┷━━━━━━━━━━━┛

---

From: Ole Jacobsen <[email-masked]>
Date: Thu, 2 Jul 2009 10:12:27 -0700 (PDT)

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   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

On Thu, 2 Jul 2009, Iljitsch van Beijnum wrote:

> >The showstopper has always been with figures which need to do in separate
> >files. How do you  manipulate the collection of files as a single object?
> 
>   ┏━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━┓
>   ┗━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━┛
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Jul 2009 19:33:18 +0200

> However, we can stick with ASCII art even if we adopt HTML.

Indeed. Let's keep these discussions separate.

BR, Julian

---

From: Douglas Otis <[email-masked]>
Date: Thu, 2 Jul 2009 10:58:58 -0700

On Jul 2, 2009, at 9:22 AM, Marshall Eubanks wrote:

>> It seems to me that where this discussion has faltered before is on  
>> whether this is, in fact, a requirement.
>
> 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 document that left the IETF to be  
> published elsewhere for this reason would also do.)

What appears to be missed in these conversations represents a  
dissatisfaction of the generation tools and output quality, which is  
easily shared.  There is good reason to avoid closed source generation  
tools, however the IETF has already employed and permitted the use of  
roff inputs and outputs, which appears to offer a reasonable means to  
satisfy the many requirements already in place.

A suggestion to use Word XML outputs as a means of providing WISIWYG  
operation misses what is currently in place within xml2rfc needed to  
generate tables, state diagrams, and graphs.  Yes, these elements are  
_currently_ contained within existing RFCs,  but  in ASCII form.  Even  
though these elements are structured using ASCII, textual processing  
must still accommodate special handling of these clumsy visual elements.

Although I am not blind, the simple instructions required by roff  
tools should allow those visually impaired a superior means for  
understanding the intent of visual graphics, rather than guessing what  
a series of white-space and characters are attempting to convey within  
diagrams or equations.

In addition, there are currently several RFCs already created using  
roff, as were my first attempts at writing I-Ds.  Due to IETF's  
current level of support for xml2rfc, this mode of input now offers an  
easier means to generate acceptable output.  IMHO, roff tools can  
still offer higher quality output that is more compatible with various  
presentation media than outputs generated from xml2rfc.

Perhaps the IETF may wish to better retain the older roff methods by  
offering better boilerplate and processing support for this currently  
acceptable method for generating I-Ds and RFCs.  A wiki style web-page  
with IETF custom roff pre-preprocessors could facilitate roff inputs  
for the creation of ID and RFC documents.  The availability of roff to  
html output should also make creating previews as a type of iterative  
WISIWYG mode of creation possible.  This would be no different than  
the steps used with xml2rfc.

IIRC, .ps generated from roff tools are still acceptable inputs as  
well, although I expect the current publishing automation is likely to  
balk at output from these older methods.  Too bad though.

-Doug

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 02 Jul 2009 19:01:53 +0100

> for this reason would also do.)
RFC1305 which states

Note: This document consists of an approximate rendering in ASCII of the
PostScript document of the same name. It is provided for convenience and
for use in searches, etc. However, most tables, figures, equations and
captions have not been rendered and the pagination and section headings
are not available.

- Stewart

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 2 Jul 2009 14:15:31 -0400

> captions have not been rendered and the pagination and section  

Yes, I seem to remember this one from before...

However, it was a while ago. You could argue it was one-off. You could  
also argue that if one document out of every
few thousand needs something extra, that should be handled by some  
waiver process. I have an existence proof of the possibility of such  
waivers...

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 severely hindering their work  
would count for a lot here.

Regards
Marshall

Regards
Marshall Eubanks
CEO / AmericaFree.TV

---

From: Pete Resnick <[email-masked]>
Date: Thu, 2 Jul 2009 17:35:18 -0500

On 7/2/09 at 4:05 PM +0100, Stewart Bryant wrote:

>>>A much better solution would be HTML, if it's sufficiently constrained.

Or, gee, we could generalize to a very constrained XML 
format.....oh....wait....

I certainly agree that some text-based markup with reasonable tools 
for folks like Dave Mills (and others) to easily convert to a 
readable (or listenable) format is absolutely essential. As Dave put 
it, the current RFC format is "unfriendly, unnecessary, possibly 
unethical and just plain wrong." I'd remove the "possibly."

>At least with pdf you know you have the whole thing.

We've actually got a standard for that: RFC 2387 and its brethren.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: [email-masked]
Date: Thu, 02 Jul 2009 18:23:16 -0700 (PDT)

> it seems much easier to read than HTML, but that's not the issue here.)

That depends on the HTML. We use a stripped down XHTML format for our
documentation sources that I find far more readable than nroff source. I also
like being able to syntax check early and often - all three of the editors I
routinely use have XML syntax checkers built in.

But I find xml2rfc format even easier to read than either stripped down HTML or
nroff.

Regardless of the format you use, I believe the key is to realize that you
spend more of your time looking at the input file and not the output file, and
it pays not to be a slob. I've gotten XML source for drafts from people who
seem to get this, but I've also gotten stuff that was so awful I really could
not understand how they put up with it.

But the real difference is in the type of markup. When I'm writing I want to
focus on the content, not on presentation details. Stripped down HTML is OK in
this regard, but not nearly as good as a format that focuses on the structural
controls I need, not the presentation details I don't care about. IMO xml2rfc
doesn't go far enough in this regard.

I think the mistake many people make is in worrying about the presentation
details too soon, too often, and too much. In a very real sense that's what the
RFC Editor is *for*.

> available groff program works well.

Um, yeah, and try installing that on some only vaguely UNIXish system it hasn't
been compiled on before. Been there, tried that, ended up using ssh to run it
on a systemm where it was preinstalled.

I've also have issues with variations between different nroff processors and
different versions of macro packages. When xml2rfc became available I converted
everything to it. Vast improvement, never going back.

				Ned

---

From: Stefan Winter <[email-masked]>
Date: Fri, 03 Jul 2009 08:06:14 +0200

Hi,

> would count for a lot here.

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 small u-Umlaut
[U+00FC] as input to an algorithm.

Sorry, in fact the draft did of course *not* contain the umlaut. I had
to escape it with the [U+00FC]. Writing that impairs the readability and
understandability of the example quite a bit since the input on "paper"
is not the same as the actual input. This is, IMHO, "severely hindering"
work.

If merely expressing oneself *about* i18n problems properly is
impossible, I'm not really surprised that internationalisation is
perceived as hard and cumbersome. (It's hard and cumbersome enough
without these restrictions already anyway.) Unicode is there for a while
already and I think switching to any kind of format that supports
international character sets is essential. Pick any format you like, as
long as it allows people to express their problems and solutions without
ugly hacks (read: as long as it supports the full set of Unicode - not
just the first 127 characters).

Greetings,

Stefan Winter

P.S.: "a2ps" never failed on me for producing 2-up, nicely framed and
properly page-breaked printer output.

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 3 Jul 2009 10:16:03 +0200

On 3 jul 2009, at 0:35, Pete Resnick wrote:

>>>> 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 unethical and just plain wrong." I'd remove the "possibly."

Please elaborate; this statement goes far beyond the inconvenience of  
having fixed line and page breaks and the lack of non-7-bit-ASCII  
characters.

I wonder what people think about the need (or lack of need) to have  
graphical images. Having written a book or two, I can tell you that  
getting text right is hard, but this pales in comparison to the  
difficulty of getting images right. Most people, including myself,  
don't have the skills to create decent artwork. The formats are  
infinitely less open (in a variety of senses), so modifying someone  
else's images is extremely difficult unless you happen to use the same  
tools or go to the lowest common denominator = bitmaps. And images are  
of course impossible to use on text-only terminals. On constrained  
devices they're hard to work with because the text doesn't scale.

So I think a good argument could be made that in general, RFCs  
shouldn't have images.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 03 Jul 2009 12:13:58 +0100

> So I think a good argument could be made that in general, RFCs 
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.

Stewart

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 3 Jul 2009 13:18:12 +0200

> clearest information transfer in the reader.

Well, readers can't read what authors can't produce.

Perhaps a good image trumps good text, but I don't think we can assume  
that this is the choice we'll be faced with in general, mediocre image  
vs good text or bad image vs mediocre text seems more likely.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 03 Jul 2009 12:26:15 +0100

> vs good text or bad image vs mediocre text seems more likely.
Images of any quality do not excuse poor text. Producing good text is 
not negotiable and we have mechanisms in place to ensure the quality of 
the text.

However it is our job to produce the most lucid description of the 
specification and I go back to my question, what format is most 
effective for the readers?

Stewart

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Jul 2009 14:57:18 +0200 (MEST)

> is not the same as the actual input. This is, IMHO, "severely hindering"

Good example.  Wrong conclusion.

Specifications that deal with processing of unicode ought to use
literal Unicode codepoints throughout (and not graphical glyphs),
because the Unicode codepoints are the things that end up in code
and need to be correct, whereas the glyphs are hard to read and
extremely ambiguous.

-Martin

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Jul 2009 15:05:44 +0200

> and need to be correct, whereas the glyphs are hard to read and

It depends.

If the non-ASCII code point is part of the protocol: yes.

On the other hand, if the code point appears in an example, illustrating 
how to deal with I18N, no.

BR, Julian

---

From: John Leslie <[email-masked]>
Date: Fri, 3 Jul 2009 12:56:47 -0400

> That is an author centric view. It is far more important to take a 

   I must dissent.

   Reader-centric views belong to publishing entities that generate
income (whether by purchase, subscription, or advertising). There have
always been book publishers that generate reader-centric interpretations
of RFCs.

   It's expensive to do so; and such publishing entities are careful to
evaluate the potential market before producing one.

   IETF publications produce _no_ income; so we need to minimize the
expenses. That leaves us concentrating on the author-centric and
editor-centric views.

   I in no way dispute that other presentations can be "better" for the
reader; I only remind folks that we subsidize IETF publications through
our meeting fees, and other avenues are always available to publish
reader-centric versions.

   For one simple example, I know of nothing preventing citations of
self-published "guides" as Informative References in RFCs.

--
John Leslie <[email-masked]>

---

From: Pete Resnick <[email-masked]>
Date: Fri, 3 Jul 2009 12:04:25 -0500

>XML isn't a display format.

And how is this responsive to what I said?  Applications of XML 
(e.g., XHTML, xml2rfc with associated XSL files) provide perfectly 
good display info that are currently in use by all sorts of display 
platforms.

The choice of a particular markup language is irrelevant to the 
overall issue: We need to have text and semantic markup, instead of 
text with spaces and control characters to do page formatting as our 
canonical format.

>Please elaborate; this statement goes far beyond the inconvenience 
>of having fixed line and page breaks and the lack of non-7-bit-ASCII 
>characters.

You bet it goes further: The current format is a horror to anyone who 
has to "read" the document on anything that does not visually display 
80 columns of fixed-width text. Try "reading" the text on a small 
handheld device. Try doing so with a text-to-speech application. Try 
magnifying it using apps meant for folks with limited vision. We have 
the ability to create text in a format that is easily interpreted by 
all of these devices and presented to the user with no loss of 
information. Using a page-layout format for our standards when page 
layout is completely unnecessary is at a minimum "unfriendly" to 
folks who want to use such devices, and (given that it is unnecessary 
to use page-layout) it is downright unethical and wrong to make it 
harder for folks who must use such devices.

Not being able to use characters in documents outside of the US-ASCII 
set is inconvenient (when they are part of the data stream of a 
protocol you wish to describe) and unfriendly (when the personal 
information about contributors cannot be properly provided). I'll 
leave off unethical there; it's still wrong.

>graphical images.

Images are *way* down the list of needs. Useful in some cases, but 
never necessary. 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.

pr

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 03 Jul 2009 18:13:18 +0100

> self-published "guides" as Informative References in RFCs.
Ah. I thought we wrote RFCs so that others could read them and
translate the content into some locally meaningful combination
of hardware and software.

If that is not the case I wonder why we spend our time writing them?

My overarching point of course is the style of an RFC should be
so as to maximize the probability that the  implementation is
correct, and that the preference  for style should be driven by
that need.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 03 Jul 2009 18:16:00 +0100

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.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 03 Jul 2009 18:16:00 +0100

Pete

Stewart

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Jul 2009 13:49:33 -0400

Dear colleagues,

Before the substantive points of the original post get buried under
counter-arguments against some _other_ point, I just want to make sure
we're all talking about the same things.  There are, in my reading,
two completely different points in Iljitsch's original post:

1.  The recent boilerplate/process-change events have resulted in a
situation where the most-recommended tool for preparing IETF documents
does not work at all in its stable version.  If you want to prepare
IETF documents you have to use a tool explicitly labelled as
bleeding-edge software.  That it works at all is a testament to those
working on the tool, but the facts are that the tool isn't
well-documented at the best of times and that this beta version
produces completely cryptic error messages that wouldn't help most
users unless they are perverse enough to keep their TCL skills sharp.
Some argument in this thread has been about the preparation tools and
whether we are creating needless barriers here.  This point was not
reflected in the original Subject: line, alas, but was an important
component of its argument.

2.  The current format of IETF documents appears to be designed to
accommodate the vagaries of a peculiar historical line printer
arrangement, and it is not flexible enough to be a useful format in
several perfectly normal contexts for readers today.  The formatting
conventions are also basically page-oriented, and in an age when a
large number of readers do not print the documents out on paper that
seems to be a serious missing feature -- particularly when page sizes
are not universal within the community of document producers and
consumers we claim to be trying to serve.  Some argument has been
about the output format and whether it is the right one for the IETF.
This topic has indeed been debated before (and I think those
suggesting that the previous inconclusive results might be relevant to
the discussion have a point).

You could easily think that there's nothing wrong with the current
archival format, and still object to the primary recommended tool
being in the state it is in the period leading up to a -00 deadline
(please note that this is not an attack on the tool makers, but rather
an observation about how the process and the supporting infrastructure
may have diverged); by the same token, you might think xml2rfc is the
bees' knees and have managed to get it working bug-free on your
jailbroken iphone, and still think that the document format as such is
the wrong way to be working.  Let us not conflate these two issues,
please.

Best regards,

A

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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 03 Jul 2009 11:04:07 -0700

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 

What is primary is to ensure that the revisable form can be easily read 30 years 
from now when the original display-creation software is lost.

Making the revisable form be better than the simplistic ASCII we've used since 
1969 is the second priority, not the first.

I'm all in favor of satisfying that second priority, but remain concerned that 
enthusiasm for it loses sight of the importance of the first priority.

This suggests that it is not quite enough to say xml or xml2rfc, but that we 
need to make sure the format of the submitted text is "directly" readable.  This 
makes a distinction between "readable" and "pretty".  Pretty is quite helpful 
for easy reading.  But only helpful.

Any competent xml editing tool let's you create and save such a readable format, 
but we can't take that for granted.  If we are going to change official 
requirements, we need them to mandate that the submitted version is as easily 
and directly readable as what we are giving up.  That means, prior to running 
the file through an xml-savvy processor.

So we need to specify formatting requirements for the revisable form.

If we are going to move to something like xml2rfc as the official 
revision/submission format -- and I do hope we do -- we need to specify rules 
for the layout of the submitted files, so that those files can be comfortably 
read with a character-display program that is not knowledge of the revision 
structure.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Jul 2009 14:12:39 -0400

Just so it does not get completely overlooked, I will point out that the 
page numbers are also useful for the table of contents.  And the ToC is 
very helpful to me when I need to find something in the document.  (Yes, 
hyperlinks would help in many cases.  But not all.)  the ToC is also 
helpful for getting a sense of what the document is about, and the page 
numbers can often hlpe the reader see where the real emphasis lies. 
(four sections, that look important, but all lie on the same page, tells 
you something right off about how much text there is on those topics.)

Yours,
Joel

---

From: John Levine <[email-masked]>
Date: 4 Jul 2009 11:27:42 -0000

>hyperlinks would help in many cases.  But not all.)

The TOC is basically a link table with coarse-grained targets.  It is
indeed often useful, but since it is mechanically generated from the
document's content, does it really matter whether it's stored as part
of the document, or generated on demand?

Since there are a lot of different ways to read and use an online
document, any format is a compromise.  The current format was a fine
compromise in the 1970s since it looks good on a TTY or line printer
and is OK on a 24x80 green screen terminal.  The tradeoffs are
different now, since some of us print them on 1200dpi page printers,
some read them on the tiny screen on a phone, and some of us use grep
followed by emacs.

I think it's reasonable to assume that going forward the vast majority
of users who read online documents will be able to use software that
can reformat them in various ways.  This tells me that although the
publication form has to be readable in a pinch as plain text, it's
more important that it's amenable to mechanical processing.  Tidily
formatted xml2rfc would be a reasonable candidate, and for backward
compatibility the public archives could easily contain both the new
form and a mechanically generated version that has numbered 60 line
pages and a TOC.

R's,
John

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 5 Jul 2009 16:04:40 +0300

> left with the current ASCII format.

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 in essence you lose a large part of the document.

In fact, you lose exactly the same information that you would lose 
were we to standardize some other format that embeds characters without compression
and merely pull the ASCII characters out.

So if you object to using a non-ASCII format because it will not be 100% readable
30 years from now, you should object to using the present format today.

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 5 Jul 2009 16:12:31 +0300

Marshall

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 technique, 
but had to give up due to the formulas not being transcribable 
(I had no problem submitting a patent application instead).

In TICTOC we are not even considering attempting any work that needs math,
but rather leave it to other SDOs.
It is considered a limitation of the system.

Y(J)S

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 5 Jul 2009 15:20:20 +0200

On Jul 3, 2009, at 19:49, Andrew Sullivan wrote:

> does not work at all in its stable version.

To me, 1.34pre3 appears to be exactly as stable as 1.33 (modulo the  
instability inevitably introduced by the 5378 train wreck).

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

Release early, release often.

Gruesse, Carsten

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 5 Jul 2009 15:24:32 +0200

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 subject line will get some of them to chime in. If  
that doesn't happen I'll shut up and try to figure out why I have so  
much trouble with something that nobody else finds difficult.

On 4 jul 2009, at 13:27, John Levine wrote:

> formatted xml2rfc would be a reasonable candidate

No, it's not. The problem with XML2RFC formatted drafts and RFCs is  
that you can't display them reasonably without using XML2RFC, and  
although XML2RFC can run on many systems in theory, in practice it's  
very difficult to install and run successfully because it's written in  
TCL and many XML2RFC files depend on the local availability of  
references. When those aren't present the conversion fails.

The philosophy behind XML2RFC is to encode meaning in the XML wherever  
possible, rather than simply display text. There are several problems  
with that:

1. It makes it hard to write source files, because now rather than  
type "Experimental" at the top of the file, I have to know what  
XML2RFC looks for to determine the draft's status. Same thing with  
boilerplate, references, etc.

2. It makes it hard to read source files for the same reason. You  
can't read an XML2RFC formatted XML file without prior knowledge and  
get all the information that would be displayed in the final draft/RFC  
format.

3. It gets it wrong. XML2RFC "knows" that you create a name from an  
initial, a period, a space and a last name. So initial "I" and last  
name "Van Beijnum" becomes "I. Van Beijnum". However, XML2RFC doesn't  
know that in Dutch, certain last name prefixes are capitalized if they  
appear at the beginning of the name (Van Beijnum) but not if they're  
in the middle because there are first names or initials: "I. van  
Beijnum".

This means that the makers of XML2RFC spent a lot of time making the  
tool require the authors to spend a lot of time to create something  
that is sometimes incorrect, with no means to correct the problem. An  
all-around waste of time.

Then there is the problem with XML in general. Now apparently there  
are XML editors that can make sure you create syntactically correct  
XML without having to take care of all the details manually. But as  
someone who has otherwise no need to write XML, I'm not familiar with  
those tools. So I write my XML2RFC source by hand. The result is that  
I invariably get error messages that the <section> and </section> tags  
don't match properly. This is a problem that is extremely hard to  
debug manually, especially as just grepping for "section" isn't  
enough: there could be a <!--, -->, </middle> etc somewhere between a  
<section> and </section> that breaks everything.

First writing a source file and then compiling it into an output file  
is no longer something something that is familiar to most people. When  
I write anything other than a draft, I can simply select "header level  
2" and I know that everything will be taken care of. I don't have to  
explicitly tell my word processor where the text following a header  
level 2 ends, because the presence of another header makes that clear  
both to me and to the software.

What we need is the ability to write drafts with a standard issue word  
processor. I'm sure that sentence conjured up nightmares of Word  
documents with insane formatting being mailed around clueless  
beaurocracies, but that's not what I mean. Word processors use styles  
to tag headings, text, quotes, lists and so on: the exact same stuff  
that you can do in XML but rather than having to think about it  
(especially closing all tags correctly) it happens easily,  
automatically and without getting in the way. (I can even change the  
style for an entire paragraph with a single menu selection or function  
key without having to find the beginnings and ends of that paragraph.)

Formatting is then based on the style tags, with all explicit  
formatting aplied by the word processor removed. This is standard  
operating procedure in 99% of publishing. (The other 1% being  
scientific/engineering books where the authors send in Latex.)

All the stuff that can't be handled by styles should just be copied  
and pasted from the boilerplate, without the need for tools to know  
about the structure of these things. (At least not in the draft stage,  
perhaps this can be useful in the final stages of RFC editing.)

---

From: Melinda Shore <[email-masked]>
Date: Sun, 05 Jul 2009 09:27:37 -0400

> 30 years from now, you should object to using the present format today.

I agree that ascii artwork has its limitations but I
find this hyperbolic and consequently unhelpful.  First,
I don't think that diagrams are necessary to understand
most documents, although they can be helpful and I think
the documents should be written with comprehensibility
in mind - reading them should not be a reminder that
without suffering there is no growth.  But I think the
documents that are completely incomprehensible without
the diagrams they contain are rare.  Maybe someone could
identify examples if they're that common.

Second, I don't know what "irreversibly corrupted" means
in this context. Even though there can be issues with
trying to display them in a proportionate font or on a
narrow screen, I'm not sure how you can claim that they're
"irreversibly corrupted" since the documents aren't
corrupted at all, just hard to read.  It's a display issue,
and I think you're overstating your case.

Right now ascii text is probably the most widely-supported
display format.  It seems to me that the priority has been
openness and universal accessibility, and that's what's
behind the choices that have been made.  It may be
appropriate to trade away a little bit of that accessibility
for documents that some people find easier to read,
although I think that would be a tough choice to make.  But
I hope that as the discussion continues (and continues and
continues and continues and continues) the broader,
organizational goals are kept in mind.

Melinda

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 5 Jul 2009 15:46:57 +0200

> Almost all RFCs have ASCII art in them,

[...]

> and in essence you lose a large part of the document.

No, you're missing my point. That point is that a file like this:

<p>In order to be able to use the largest packet sizes under the widest
range of circumstances, nodes SHOULD include a new MTU option in both
neighbor solicitation and neighbor advertisement messages RFC2461".</p>

<p>The format of the neighbor discovery MTU option is as follows:</p>
<pre>
    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  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              MTU                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

Will display as follows if you remove everything between < and >  
(inclusive):

In order to be able to use the largest packet sizes under the widest
range of circumstances, nodes SHOULD include a new MTU option in both
neighbor solicitation and neighbor advertisement messages RFC2461"

The format of the neighbor discovery MTU option is as follows:

    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  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              MTU                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here are links to the examples in case they get lost in the mail:

http://www.bgpexpert.com/drafthtml.txt
http://www.bgpexpert.com/drafthtml.html
http://www.bgpexpert.com/drafthtmlfiltered.txt

> So if you object to using a non-ASCII format because it will not be  
> 100% readable 30 years from now, you should object to using the  
> present format today.

Wasn't that what I was doing?

> It is considered a limitation of the system.

So once those standards are published somehwere else, what kind of  
language do you use to implement them that allows mathematical  
formulas to be part of the code?

In other words: anything that can be expressed in math symbols can  
also expressed in ASCII, programmers have been doing that for half a  
century. Annyoing, but it does have the advantage that once you have  
it in that format you don't have to worry about strange  
incompatibilities that make the symbols come out wrong.

---

From: "Dave Nelson" <[email-masked]>
Date: Sun, 5 Jul 2009 10:22:29 -0400

Iljitsch van Beijnum writes...

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

My personal experience with XML2RFC, as an I-D and RFC author has been
largely positive.  There does seem to be a bug in the latest pre-release
version around the use of ">" and "<" characters in ASCII art figures (as
arrow heads).  Other than that, I find it easy to use.

It's true that the documentation is merely adequate, especially in the area
of document meta-data.  I find it to be generally consistent with other open
source documentation.

> The problem with XML2RFC formatted drafts and RFCs is that you
> can't display them reasonably without using XML2RFC...

All you're saying is that XLM2RFC isn't WYSIWYG.  True enough.  Neither is
nroff.

> ...and although XML2RFC can run on many systems in theory, in
> practice it's very difficult to install and run successfully because
> it's written in TCL and many XML2RFC files depend on the local 
> availability of references.

I rely on the on-line, web-based conversion service.  I'll admit that I've
never gotten a local install of XML2RFC to work.

> What we need is the ability to write drafts with a standard
> issue word processor. 

Why?  I suppose if there were indeed a *standard* word processor, this might
be feasible, but I think by "standard issue" you mean "commercially
available".

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 5 Jul 2009 16:31:48 +0200

> be feasible, but I think by "standard issue" you mean "commercially

http://www.xmlmind.com/xmleditor/

Commercial, and the personal edition is available at no cost.
I've gotten non-CS people up to speed on that tool in no time.

Best with:
http://code.google.com/p/xml2rfc-xxe/

(But then, I use Emacs, which is non-commercial and free.)

Gruesse, Carsten

---

From: Colin Perkins <[email-masked]>
Date: Sun, 5 Jul 2009 15:38:32 +0100

> much trouble with something that nobody else finds difficult.

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.

I also appreciate the added consistency in Internet-Draft formatting  
that has resulted since xml2rfc has been widely adopted. This makes it  
a lot easier to print drafts, since they have consistent page sizes  
and form-feed characters.

-- 
Colin Perkins
http://csperkins.org/

---

From: Tim Bray <[email-masked]>
Date: Sun, 5 Jul 2009 07:51:09 -0700

On Sun, Jul 5, 2009 at 6:27 AM, Melinda Shore<[email-masked]> wrote:

> 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
world's population.
- For electronic consumption of texts longer than SMS messages, HTML
is the most widely-used display format, probably followed by PDF.
- For print consumption, the use of modern typographic techniques -
real quotation marks, dashes, accented characters if only for usages
like café and coöperate - is generally seen as required, so ASCII is
very seldom used.

ASCII-only is a primitive leftover from the
typographically-impoverished dawn of computing.  Can we get over it
already?  -T

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 5 Jul 2009 08:02:52 -0700

>It is considered a limitation of the system.

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, they are working under a misconception. Talk about premature anti-optimization!

--Paul Hoffman, Director
--VPN Consortium

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 05 Jul 2009 12:01:37 -0400

Having written a moderate number of drafts, using a number of tools, I 
find that I strongly prefer using XML2RFC.
One large draft I was working on was originally written using WORD.  I 
found it extremely difficult to work with (although I have a current 
version of Word available at all times.)
Instead, working with another author we converted the document to XML 
for XML2RFC.  And we did this in spite of knowing up front that the 
large amount of XML in the I-D was going to make this harder.

The current procedures allow for XML2RFC, Word, NROFF, and manual text 
(if you really want.)  Yes, to use any one of those you have to figure 
out some idiosyncrasies of the particular approach.  So I am very 
confused why you are asking us to kill a tool that was produced by 
volunteers, works very well, and that many people use by choice.

I have seen some folks arguing that we should make XML2RFC normative and 
mandatory.  If they can figure out how to automatically and accurate 
convert the other mechanisms people use, then that can be considered. 
Otherwise, mandating would be inappropriate, as some folks do indeed 
find it difficult.

Yours,
Joel M. Halpern

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 been ignoring the thread, hopefully the new 
> subject line will get some of them to chime in. If that doesn't happen 
> I'll shut up and try to figure out why I have so much trouble with 
> something that nobody else finds difficult.
...

---

From: Melinda Shore <[email-masked]>
Date: Sun, 05 Jul 2009 12:05:40 -0400

Tim Bray wrote:
> already?  

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 think the choice of formats tends to support more
openness and accessibility.  I think you're implicitly
arguing that that's not the right tradeoff, and frankly
I think it's exactly the right tradeoff, myself.

Melinda

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 5 Jul 2009 11:04:26 -0600

> much trouble with something that nobody else finds difficult.

I'm a programmer, so none of this probably matters, but I didn't have 
any more trouble learning to use xml2rfc than I normally have with other 
programs that are fairly powerful but poorly documented.  Reading XML is 
its own skill and not always easy, by any means, but that is true for 
any other text markup language.  Deciphering the error messages isn't 
easy either, but not *extremely* hard.

I did try to install xml2rfc locally on my system and failed miserably, 
partly because of all the additional junk I would have had to install, 
but the online version always works like a champ for me.

The point about capitalizing Dutch names wrong is an important 
localization issue, since people's names are important, but treating it 
as a fatal flaw in the premise of "encode meaning, not presentation" 
seems to weaken the overall argument.  It's a bug.

> key without having to find the beginnings and ends of that paragraph.)

I fear this will run into the ground instantly, if the anti-Microsoft 
faction insists on a single "standard issue" word processor that is 
unfamiliar to most users.  The same problems with learning to use a new 
tool will apply.

It sounds like what people really want is a more comprehensive system 
that would allow I-D authors to use xml2rfc, roff, Word, LaTeX, or 
basically any tool they like, not a great policy reversal that replaces 
one mandatory tool with another.  Given the level of effort involved and 
user expectations, especially concerning support for the latest updates 
to the IP boilerplate, this would be beyond the scope of volunteer 
developers; it would require professional developers with a professional 
development budget.

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 5 Jul 2009 11:13:43 -0600

Tim Bray <tbray at textuality dot com> wrote:

>> Right now ascii text is probably the most widely-supported display 
>> format.
>

I suspect Melinda meant to say "plain text," and wasn't intending to mix 
up the "ASCII vs. Unicode" debate with the "plain vs. formatted text" 
debate.

I predict people will continue to combine the character-encoding issue, 
the formatted-text issue, the pretty-pictures issue, and the 
document-creation issue into one big amorphous blob, significantly 
extending the length of time it will take to agree upon and solve any of 
these problems.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 05 Jul 2009 10:36:00 -0700

> vast majority of draft authors has absolutely no problems with XML2RFC.

I use the RFC 2629 format for all my drafts and cannot imagine using
something else.  The xml2rfc tool is not perfect but does a good job
to convert in html or text.

I do not think that the RFC 2629 format should be the only mandatory
format, but I think that the upload tool should at least give a
warning when an RFC 2629 document will not permit to recreate the
text version uploaded at the same time.

I wrote an (yet unpublished) tool to convert RFC 2629 documents to
mobi document, so they can be used on an Amazon Kindle.  The plan
was to take the list of all I-Ds published as RFC 2629 documents
before the deadline, convert them and let people install them on
their Kindle, e.g. to read on the trip to the IETF meeting.
Unfortunately most of the I-D uploaded in RFC 2629 form cannot be
used to generated a useful document (mobi or text), for two main
reasons: 1) the date element is not fully filled, so the date in the
final output changes and, 2) the references are not resolved (i.e.
there is <?rfc include='file'?> elements in the document), so the
final output changes when the documents referenced change.

The problem is that there is at the same time some high level
components (include, unspecified dates) mixed with low level
components in the RFC 2629 format.  The low level components are
part of the subset that makes possible to rebuild the various output
formats at anytime and that, IMO, should be enforced at upload time.
 The high level components are what makes the editing process
easier.  I use a superset of RFC 2629 for my documents (e.g. I use
xinclude instead of the include PI) and a script to convert it to
the low-level subset described above.  This script uses the docName
in the high level document to generate the filename of the low level
document, which is very useful when using source control management.
 The script also resolves all the xinclude references, removes the
comments and adds the current date.  The process is then something
like this:

turn-uri.xml
   --> draft-ietf-behave-turn-uri-02.xml --> upload
       --> draft-ietf-behave-turn-uri-02.txt --> upload
       --> draft-ietf-behave-turn-uri-02.mobi

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 05 Jul 2009 19:00:55 +0100

> http://code.google.com/p/xml2rfc-xxe/
+1

This is my preferred mechanism (thanks to Bill Fenner).  It isn't 
totally perfect but it makes it very difficult to produce invaliud xml 
and does give you a good idea of what you will get.

One colleague has had problems due to exploiting (or maybe just not 
getting caught by) some of the laxities in earlier versions getting 
tightened up later, but it is generally easy enough to fix things up.  
Bill's verifier is very helpful for this purpose.
http://www.fenron.com/~fenner/ietf/xml2rfc-valid/

As regards documentation, there are two sets of tutorial slides (maybe 
could be described as 'basic' and 'intermediate' - I wrote the latter).  
The FAQ is very useful and there are several templates, including the 
one I did to accompany the tutorial I did.  This has lots of explanatory 
text in it with many examples - there is a stripped down version for 
when you are experienced. These all fill in the holes left by the basic 
documentation IMHO, including the complete list of PIs and what they do.
http://xml.resource.org/xml2rfcFAQ.html

Regards,
Elwyn

---

From: [email-masked]
Date: Sun, 05 Jul 2009 11:16:36 -0700 (PDT)

> write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or

My experience has been the same. I will also add that I find the ability to
apply XML tools, including but not limited to syntax checking editors, very
convenient.

I particularly like the fact that xml2rfc lets me focus on the content of my
drafts and spend very little time on presentation issues. I don't even want to
think about how much time I've wasted piddling around with formattting nits
when using nroff, and don't get me started on LaTeX.

Oh, and as for installing the software, I'm not a TCL fan, but even so I've
done that on everything from  Mac OS 9 to Solaris to OpenVMS. I sure can't say
the same for groff.

My only serious complaint about xml2rc has been the current need to use a
pre-release version and the whole boilerplate thing, but I view that as a
failing (or is that "flailing"?) of our process and not an xml2rfc issuue per
se.

> and form-feed characters.

Agreed that the consistency is very welcome, but I honestly can't recall the
last time I printed out a draft or RFC. It's been several years at least.

				Ned

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 5 Jul 2009 21:37:43 +0200

On 5 jul 2009, at 16:22, Dave Nelson wrote:

> I suppose if there were indeed a *standard* word processor, this might

Standard issue = standard, typical. I used it in the sense of "any  
decent".

Any word processor can create styles the way I talked about, such as  
Word, Pages, OpenOffice, just to name the ones that I know are still  
around. The only problem converting a style-tagged document to draft/ 
RFC format or whatever archival format we end up using in the future.

The obvious way to do this would be to interpret the XML that each of  
these produce, but the problem is that they each have their own  
format, with little interoperation. Word 97 .doc format is the de  
facto lingua franca in the word processing world, but this is an  
inconvenient format. Rich text (RTF) format would probably be best.  
This format is fairly limited, but we only need the text itself and  
the styles so it should be more than sufficient. It's also a text- 
based format.

On 5 jul 2009, at 18:01, Joel M. Halpern wrote:

> So I am very confused why you are asking us to kill a tool that was  
> produced by volunteers, works very well, and that many people use by  
> choice.

You're right, I shouldn't use the word "die". The blog post by ekr  
that I linked to in my first message talked about how XML2RFC has  
become a de facto requirement because of the outdated formatting  
requirements that can only be met with XML2RFC or even quainter tools.  
This is what I'm having problems with. Of course if people are happy  
with XML2RFC, that's fine.

> I have seen some folks arguing that we should make XML2RFC normative  
> and mandatory.  If they can figure out how to automatically and  
> accurate convert the other mechanisms people use, then that can be  
> considered.

Ah, but that's impossible, unless you add an AI to the conversion tool  
that comes up with the semantic annontations that were never in the  
source.

> On 5 jul 2009, at 19:04, Doug Ewell wrote:

>> localization issue, since people's names are important, but  
>> treating it as a fatal flaw in the premise of "encode meaning, not  
>> presentation" seems to weaken the overall argument.  It's a bug.

It's not a bug, it shows that the basic premise behind XML2RFC is  
untenable.

>>
>>> What we need is the ability to write drafts with a standard issue  
>>> word processor. I'm sure that sentence conjured up nightmares of  
>>> Word documents with insane formatting being mailed around clueless  
>>> beaurocracies, but that's not what I mean. Word processors use  
>>> styles to tag headings, text, quotes, lists and so on: the exact  
>>> same stuff that you can do in XML but rather than having to think  
>>> about it (especially closing all tags correctly) it happens  
>>> easily, automatically and without getting in the way. (I can even  
>>> change the style for an entire paragraph with a single menu  
>>> selection or function key without having to find the beginnings  
>>> and ends of that paragraph.)
>>
>> I fear this will run into the ground instantly, if the anti- 
>> Microsoft faction insists on a single "standard issue" word  
>> processor that is unfamiliar to most users.  The same problems with  
>> learning to use a new tool will apply.
>>
>> It sounds like what people really want is a more comprehensive  
>> system that would allow I-D authors to use xml2rfc, roff, Word,  
>> LaTeX, or basically any tool they like, not a great policy reversal  
>> that replaces one mandatory tool with another.  Given the level of  
>> effort involved and user expectations, especially concerning  
>> support for the latest updates to the IP boilerplate, this would be  
>> beyond the scope of volunteer developers; it would require  
>> professional developers with a professional development budget.
>>
>> --

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 05 Jul 2009 14:52:57 -0500

>and form-feed characters.

huh?

the current boilerplate has the first page being 54 lines long, and 
subsequent pages being 57 lines long, but with the "footer" on the 
56th line, and not the 57th.

The "footer" on the first page isn't on the last line of the page either.

This isn't very uniform...  perhaps unless you use some special 
viewer to recreate this non-uniform display consistently.

IDs and RFCs are displayed in text, and they should be viewable in 
any text program consistently.

Or am I missing some magic program that is implicitly mandatory to 
use in all this process?

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 05 Jul 2009 14:55:39 -0500

+1

At 11:01 AM 7/5/2009, Joel M. Halpern wrote:
>considered. Otherwise, mandating would be inappropriate, as some 
>folks do indeed find it difficult.
>
>Yours,
>Joel M. Halpern
>
>>hopefully the new subject line will get some of them to chime in. 
>>If that doesn't happen I'll shut up and try to figure out why I 
>>have so much trouble with something that nobody else finds difficult.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 5 Jul 2009 22:35:40 +0200

I also support this view, and the reason why I think this is a good  
idea is that the likelyhood we will see MORE (professional) tools  
helping with the XML2RFC production if we do.

So I think it will help "both" views expressed on this list.

    Patrik

On 5 jul 2009, at 21.55, James M. Polk wrote:

>> I have seen some folks arguing that we should make XML2RFC  
>> normative and mandatory.  If they can figure out how to  
>> automatically and accurate convert the other mechanisms people use,  
>> then that can be considered. Otherwise, mandating would be  
>> inappropriate, as some folks do indeed find it difficult.
>>
>> Yours,
>> Joel M. Halpern
>>
>>> 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 subject line will get some of them to  
>>> chime in. If that doesn't happen I'll shut up and try to figure  
>>> out why I have so much trouble with something that nobody else  
>>> finds difficult.
>

---

From: Colin Perkins <[email-masked]>
Date: Sun, 5 Jul 2009 21:59:37 +0100

> viewer to recreate this non-uniform display consistently.

It doesn't greatly offend me that the first page is three lines  
shorter than the other pages.  Nor does it confuse enscript, on those  
occasions when I want to print an internet-draft or RFC.

This is very much unlike the situation pre-xml2rfc, when the page  
length and width varied considerably for some drafts, and where form- 
feeds were often inconsistently applied.

-- 
Colin Perkins
http://csperkins.org/

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 5 Jul 2009 19:25:39 -0400

+1

For those who are used to MS-Word, XMLMind is frustrating and truly requires an XML mind.  Even simple things like cut/paste are done in a very different (and frankly inconsistent) way, as are references and such.  In theory a WYSIWYG word processor shouldn't require an author to know the internal representation and underlying language of the document format.

I know a large number if not outright majority of IETF authors do not use MS-Word, so XML2RFC is a fine *option* - but please don't ever *mandate* it and force the rest of us have to write documents in a syntax only a tiny fraction of the planet uses and understands.

-hadriel

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 06 Jul 2009 03:44:17 +0200

I also would be against mandating xml2rfc.

I do agree that certain aspects of xml2rfc are convenient, but when it comes
to edit text, I really prefer .nroff

> done that on everything from  Mac OS 9 to Solaris to OpenVMS. I sure can't say

I hope to have provided a simple way to get around these issues with nroff
with the tool I wrote, as it makes it easy to do the formatting nits and
does not require groff or any other external tools to be installed.

/Stefan

---

From: Tim Bray <[email-masked]>
Date: Sun, 5 Jul 2009 20:46:15 -0700

On Sun, Jul 5, 2009 at 9:05 AM, Melinda Shore<[email-masked]> 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
issues, so let's try and be careful about our assertions.

>  Right now
> is.

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 print
HTML instantly and correctly at the touch of control- or command-P,
but can render IETF legacy ASCII on paper only with various gyrations
and sidesteps.

> As I mentioned in the mail to which you're responding,

I think that we're in agreement as to objectives: openness,
accessibility, and usability. My claim is that a carefully considered
and constrained flavor of HTML would meet those objectives better than
IETF legacy ASCII.  I claim that this is true exclusive of whatever
consensus develops around the issues of i18n and the introduction of
graphics.

(There may be a disagreement in that I would tend to place more weight
than some others on the needs of spec consumers compared to those of
producers.)

 -Tim

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 5 Jul 2009 22:02:53 -0600

> but can render IETF legacy ASCII on paper only with various gyrations 

I'd still be more confident that the differences between the issues were 
understood if the above text read "IETF legacy plain-text" instead of 
"IETF legacy ASCII."  If we moved from ASCII to UTF-8 tomorrow, but 
otherwise kept the current plain-text format with its lines separated by 
CRLF and its pages separated by FF, and all of the other rigid 
formatting constraints, the same complaints about plain-text versus HTML 
would exist.

---

From: Tim Bray <[email-masked]>
Date: Sun, 5 Jul 2009 21:16:48 -0700

On Sun, Jul 5, 2009 at 9:02 PM, Doug Ewell<[email-masked]> 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 the touch of control- or command-P, but can
>> render IETF legacy ASCII on paper only with various gyrations and sidesteps.
>
> understood if the above text read "IETF legacy plain-text" instead of "IETF
> legacy ASCII."

You're entirely correct, and my poor phrasing is less forgiveable
because I was just giving Melissa a hard time for her assertions about
"ASCII".  Sorry.

>  If we moved from ASCII to UTF-8 tomorrow, but otherwise kept
> the current plain-text format with its lines separated by CRLF and its pages
> separated by FF, and all of the other rigid formatting constraints, the same
> complaints about plain-text versus HTML would exist.

Right.  As many have pointed out here, there are three separate issues here:
1. Usability
1.a Reader usability
1.b Author usability
2. Internationalization
3. Graphics

My argument is that 1.a. and 2. would be dramatically improved by the
introduction of HTML, while 1.b. would not on average change much
across the universe of I-D authors.  And that 3 is a less urgent issue
than 1 and 2.

-Tim

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 6 Jul 2009 09:53:25 +0300

OK, here is what happens on my netbook using your method.

Original

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
   +-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+
   |     Type      |    L
ength     |R|T|  Transpor
t flags  |  Res  |
   +-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+
   |                     
         MTU             
                 |
   +-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 6 Jul 2009 10:01:06 +0300

> ... 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 power is not needed for the plain text documents that
most people participating in this thread seem to be writing.

Y(J)S

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 6 Jul 2009 09:06:28 +0200

> most people participating in this thread seem to be writing.

Problem with LaTeX and TeX is the need for class libraries, and the  
lack of agreed upon way of distributing a LaTeX/TeX file with the  
class files needed (part from what is "standard"), or lack of  
automatic tools that include needed things from the class files to the  
source file.

    Patrik

---

From: Lars Eggert <[email-masked]>
Date: Mon, 6 Jul 2009 10:10:12 +0300

+1

I maintain the fink package for xml2rfc, and the committers asked me  
to wait for the "stable" release instead of sending them ports for  
"pre" releases (the "pre" releases don't fit well with the regular  
fink naming scheme and hence require manual tweaking, which they want  
to avoid.)

Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 6 Jul 2009 10:18:14 +0300

Hi,

> hopefully the new subject line will get some of them to chime in.

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 (for svn, diff, etc.)

I'm fully open to trying something new once someone creates a  
different ("better") tool, but until then, xml2rfc is OK.

Lars

---

From: james woodyatt <[email-masked]>
Date: Mon, 6 Jul 2009 00:23:24 -0700

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 to put the bar.
>
> [my piquant comment elided for space]
>
> 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'.

I don't want to go that far.  Let me revise my remarks: the perception  
of editors making seemingly arbitrary objections about *manuscript  
formatting*, primarily for the purpose of "rubbing the noses" of  
prospective authors in their own plebeianness, is a very common trait  
among unpublishable wankers.  (Being an unpublishable wanker myself  
still, I'm speaking from experience *and* close observation of my  
peers.)

Shorter james: I'll need to be convinced that perception is fair  
before I can join in the pillorying of our I-D submissions system  
maintainers.

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

---

From: Bill McQuillan <[email-masked]>
Date: Mon, 6 Jul 2009 00:24:58 -0700

What sort of editable input, handled by what sort of presentation
mechanism, would solve this case?

And, if it involves horizontal scrolling and/or zooming in or out, why
wouldn't that also handle plain text, too?

-- 
Bill McQuillan <[email-masked]>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 6 Jul 2009 09:37:27 +0200

Hm, it's not supposed to break lines between <pre> and </pre> even if  
they don't fit on the screen...

Obviously ASCII art is created with screen / paper size assumptions  
built in. I never claimed I was able to get around that. My claim was  
that it was possible to create an HTML-ized form of the RFC format  
that would both be valid HTML and could be turned back into the well- 
known plain ASCII format by simply removing the HTML tags.

Due to the difficulties in making good graphics and the issue of  
having a single RFC span multiple files in the case of HTML format  
with graphics I think we should stick with ASCII art in the general  
case even if we move to HTML as the archival format. But packet layout  
diagrams can be made with HTML tables, which would make them a little  
more flexible than ASCII art but on a really tiny screen those still  
wouldn't display very well.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jul 2009 09:46:24 +0200

Lars Eggert wrote:
> used Joe's Word template, which works OK, but I prefer something 
> ASCII-based for collaborative editing (for svn, diff, etc.)
> 
> I'm fully open to trying something new once someone creates a different 
> ("better") tool, but until then, xml2rfc is OK.

Indeed.

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 on a 
revision of it (that is, RFC 2629).

With respect to the tools: I usually do not worry about xml2rfc.tcl (the 
processor) until I need to submit something. Instead, I make sure that 
my source validates (against the DTD), and instead focus on content, and 
just review the HTML output, as produced by rfc2629.xslt. The latter 
works on any machine that has support for XSLT, such as any that can run 
IE6, Firefox 2, Opera 9, or Safari 3. And no, you don't need a browser 
to run the XSLT, just install xsltproc or Saxon.

Finally, regarding local installations of xml2rfc.tcl: at least on 
Windows, just install Cygwin, make sure TCL is included in the install, 
and it will work just fine.

BR, Julian

---

From: Melinda Shore <[email-masked]>
Date: Mon, 06 Jul 2009 06:08:10 -0400

Tim Bray wrote:
> extremely well-defined term"ASCII". 

Sure, you are.  You're implying that there are characters
we want to display that can't be done within the current
constraints.

> at all.  

I've never run into a device that can't display ASCII at
all (if it can display HTML it can display plain ASCII), but
have used and owned a large number of devices that can't
display HTML.  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.

Melinda

---

From: Dave Cridland <[email-masked]>
Date: Mon, 06 Jul 2009 11:43:32 +0100

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  
> on a revision of it (that is, RFC 2629).
> 
> 
The vocabulary is basically sound. I sympathize with Iljitsch wanting  
finer control over the rendering of his name, which would need to be  
addressed here.

If a GUI WYSIWYG tool got created, I'd probably use it. If someone  
created an import filter for some word processor or another, I might  
use it, but I generally don't get on with word processors anymore. (I  
had an argument with one a few years ago, we never made up).

> With respect to the tools: I usually do not worry about xml2rfc.tcl  
> (the processor) until I need to submit something. Instead, I make  
> sure that my source validates (against the DTD), and instead focus  
> on content, and just review the HTML output, as produced by  
> rfc2629.xslt. The latter works on any machine that has support for  
> XSLT, such as any that can run IE6, Firefox 2, Opera 9, or Safari  
> 3. And no, you don't need a browser to run the XSLT, just install  
> xsltproc or Saxon.
> 
> 
I do much the same, although because the document is in XML, I use a  
slightly extended format to include annotations to support finer  
reference handling and checking, which I scribbled some time back in  
XSLT. It gives me an extra stage to my processing, and annoys  
co-authors, but produces documents I know have the right references  
in the right sections.

XML purists will probably wail and gnash teeth, since I replaced the  
inclusion handling very early on with something probably even worse  
than the include PI, but that's the joy of XML.

> Windows, just install Cygwin, make sure TCL is included in the  
> install, and it will work just fine.

There are also online versions, which eliminate the need to install  
it at all if you've got bandwidth.

I'm quite sure that both the file format and toolset could improve,  
but I thinks it's a very reasonable way of processing drafts as it  
is, and I've be very happy if it were eventually the only way.

FWIW, I suspect that the way I'm doing things - with an initial  
format and using the RFC 2629 format as an intermediate one - is  
probably the rough shape of things to come.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jul 2009 12:43:39 +0200

> all (if it can display HTML it can display plain ASCII), but

Some EBook readers, as far as I recall, display XHTML fine, but do not 
display plain text. And even if they do, you will encounter the line 
wrap problem.

> technical specifications.

Of course that depends on the type of HTML we would use. For instance, 
if you get inconsistent results with the HTML my XSLT variant of xml2rfc 
produces, please let me know (example: 
<http://greenbytes.de/tech/webdav/rfc2616.html>).

BR, Julian

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 06 Jul 2009 11:53:35 +0100

+1

... and I am quite happy to use the online compiler.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 06 Jul 2009 11:56:15 +0100

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 d…
We know this, the problem is that you cannot publish a standards
track document in this format.

Stewart

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 6 Jul 2009 13:01:56 +0200

On 6 jul 2009, at 12:08, Melinda Shore wrote:

> Plus, there appears to be a certain amount

I disagree with 2. Today, drafts and RFCs have a fixed format, that  
should render the same on all displays and in print (barring font  
differences, but I guess Courier is assumed). Although this format  
isn't particularly pretty and current mainstream tools can no longer  
create it, this format has a lot going for it:

- pretty much everything that can classified as a computing device can  
display it natively
- should the need arise to write an implementation for display  
software from scratch, that would be extremely trivial
- no issues with copy/paste
- compatible with lots of tools

However, it has one big issue: it doesn't adapt to the properties of  
the display gracefully. (Or at all, really.)

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 as preformatted text. This type of basic HTML will render  
slightly differently on different implementations, but that's the  
point. Unless technical meaning is encoded in spaces and line breaks,  
this shouldn't matter.

And even in basic HTML, it's possible to add class specifications etc  
that allow tools to apply more intelligence than would be possible  
with plain text.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jul 2009 13:12:09 +0200

Iljitsch van Beijnum wrote:
> tables, but we'd lose the headers/footers. ASCII art could still be used 
> ...

Headers/footers will work just fine with a HTML client that supports the 
CSS3 paged media extensions; for now that's only PrinceXML 
(http://www.princexml.com/), but it's a start.

BR, Julian

---

From: Shane Kerr <[email-masked]>
Date: Mon, 06 Jul 2009 13:51:53 +0200

Iljitsch,

> much trouble with something that nobody else finds difficult.

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
doesn't handle non-ASCII very well (important for some names), the error
output is non-intuitive, the tool didn't work off-line (no fun on an
airplane), and so on.

It seems to get in the way of writing the actual draft.

Maybe there is no better way, but it seems hard to believe. (I am more
willing to believe that there is no better way *now*, but that one may
be found in the future.) Making it harder on authors (of which we seem
to have plenty) in order to make things easier on editors and reviewers
(which seem in short supply) may be the right trade-off.

--
Shane

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jul 2009 14:01:32 +0200

> 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 problem per se.

> output is non-intuitive, the tool didn't work off-line (no fun on an

It does work offline, unless your source requires non-local files (like 
external references).

BR, Julian

---

From: Lou Berger <[email-masked]>
Date: Mon, 06 Jul 2009 08:19:21 -0400

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 easier and let me focus on the the document rather than
the document production...

Lou

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Jul 2009 09:28:27 -0400

> 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 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 there are some dust bunnies in the
corners.  If I knew anything at all about TCL, I'd probably try to do
more work on it, but as it is I'm just grateful that those who work on
xml2rfc do as good work as they do.  (That isn't to say that there
isn't an issue here with process, but as I already that is not a
criticism of the xml2fc developers.)

A

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 06 Jul 2009 09:42:16 -0400

> hopefully the new subject line will get some of them to chime in.

I was ignoring it and hoping it went away.  ;-)

I started off using the MS Word template and CRLF to output txt documents.
I found this to be a PITA.  About 9 months ago I switched to xml2rfc and
found it to be great.  Yes, it had a learning curve and the error messages
could be better, but the learning curve is not terrible IMHO and you
eventually get to figure out what the errors mean after awhile.  My
productivity gains in writing and editing drafts is much higher than with MS
Word, though I miss some of Word's built-in change acceptance/rejection
functionality (doing an xml diff is fine, just different).

I also love being able to define both external links and internal anchors so
easily.  Just the internal reference linking has saved me time in post
version -00 docs when I move sections or sentences around and needn't worry
about keeping track of what section was what number.  And it is also nice to
be able to share an HTML version of the doc with co-authors and reviewers,
rather than a txt doc with no working links.

I happen to use Coda on the Mac and use it to write HTML and other scripting
stuff.  YMMV.

> references. When those aren't present the conversion fails.

How frequently do any of us work when we're not connected to the Internet?
I just have my XML editor open in one window and the web-based xml2rfc tool
in the other, and every time I make a significant change, I just re-run it
to display an HTML version of the document.  This tends to also make
error-investigation easier since I know what I just changed and can then
review a specific section to find my error.

> <section> and </section> that breaks everything.

This is most likely a nested section tag problem.  When you write your XML
do you have every "flat" and justified left?  If so, I'd recommend you
tab-in sections and keep your open and close tags lined up, as well as any
tags within each section tabbed in further.

> processor. 

You mean like the template and directions available for MS Word?  Why not
just use that?  

Jason

---

From: Bob Braden <[email-masked]>
Date: Mon, 06 Jul 2009 06:56:45 -0700

> track document in this format.

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.

Bob Braden

---

From: Eric Rosen <[email-masked]>
Date: Mon, 06 Jul 2009 10:52:53 -0400

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
questions of the form  "what do I have to do to  make xml2rfc produce output
that  will pass  idnits?".  I  can't tell  them "just  put in  the following
boilerplate", instead  I've had to figure  out the right value  of the "ipr"
variable.  (BTW, no one ever  cares what the boilerplate actually says, just
whether it will  pass idnits; xml2rfc really encourages  folks to ignore the
semantics of the boilerplate.) 

Joel> One large draft I was working on was originally written using WORD.  I
Joel> found it extremely  difficult to work with (although  I have a current
Joel> version  of  Word available  at  all  times.)   Instead, working  with
Joel> another author we converted the document to XML for XML2RFC.

Hey, I've converted  from both Word and  XML to nroff; that way  I don't get
any surprises  ;-) OTOH, I  have to admit  that nroff was a  bit challenging
when I moved from Solaris to Linux.

Joel> I have seen  some folks arguing that we  should make XML2RFC normative
Joel> and mandatory.

Of course,  in the  IETF it  is very common  for folks  to think  that their
personal preferences are objectively superior.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Jul 2009 07:59:34 -0700

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 that says one way or another, but I could have missed it). We have recent full-worked examples where the PDF for a standards-track document has valuable visual information, such as RFC 5059.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rosen <[email-masked]>
Date: Mon, 06 Jul 2009 10:58:32 -0400

> 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  of "page  numbers"  and "table  of
contents" have quite reached the status of "quaint and archaic".

> large number  of standard  office printers that  print HTML  instantly and
> correctly 

My experiences printing HTML docs are a bit different, I guess.

Is there no  tool that will html-ize an RFC or  i-d for presentation?  Folks
who want to  read RFCs on their cell  phones should be able to do  it, but I
really don't see what that has to do with archival formats.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 6 Jul 2009 17:05:11 +0200

On Jul 6, 2009, at 15:28, Andrew Sullivan wrote:

> corners.

While I'm certain there are some dust bunnies, I'm nearly certain they  
are the same as with 1.33.

There simply aren't that many changes.

1.34pre3 is certainly working for people doing drafts these days.
1.33, however, is utterly useless!

Ship it.

(Maybe after removing the one remnant test output in the nroff  
rendering code on line 12106.)

Gruesse, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jul 2009 17:08:17 +0200

> leave a lot to be desired, as the included links always seem to go stale.

But that's a problem of the link targets, not the document format, right?

> My experiences printing HTML docs are a bit different, I guess.

In generic, or HTML as produced by tools.ietf.org, xml2rfc, or rfc2629.xslt?

BR, Julian

---

From: Tony Hansen <[email-masked]>
Date: Mon, 06 Jul 2009 11:17:13 -0400

+1!!

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 06 Jul 2009 08:41:43 -0700

Eric Rosen wrote:
> references to  be a  really useful  tool.  

Given how extensive and strong the support for using it is, your assertion is 
demonstrably incorrect.  On the other hand, that some folk might not like using 
it is demonstrably correct.

d/
-- 

   Dave Crocker

---

From: Bob Braden <[email-masked]>
Date: Mon, 06 Jul 2009 08:53:08 -0700

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.
	...
	The primacy of the ASCII version typically requires that the
  	critical diagrams and packet formats be rendered
	as "ASCII art" in the .txt version.

	However, secondary or alternative versions in PostScript and/or
	PDF are provided for some RFCs, to allow the inclusion of fancy
	diagrams, graphs, or characters that cannot possibly be rendered
	in ASCII plain text

Bob Braden
for the RFC Editor

---

From: Russ Housley <[email-masked]>
Date: Mon, 06 Jul 2009 11:52:12 -0400

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-guidelines.html
This web page provides guidelines for I-D submission.  While the vast 
majority of the information in it is correct, It needs to be 
updated.  The author has just been too busy to do the update.

http://www.ietf.org/ID-Checklist.html
This web page provides the things that are checked by the IDnits tool 
which is used as part of the online submission checking.

I have personally prepared an I-D and checked it with the IDnits 
running on tools.ietf.org an then had it rejected by the online 
submission tool.  I have asked the Secretariat to work with Henrik to 
figure out what is wrong.  I suspect others have been caught in the 
same situation.  Perhaps that was resolved in the week while I was 
away.  I'll be checking after I clear my email backlog.  The answer 
might be in it...

There is no intention that xml2rfc be the only way to produce an I-D 
that is acceptable to the online submission tool.  xml2rfc seems to 
have a higher success rate, and we are working to improve the online 
submission tool so that all of the various tools have high success rates.

Russ

At 06:01 PM 6/29/2009, 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.

---

From: John Levine <[email-masked]>
Date: 6 Jul 2009 16:53:58 -0000

> 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 despite
having used it on and off since Word 6 in the early 1990s.
Personally, I can edit XML using emacs and its XML macros without much
trouble, since its auto-indent makes it straightforward to figure out
what's supposed to match what, and the xml2rfc codes aren't notably
harder or easier to remember than nroff directives or Word styles.

Just considering the question of what formats are best for authors and
readers (not i18n or graphics), I see people talking past each other
and getting nowhere.

Is it essential that anyone can be fully productive editing I-Ds using
teco or vi with no training?  Or would it be OK to assume that most
people will have access to better tools, so long as it is possible if
painful to edit them with a basic text editor?

Similarly, does the publication format have to be directly displayable
using the native tools found on TOPS-10 or CP/M, or would it be OK to
assume that most people will have access to better tools, so long as
it's possible to view them in a tty emulator, either directly, or by
providing both canonical and rendered versions at the RFC editor FTP
or web server?

It should be pretty obvious what I think the answers to these
questions are, but my answers are clearly not everyone else's.  We
can't solve the problem until we have rough consensus about what
problem we're trying to solve.

R's,
John

---

From: Martin Rex <[email-masked]>
Date: Mon, 6 Jul 2009 22:25:30 +0200 (MEST)

Stefan Winter wrote:
> 
>                                  Plain ASCII makes work on drafts which

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.

non-ASCII letters are a royal PITA in so many ways, that they should
not be used.

Finding a Postscript printer driver that prints umlauts is
extremely difficult (I know, I'm German and I can't get PDFs printing
properly with Umlauts).  Similarly, quite a lot of screen fonts do
not contain Umlauts.  And although my software is configured to
work with iso-8859-1, it is unable to display cyrillic and greek
characters.  

And while I'm German and have keys for umlauts on my keyboard,
I have serious difficulties to create other funny characters
from the iso-8859-1 character set (like some skandinavian),
let alone greek, cyrillic or any symbols from asian languagues.

I can not recognize, name or type any of the symbols from
asian languages, and I can neither print or display them,
nor input them on my keyboard.  Which makes it completely
impossible to search for them or discuss them.

Really, I see no justification why they should be part of an
IETF specification, if they're only marginally useful to a 
(smaller) fraction of the consumers of IETF specs and fairly
hostile and unusable to the rest.

If the IETF want so allow umlauts, it will have to allow all
of Unicode, and that would become close to a catastrophe.
 90.0% of the software *I* use is capable of ISO-8859-1,
  9.9% is pure-ASCII
  0.1% is capable to do more than that (not necessarily
       full unicode)

Actually, most of the common fixed sized fonts seem to
contain only ASCII characters (and fixed size fonts happen
to be the fonts that I use mostly).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 6 Jul 2009 22:40:18 +0200 (MEST)

> I can't imagine anything better for professional document preparation.

I bought the TeXbook in 1989 and liked it, despite the learning curve.

I tried LaTeX in 1992 and junked it.  The header&footers used
in the LaTeX book where impossible to create with LaTeX (which I think
amounts to cheating), so I dropped back to plain TeX. 

The problem with most LaTeX documents I came across in 1991-1995
was that they used style files that were extremely hard to find
(for someone not using a particular universities infrastructure).

The TeX language/syntax takes a little getting used to.

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jul 2009 22:53:12 +0200

> the texts (and the examples) to ASCII.

Text? Yes. Examples? Contact info? No.

> non-ASCII letters are a royal PITA in so many ways, that they should

Disagreed.

> work with iso-8859-1, it is unable to display cyrillic and greek

I have never had problems printing PDFs with umlauts.

> let alone greek, cyrillic or any symbols from asian languagues.

That's a totally orthogonal issue.

> impossible to search for them or discuss them.

I'm pretty sure that you can display and print at least some of them 
with a recent browser and operating system.

> hostile and unusable to the rest.

Non-ASCII characters in I18N examples would be useful to *any* reader. 
Keep in mind that a consumer of an IETF spec will be able to read 
English, thus understand the Latin alphabet, and thus be able to 
understand the difference between, for instance, an "e" and an "é".

> of Unicode, and that would become close to a catastrophe.

I would support allowing all of Unicode for contact information (as long 
as an ASCII substitute text is available), and a subset for examples.

>   0.1% is capable to do more than that (not necessarily

Any HTML4 user agent supports Unicode (and no, that doesn't mean it will 
have fonts to display all of it).

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jul 2009 22:54:25 +0200

> XML tags, if any.  (So that tools more mainstream languages can be

Could you please elaborate what you mean by "restricted subset of XML tags"?

BR, Julian

---

From: Martin Rex <[email-masked]>
Date: Mon, 6 Jul 2009 23:16:14 +0200 (MEST)

> Could you please elaborate what you mean by "restricted subset of XML tags"?

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.

-Martin

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jul 2009 23:29:24 +0200

> programming languange and NOT use any weird and incompatibly-revved

So you mean a subset of the XML syntax.

Apparently you've had bad experience with XML in the past. I realize 
that there's a lot of junk out there which calls itself "XML parser"; 
but it's certainly not hard to find compliant XML parsers. Just do not 
use the broken ones.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Jul 2009 23:30:50 +0200

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 the new 5378 escape clause; 
I'd need to review this mailing list's archives for details.

BR, Julian

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 6 Jul 2009 14:38:54 -0700

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. 

I am not opposed to tools like xml2rfc in general, but that implementation
(even using something like xmlmind with the appropriate filter) represents a
giant leap backward to the early 80's world of document creation. As far as
I am concerned xml2rfc represents a first step, but we must not stop there. 

Tony

> Hadriel Kaplan
> Sent: Sunday, July 05, 2009 4:26 PM
> To: Joel M. Halpern; Iljitsch van Beijnum
> Subject: RE: XML2RFC must die, was: Re: Two different threads - IETF
> Document Format
> 
> 
> For those who are used to MS-Word, XMLMind is frustrating and truly
> requires an XML mind.  Even simple things like cut/paste are done in a
> very different (and frankly inconsistent) way, as are references and
> such.  In theory a WYSIWYG word processor shouldn't require an author
> to know the internal representation and underlying language of the
> document format.
> 
> I know a large number if not outright majority of IETF authors do not
> use MS-Word, so XML2RFC is a fine *option* - but please don't ever
> *mandate* it and force the rest of us have to write documents in a
> syntax only a tiny fraction of the planet uses and understands.
> 
> -hadriel

---

From: Tim Bray <[email-masked]>
Date: Mon, 6 Jul 2009 21:26:16 -0700

On Mon, Jul 6, 2009 at 12:18 AM, Lars Eggert<[email-masked]> wrote:

> 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 (for svn, diff, etc.)
>

What Lars said. -T

---

From: Lars Eggert <[email-masked]>
Date: Tue, 7 Jul 2009 10:33:24 +0300

"Release early, release often."

Can't we simply do a 1.35 whenever the upcoming changes have been  
finalized?

Lars

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jul 2009 06:04:14 -0400

--On Sunday, July 05, 2009 12:01 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> Having written a moderate number of drafts, using a number of
> tools, I find that I strongly prefer using XML2RFC.
>...
> The current procedures allow for XML2RFC, Word, NROFF, and
> manual text (if you really want.)  Yes, to use any one of
> those you have to figure out some idiosyncrasies of the
> particular approach.  So I am very confused why you are asking
> us to kill a tool that was produced by volunteers, works very
> well, and that many people use by choice.
> 
> automatically and accurate convert the other mechanisms people
> use, then that can be considered. Otherwise, mandating would
> be inappropriate, as some folks do indeed find it difficult.
>...

+1

I also believe that some documents may argue for different
tools.  In one document I've had to work on recently, I've had
to use the xml2rfc-> nroff -> text path (or could have started
in nroff), and it doesn't make me very happy.  But that is, at
most, an argument for improving xml2rfc, not for getting rid of
it.

I do believe that we need to [regularly] reexamine the content
and format requirements for I-Ds to be sure that no set of tools
is inadvertently excluded or made more burdensome, but that is a
separate issue.

> How frequently do any of us work when we're not connected to

Quite a lot, actually.  And it is why, as pointed out in an
earlier note, I think xml2rfc would benefit from a "report and
move on" strategy for dealing with external entity references
that cannot be retrieved and/or from a directive or attribute
that would permit use of a text placeholder as the body of a
<reference> element in documents under development rather than
the formal structure now required.  But the tool is quite usable
without those enhancements and, even when I'm working offline
for an extended period, I haven't found that "edit offline,
compile after I get back on line" is a serious impediment to
getting work done.

   john

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jul 2009 06:25:02 -0400

> I think it's exactly the right tradeoff, myself.

Agreed.

I also find it fairly disturbing that we cannot seem to have any
discussion at all about RFC content, format, or methods of
production without also opening up and rehashing all of the
questions of:

	* Why RFC's should not be published in Lower Slobbovian?
	
	* Why the native RFC character set cannot be EBCDIC-32?
	
	* Whether pictures are, or are not, better than text?
	
	* Whether it is more important to optimize for passive
	readability on, e.g., objects with small screens or for
	searching, extraction, and editing?

	* Whether someone's favorite tool for aiding in the
	production of documents should be made mandatory or
	prohibited entirely as a source of evil?

and so on.  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.  Worse, these floods
of discussions tend to drive out small but useful improvements
by overwhelming any meaningful discussion of the proposed
changes themselves.

Sad.

    john

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Jul 2009 12:49:37 +0200

On 7 jul 2009, at 12:25, John C Klensin wrote:

> The questions, or at least a subset of them, are
> important, and that wastes a lot of time.

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) everyone,  
rather than optimize for one particular way to interpret the state of  
the universe.

The "good" thing is that the current situation leaves so much to be  
desired that this should actually be doable.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 7 Jul 2009 09:03:18 -0400

I created an xml2rfc template, like those available on xml.resource.org,
which I copy and modify for new drafts, and use the web version of the
tool - and everything works well enough for me.

I'm decidedly not picky about formatting, because I want to spend my
time contributing content.

Because sometimes the error messages can be cryptic, when modifying the
XML tags, I frequently submit the document and generate HTML in order to
bound the number of XML tags that can contribute to a problem.

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tim Bray
Sent: Tuesday, July 07, 2009 12:26 AM
To: Lars Eggert
Cc: Iljitsch van Beijnum; IETF Discussion Mailing List
Subject: Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two
different threads - IETF Document Format)

On Mon, Jul 6, 2009 at 12:18 AM, Lars Eggert<[email-masked]>
wrote:

> different

What Lars said. -T

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Jul 2009 15:10:03 +0200

> bound the number of XML tags that can contribute to a problem.

Again: it's much easier to test using any recent web browser, and using 
rfc2629.xslt. Just press F5 (refresh) in the browser window, and there 
you go.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Jul 2009 15:30:40 +0200

> rfc2629.xslt. Just press F5 (refresh) in the browser window, and there 

OK, I have been told off-list that this needs more explanation...

rfc2629.xslt implements the xml2rfc vocabulary in XSLT, which all major 
browsers nowadays implement.

Thus, you can simply open the XML in the browser, and let the browser 
convert to HTML.

To do so:

1) Add the XML Stylesheet Processing Instruction to the top of the 
source file, such as in:

   <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

(after the XML declaration, when present)

2) Copy rfc2629.xslt to the folder where the xml2rfc source file resides 
(get it from <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>).

3) Open the XML file in IE/Firefox/Safari/Opera.

More info: <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html>

NOTE: rfc2629.xslt does not support xml2rfc's "include" processing 
instruction, thus external references will only work using the XML 
entity inclusion mechanism (see <http://xml.resource.org/>, "Including 
Files").

BR, Julian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Jul 2009 15:53:56 +0200

On 7 jul 2009, at 15:30, Julian Reschke wrote:

> Thus, you can simply open the XML in the browser, and let the  
> browser convert to HTML.

Notwithstanding everything else I've said, this is pretty cool, makes  
it much easier to find problems in the XML.

Is this kind of stuff covered in the XML2RFC intro at IETF-75?

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 7 Jul 2009 07:54:23 -0600

> rather than optimize for one particular way to interpret the state of 

But as John pointed out, this isn't going to happen unless that group 
can focus on what "the current situation" refers to, and try to solve 
one problem at a time, and stop pretending that ASCII vs. Unicode and 
fixed vs. floating line breaks and ASCII art vs. bitmapped/vector 
graphics and "which tool is best" are all the same issue.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Jul 2009 15:57:51 +0200

Iljitsch van Beijnum wrote:
> Notwithstanding everything else I've said, this is pretty cool, makes it 
> much easier to find problems in the XML.
> 

I think it was mentioned in previous intros, but I'm not sure.

That being said, I'll probably be there, and will be happy to explain 
and demo things if there's time available.

BR, Julian

---

From: Tony Hansen <[email-masked]>
Date: Tue, 07 Jul 2009 12:23:02 -0400

I also had to copy rfc2629-other.ent, rfc2629-xhtml.ent and rfc2629.dtd
into the current directory to get it to work. And Firefox seems to be
pickier than IE about the XML it will accept.

Otherwise pretty cool.

	Tony Hansen
	[email-masked]

Julian Reschke wrote:
> Julian Reschke wrote:
>> Again: it's much easier to test using any recent web browser, and
>> using rfc2629.xslt. Just press F5 (refresh) in the browser window, and
>> there you go.
>>
>> BR, Julian
>> ...
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Jul 2009 18:27:43 +0200

> into the current directory to get it to work. And Firefox seems to be

That hasn't got anything to do with the XSLT, but with the fact that the 
browsers use proper XML parsers, while xml2rfc does not (which really is 
frustrating).

> pickier than IE about the XML it will accept.

Both browsers may differ on how they handle the DTD. If you've got an 
example I should look it, please email it.

> Otherwise pretty cool.

Thanks!

BR, Julian

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jul 2009 16:42:57 -0400

--On Tuesday, July 07, 2009 12:49 +0200 Iljitsch van Beijnum
<[email-masked]> 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) everyone, rather than optimize for
> one particular way to interpret the state of the universe.
> 
> 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 about what is important, about how to count "(pretty
much) everyone", etc., are divergent enough to make an effective
process like the one you outline unlikely.  You believe that
xml2rfc needs to be eliminated, some believe that it should be
made mandatory, others of us believe that it is an extremely
useful tool for those who use it (although it could be improved)
but that requiring it to the exclusion of other tools would be a
mistake.

Similarly, some of us believe that a plain ASCII format with
directly-encoded "hard" line endings is extremely stable as well
as extremely suitable for direct search and extraction of
material (e.g., by copy-and-paste operations).  We do not see
those as being properties of more sophisticated alternatives
unless tools that are specifically matched to those alternatives
are available (and maybe not then).  We draw some comfort from
the facts that it does not have to be interpreted by programs
for display, that it converts to UTF-32 by simple bit padding
and to UTF-8 by doing nothing, and that there is exactly one way
to represent all of the characters it can represent.  Again,
other systems, even native UTF-8, do not have that property (in
the latter case because there is more than one way to represent
the same character, at least prior to normalization).   Others
either accept those considerations or not, but believe that
other considerations are more important.  They may be right,
but, again, I don't see any way in which we are going to reach
agreement that those changes would improve things for almost
everyone.

     john

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Jul 2009 23:01:05 +0200

> process like the one you outline unlikely.

The points that you make in the rest of your message are mostly valid,  
but I think they can be addressed by showing people that if we take a  
few steps in the right direction, they at least get something that is  
better than today, so most people would be at least somewhat happy  
with that.

I truly believe it can be done, and I'd be happy to take the time to  
make a start in Stockholm if anyone else is prepared to invest time.

(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.)

---

From: Tim Bray <[email-masked]>
Date: Tue, 7 Jul 2009 14:12:42 -0700

On Tue, Jul 7, 2009 at 1:42 PM, John C Klensin<[email-masked]> wrote:

> 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) seems unlikely, but apparently there are a
large number whose experience of online information differs
dramatically from the people I hang out with.

> material (e.g., by copy-and-paste operations).

As to copy-and-paste, your statement is probably not a majority
viewpoint.  A high proportion of my copy-and-pastes are either into
something that'll be delivered via browser (the line-ends silently
vanish) or in an email (where they cause unpredictable breakage
depending on the settings of my email authoring and the recipient's
email reading software.

> We draw some comfort from
> for display,

I really hope you didn't mean what that sentence apparently says. No
file may be displayed without the invention of one or more computer
programs.  I think that what you're saying is that IETF legacy
plain-text displays correctly in a terminal emulator (and incorrectly
in a browser).  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.

 -T

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 7 Jul 2009 17:40:29 -0400

> 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 haven't yet heard any *compelling* arguments against the use of plain-text
(ASCII or UTF-8) as the default and normative representation format for
RFCs.  Arguments, yes; *compelling* arguments, no.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Jul 2009 10:44:53 +1000

> pickier than IE about the XML it will accept.

I had wierd results with the following just printing out "Zone" and
not the rest of the lines in the table.

        <texttable>
          <ttcol align="left">Zone</ttcol>
          <c>10.IN-ADDR.ARPA</c>
          <c>16.172.IN-ADDR.ARPA</c>
          <c>17.172.IN-ADDR.ARPA</c>
          <c>18.172.IN-ADDR.ARPA</c>
          <c>19.172.IN-ADDR.ARPA</c>
          <c>20.172.IN-ADDR.ARPA</c>
          <c>21.172.IN-ADDR.ARPA</c>
          <c>22.172.IN-ADDR.ARPA</c>
          <c>23.172.IN-ADDR.ARPA</c>
          <c>24.172.IN-ADDR.ARPA</c>
          <c>25.172.IN-ADDR.ARPA</c>
          <c>26.172.IN-ADDR.ARPA</c>
          <c>27.172.IN-ADDR.ARPA</c>
          <c>28.172.IN-ADDR.ARPA</c>
          <c>29.172.IN-ADDR.ARPA</c>
          <c>30.172.IN-ADDR.ARPA</c>
          <c>31.172.IN-ADDR.ARPA</c>
          <c>168.192.IN-ADDR.ARPA</c>
        </texttable>

Also how do you do the equivalent of "&nbsp;&nbsp;&nbsp;&nbsp;" in
xml?
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Jul 2009 10:52:13 +1000

>           <c>168.192.IN-ADDR.ARPA</c>

I should add if I add a second column the full table is discplayed.

> > > More info: <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html
> >
> > >

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jul 2009 21:02:46 -0400

--On Tuesday, July 07, 2009 14:12 -0700 Tim Bray
<[email-masked]> wrote:

> I really hope you didn't mean what that sentence apparently
> says. No file may be displayed without the invention of one or
> more computer programs.  I think that what you're saying is
> that IETF legacy plain-text displays correctly in a terminal
> emulator (and incorrectly in a browser).  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.

With the understanding that I'm not a heavy Linux or Unix user
on client machines but in the hope that the community will
understand the reference, let me restate the comment as follows:

If I start with a plain-ASCII string with line boundaries in it
if needed, I can get it plausibly (although perhaps not
optimally) rendered by  piping it to the user's display
terminal, e.g., with
   cat(string)
or
   printf(string)

Those functions, in addition to being extremely simple, tend to
be basic functions of operating systems or APIs to those basic
functions.

By contrast, sensible rendering of, e.g., HTML, requires that I
recognize the material as HTML and have a sufficient HTML
interpreter to distinguish between what is to be displayed and
what are instructions and perhaps what to do with those
instructions.  That seems to me to be a significant and
substantive difference.  YMMD.

   john

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Jul 2009 09:00:21 +0200

>           <c>17.172.IN-ADDR.ARPA</c>

That's a bug in the texttable processing code, which I'm currently 
fixing (download the new version later today...). Thanks for the report.

> Also how do you do the equivalent of "&nbsp;&nbsp;&nbsp;&nbsp;" in

If you reference the rfc2629.dtd (as shipping with xml2rfc.tcl), it 
should work out of the box, as rfc2629-xhtml.ent defines that entity.

Otherwise, just substitute with: "&#160;&#160;&#160;&#160;".

Out of curiosity: where do you need that?

BR, Julian

---

From: Stefan Winter <[email-masked]>
Date: Wed, 08 Jul 2009 10:03:51 +0200

Hi,
> 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 advocate (which I
absolutely don't mind playing here) could say that the restriction to
ASCII *prevents* expressing oneself in the full bouquet of English
language; unfortunately, English language is mandatory for IETF
documents. So, staying with ASCII would require a reformulation for IETF
language from

"English"

to

"English words which can be expressed in ASCII encoding"

Example?

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

http://en.wikipedia.org/wiki/Naive
http://en.wikipedia.org/wiki/Coup_d%27Etat

At least the first one has been used in an I-D from the IAB very
recently
(http://www.ietf.org/internet-drafts/draft-iab-idn-encoding-00.txt). It
used the alternative spelling with a normal i; the other spelling was
obviously impossible for the reasons we are discussing in (parts of)
this thread. Maybe the author wanted to use that alternative spelling
anyway, but maybe he was forced to use it even though it hurt his eye
and he is now drowning in grief over the butchering of language he was
forced to execute in order to publish his work. We will never know for
sure; unless of course the author tells us about his feelings on this
list :-)

Let's give ASCII its long-overdue coup de grâce (
http://en.wikipedia.org/wiki/Coup_de_grace ).

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Jul 2009 18:16:08 +1000

> fixing (download the new version later today...). Thanks for the report.

Will do.

> Out of curiosity: where do you need that?

IPv6 reverse addresses are long.  Break and indent.  If you have
a better way I would be happy to hear it.

        <texttable>
          <ttcol align="left">Zone</ttcol>
          <c>0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\</c>
          <c>&nbsp;&nbsp;&nbsp;&nbsp;0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</c>
          <c>1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\</c>
          <c>0&nbsp;&nbsp;&nbsp;&nbsp;.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</c>
        </texttable>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Jul 2009 10:30:41 +0200

>> fixing (download the new version later today...). Thanks for the report.

(I just published the new release)

>           <c>0&nbsp;&nbsp;&nbsp;&nbsp;.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</c>

Ok, that's an interesting case where non-breaking spaces are needed as a 
last resort.

Also, this case would be simpler if <c> allowed <vspace>, so you 
wouldn't need to split the contents into two table cells (which *will* 
look weird when read in HTML...).

...but then, we may be getting off-topic here, so if people want to 
discuss the xml2rfc vocabulary or the tools in more details we probably 
should move over to the xml2rfc mailing list.

BR, Julian

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 8 Jul 2009 12:43:29 +0300

> I bought the TeXbook in 1989 and liked it, despite the learning curve.

Did you read the entire TeXbook and only then start TeXing ?
Although I have read every page several times,
I never set out to do so. For me it was a quick scan,
modification of existing files, and then reading as needed.

> amounts to cheating), so I dropped back to plain TeX. 

Nothing is impossible. You just have to write your own style files (in TeX).
I have written several completely new LaTeX styles, you can do
anything that TeX allows (that is, anything at all).
In fact, I wrote a style for Hebrew Language PhD theses - 
that required reversing the line direction, different line splitting, etc.

> (for someone not using a particular universities infrastructure).

Most journals or textbook publishers that accept TeX in any form
will supply you with their style file. The beauty is that you can
prepare your text and then slap on the style at the last moment
(or if one journal rejects your paper, you can easily prepare it for submission
to another journal). 

I considered writing a style for IDs and RFCs.
But although the initial effort would not be major,
I don't want to be stuck for life with maintenance.
Kudos to those who maintain the xml2rfc tools.

Y(J)S

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 8 Jul 2009 05:50:58 -0400

> words from French, but nontheless English words.

Yes, but in importing such words into English, we're perfectly happy to
strip off the "decorations" that you mention.  For example, when I look up
naïve in Webster's New Universal Unabridged Dictionary (a large book, not an
online service) it lists both the decorated and undecorated versions, with
the undecorated version appearing first, indicating the more common usage.

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Jul 2009 09:02:22 -0400

--On Tuesday, July 07, 2009 23:01 +0200 Iljitsch van Beijnum
<[email-masked]> 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 over the
years suggests that this particular soup retains its
temperature, and perhaps becomes hotter, the longer it
circulates around the table.

    john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 5 Jul 2009 08:02:33 -0400

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
Wesley did have a somewhat weird review format but the final book is
professionally typeset by a designer who had a clue about typography.

On Tue, Jun 30, 2009 at 4:15 PM, james woodyatt<[email-masked]> 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.
>
>
> --

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

---

From: Russ White <[email-masked]>
Date: Tue, 07 Jul 2009 10:23:37 -0400

> something that nobody else finds difficult.

I don't mind the XML part of writing the drafts, it's just annoying that
so few DTDs are available to edit the things. There are a ton of
commercial XML editors out there--Word, Dreamweaver, and many others.
But, not being an XML expert, I don't know how to get a DTD to work in
any of these software packages, so editing the XML side is a matter of
hand coding it. <blech>

I think a lot of the problem is the issues with editing these things. If
we had a DTD that worked in other pieces of software, it could be
converted using commonly available software into text formats. The
problem, from my perspective, isn't the format, it's the lack of tools
to work in that format, at this point.

:-)

Russ

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 08 Jul 2009 07:49:17 -0700

>>>>> On Mon, 6 Jul 2009 10:18:14 +0300, Lars Eggert <[email-masked]> said:

LE> I'm fully open to trying something new once someone creates a
LE> different ("better") tool, but until then, xml2rfc is OK.

I'd even argue that the xml2rfc language is pretty good and fairly
flexible.  I've run into a number of things I'd like to force it to do
that are mildly difficult, but in the end I've been happy with the
language.

It's the tool that needs a rewrite, IMHO.  Don't get me wrong, it's
taken us a long way and we wouldn't be as far forward in interoperable ID
authorship if it weren't for the existing tool.  However, like all good
prototypes eventually you need to take what you've learned and rewrite
it to fix the problems.  I've been tempted to take on the task myself,
but don't have the allocated time to make it happen.  (and it certainly
wouldn't be in TCL, as that's about my least preferred language of the
large number of languages I've written code in; no offense to TCL lovers).
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: [email-masked]
Date: Wed, 08 Jul 2009 10:38:44 -0700 (PDT)

> commercial XML editors out there--Word, Dreamweaver, and many others.

That's actually part of the problem - there are so many XML-capable
tools that providing directions for even a reasonable subset would be
very challenging.

> any of these software packages, so editing the XML side is a matter of

I'm a little unclear on how configuring an XML editor to know about a DTD, or
Schema, or Relax grammar is a matter of having sufficient XML expertise. It's
mostly a matter of knowing how to use your tools. If this is truly hard to do
it's a problem with the documentation for whatever tool you're using.

FWIW, in many cases it's simply a mattter of parking the DTD or Schema in the
same directory where your XML sources are.

I use four different XML-aware editors, two of them - BBEdit and Exchanger -
quite regularly, and I've had no real problems getting this set up. The (free)
BBedit XML validation plugin is a little annoying in that it puts the material
to validate in a temporary file before invoking the validator, meaning the
coresident file trick doesn't work. But a simple google search turns up a
reasonable solution - use a URL with an explicit path in the DOCTYPE
declaration.

Exchanger handles this especially well, I think. Most of the time it finds the
DTD without any trouble, but when it can't it simply prompts for the location,
and remembers it after that. It also supports specifying the location in the
source file if that's more to your taste.

> to work in that format, at this point.

I've had no trouble using either the DTD or the Relax grammar that comes with
the xml2rfc distro.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 08 Jul 2009 12:17:56 -0700

Russ White wrote:
>     If
> converted using commonly available software into text formats.

What is supplied with xml2rfc works fine with other pieces of software, per 
Ned's response.

> The

There are plenty of tools that work just fine with it.

d/
-- 

   Dave Crocker

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 9 Jul 2009 15:16:48 +0300

Patrik,

> Problem with LaTeX and TeX is the need for class libraries, 

How is that different from needing the latest tcl code for xml2rfc ?

> and the lack of agreed upon way of distributing a 
> LaTeX/TeX file with the class files needed (part from what is "standard"), 
> or lack of automatic tools that include needed things from the class files to the source file.

Still nowhere near the combination of opaque processing instructions needed for xml2rfc.

Something like \documentclass[std,trust200902]{RFC} at the top of the file
is all that would be needed.

Y(J)S

---

From: Russ White <[email-masked]>
Date: Wed, 08 Jul 2009 20:13:18 -0400

> What is supplied with xml2rfc works fine with other pieces of software,
> per Ned's response.

Perhaps I should email Ned.... I've tried pulling the DTD into
Dreamweaver several times, with no success. I did email the list once,
and the response I received was along the lines of, "if you get that
working, a lot of people would be happy." I never received a response
saying, "it works, and this is the way you need to pull the DTD in."

Of course, we might be talking about two different things. You can use
Dreamweaver as a text editor on the DTD, but you can't do the same thing
you do in XMLMind, which is to have the sections set out in the other
editing modes. I can use emacs if I'm going to have to memorize all the
sections, and how to put them together--no need to use Dreamweaver as a
text editor.

:-)

Russ

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sun, 12 Jul 2009 13:46:26 +0100

I just *knew* it was a mistake to "Leave this thread for later ..."

> text with spaces and control characters to do page formatting as our  
Hmm.  Generalisation is good.  Semantic markup is also good.  But  
ASCII has a good standing and a thoroughly good reason for being, and  
probably continuing to be, a canonical format.  We are at nobody's  
mercy.

Now, I'm not for disputing the usefulness of XML or whatever other  
format becomes popular.  For HTML, for example, my screen reader has  
keystrokes to jump to the next heading, or to list them for me to  
select.  I would want whatever we choose as the alternative markup  
stored in the same repository, and to have the same chances of being  
used as the ASCII by those who need preprocessed output, for whatever  
purpose, on whatever device.  I think this is somewhat optimistic,  
though; either it creates more work for people who have quite enough  
to do already just writing this stuff, else it precludes many existing  
and perfectly good historical documents whose chance of conversion to  
other formats now are somewhat limited by, for example, wishwash in  
the current format variations.

On the other hand, as a writer I am not exactly enamoured by the  
choices available.  I just want to write.  I'm blind; without my £5000  
(sorry, l5000 :-) ) braille display on hand, and without brltty on  
Linux, I cannot feel my way around the document; get the indentations  
right, the line count right, the line width right.  And even if I  
could, it's very tiresome.  xml2rfc does peculiar things all of its  
own; even as a Tcl lover I'm not happy with its weird tendency to add  
extra whitespace where it shouldn't be, or to make bold assumptions  
about the author's ecstatic desire to write perfect XML, or the  
somewhat less semantic HTML it generates, or ...  I just want to  
write, straight long lines, one a paragraph, with YAML-style section  
delimiters, no boilerplate.  All that pretty-printing is someone  
else's problem, I just want to put an idea into a starting-point  
draft.  So I'd be much gratified if somebody could, or could give me  
the encouragement to, write such a scheme up and then code it,  
probably in Tcl.

>>> As Dave put it, the current RFC format is "unfriendly,  
>>> unnecessary, possibly unethical and just plain wrong." I'd remove  
>>> the "possibly."
>>
>> of having fixed line and page breaks and the lack of non-7-bit- 
>> ASCII characters.
>
> You bet it goes further: The current format is a horror to anyone  
> who has to "read" the document on anything that does not visually  
> display 80 columns of fixed-width text. Try "reading" the text on a  
> small handheld device. Try doing so with a text-to-speech  
> application. Try magnifying it using apps meant for folks with  
> limited vision. We have the ability to create text in a format that  
> is easily interpreted by all of these devices and presented to the  
> user with no loss of information. Using a page-layout format for our  
> standards when page layout is completely unnecessary is at a minimum  
> "unfriendly" to folks who want to use such devices, and (given that  
> it is unnecessary to use page-layout) it is downright unethical and  
> wrong to make it harder for folks who must use such devices.
>
Wo!  Brave assumptions!

For me, ASCII is *why* I read IETF standards, almost in preference to  
other organisations.  Clean, one-spec-a-file, consistent naming, can  
be further preprocessed if desired (as above: to an extent), 7-bit for  
display using all known braille codes on all braille displays.  Truly,  
as I've said, ASCII is a splendid lowest-common-denominator choice of  
format.  About the only hindrance for text-to-speech and braille alike  
is the headers and footers; they make no sense even on common textmode  
terminals, interrupt the perfect flow of speech for no reason, and are  
just annoyingly redundant.  Remove those, and I think we have a  
perfect ASCII representation.

> Not being able to use characters in documents outside of the US- 
> ASCII set is inconvenient (when they are part of the data stream of  
> a protocol you wish to describe) and unfriendly (when the personal  
Hmm, transition to UTF-8?  Readily available tool to remap UTF-8  
common glyphs to flat ASCII representations?

> Images are *way* down the list of needs.

Correct.  Box drawings are accessible with a bit of imagination, but  
they're not worth the bytes they take up; if a spec doesn't (or can't)  
adequately express itself in beautiful English, it should go straight  
back into community circulation till it does.  Technical unambiguity  
is key.  Anything done to detract from it, including pretty pictures,  
isn't any good for anything standard.  It follows that reduction to  
algorithmic building blocks is as achievable using text or pseudocode  
as any amount of flow charts or whatever the current eye-catcher is.   
(I did mention I'm blind, but if you're not convinced, consider that  
drawings of any kind are generally a nuisance to me, so simply  
understanding a specification could be difficult to people with visual  
impairment or text display requirements different than monospace for  
whom the graphic has no meaning.  I need my braille display [bar  
backslash dash slash ... won't do it for me] and then, with one line  
of cells and only 32 of them, somehow have to understand it.   
Sometimes can, sometimes can't, often not any the wiser.)

> the list. Everything else is extra.

I have no conviction.  I'll let others try to spell it out.  I don't  
imagine any big changes soon, though.

Cheers,
Sabahattin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Jul 2009 00:19:10 -0400

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 just by asking.

Another approach would be to use vector graphics markup which is XML
for the diagrams.

Another would be to simply stick with the ASCII art.

On Thu, Jul 2, 2009 at 11:05 AM, Stewart Bryant<[email-masked]> wrote:
>>> HTML
>  files.