Subject: RE: ASCII art

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 23 Nov 2005 05:34:31 -0800

But there is a teensy inconsistency in an argument that goes 'we must
have plaintext for accessibility' then ignores the language and
character set issues as unimportant.

The real reason to change the RFC format is that the IETF needs to make
a visible sign that it is capable of institutional change. A lot has
happened in the past three years, there has been a significant turnover
in IETF management. The old boys club (and it was mostly boys) has been
largely broken up. The IAB and IESG are now subject to de-facto term
limits.

Institutions that do not constantly renew and re-invent themselves
become obsolete. The IETF is a technology organization, if its
communications tell the world that it is wedged in the 1960s it will be
very difficult for it to be relevant in the modern Internet which has
over a billion users.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dave Aronson (re IETF)
> Sent: Wednesday, November 23, 2005 8:20 AM
> To: [email-masked]
> Subject: Re: ASCII art
> 
> JFC (Jefsey) Morfin [mailto:[email-masked]] writes:
> 
>  > This is here where however we have a real practical 
> problem. Only  > standards and procedures written in English 
> can be authoritative and  > Drafts needs to be designed using 
> the ASCII charsets. This is  > acceptable when only English 
> speaking engineers and reading users are  > concerned. This 
> represents less than 1/4 of the world population.
> 
> But the entire world population isn't all equally involved in 
> designing and running the Internet, or for that matter even 
> using it.  (Egalitarians may claim they SHOULD be, but since 
> they AREN'T for now, and changing languages is IMHO extremely 
> unlikely to change that, we can ignore that for now.)  
> English is the "lingua franca" of the modern world, so to 
> speak.  Therefore, to paraphrase Churchill, English is the 
> worst possible language for Internet protocol documentation, 
> except for all the others.
> 
> -Dave
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Nov 2005 15:15:18 +0100

> very difficult for it to be relevant in the modern Internet which has

The IETF is the *Internet* Engineering Task Force not some document
formatting engineering task force.  We don't have to lead with our chins
here.  If some open standard is accepted for document processing, I'm
happy to use it once it is clear that it will stand the test of time.  I
certainly wouldn't bet the bank on the current OpenDoc standard.

In the meantime I will settle for seeing the IETF reinvent itself by
continuing to produce relevant work in the areas we claim expertise.
That generally involves lots of ones and zeros on wires, which can
easily be represented and described in English with ASCII.  And if
someone wants to translate that ASCII into any other language, I say
"Have at it!"  Or... if someone wants to develop source in any other
language and then translate into English, fine with me as long as we
understand that the English is normative in the end.

Eliot

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Nov 2005 09:58:23 -0500

Let me try a concrete proposal:

- All document editors MUST submit XML format to the RFC editor. 
(Mostly) semantic markup makes a lot more sense than presentation 
mark-up as it makes it possible to translate the format into a variety 
of output formats. This format is the long-term archival format, as it 
seems highly unlikely that the world will suddenly forget how to 
interpret XML in any timeframe we care about. The schema/DTD is 
documented in ASCII, so if an alien invaders take over the (IETF) world, 
they can bootstrap, as long as they can figure out English.

- Authors can use Word (or other formats), but must use a Word style 
that makes automatic translation to the 2629 XML possible. I don't know 
enough about Word internals to know if Word styles are sufficient to 
make this possible today, but with a bit of semantic mark-up (e.g., 
surround the abstract with tags), this shouldn't be too hard.

- The XML version is made available to the public and is the 
authoritative version, in addition to the traditional ASCII version. The 
XML version can then be used to generate more readable and printable 
versions using XSLT or other tools. I suspect generating a PDF version 
wouldn't be hard, either. These presentation formats can then evolve as 
people care to write tools.

- The XML format also allows the use of UTF-8, for use in examples, not 
as normative text. The translation to ASCII can automatically insert U+ 
or other appropriate elements.

- SVG or a subset thereof is authorized for illustrative (non-normative) 
diagrams. The XML schema already supports the ability to link 
alternative renditions of graphics, so this requires minimal effort.

I think this would actually put us ahead of standards organizations that 
use presentation-oriented document formats that are hard to transform 
into alternative renditions now or in the future. None of the above 
requires a major change in process, rules or procedures. The only 
'tools' effort would be to create a suitable DOC template. Given that 
converting existing late-stage drafts may be onerous, this can be phased 
in over time.

Henning

---

From: Ted Faber <[email-masked]>
Date: Wed, 23 Nov 2005 07:22:50 -0800

On Wed, Nov 23, 2005 at 05:34:31AM -0800, Hallam-Baker, Phillip wrote:
> a visible sign that it is capable of institutional change.

Boy, I'm hoping that was a typo or rhetorical or something.  Because as
written it's pretty poorly reasoned.  I'd prefer to make institutional
changes only when they're needed for the good of the institution, not to
prove that there's working process machinery.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 23 Nov 2005 17:07:06 +0100

--On onsdag, november 23, 2005 09:58:23 -0500 Henning Schulzrinne 
<[email-masked]> wrote:

> - All document editors MUST submit XML format to the RFC editor. (Mostly)
> semantic markup makes a lot more sense than presentation mark-up as it
> makes it possible to translate the format into a variety of output
> formats. This format is the long-term archival format, as it seems highly
> unlikely that the world will suddenly forget how to interpret XML in any
> timeframe we care about. The schema/DTD is documented in ASCII, so if an
> alien invaders take over the (IETF) world, they can bootstrap, as long as
> they can figure out English.

this is possible to say. I don't know if it's acceptable.... for instance,
XML2RFC versions invoke boilerplate, they don't contain it; are there legal 
dragons here, or is the naming of a publicly-identified DTD/schema enough 
of an invocation of legalisms?

> - Authors can use Word (or other formats), but must use a Word style that
> makes automatic translation to the 2629 XML possible. I don't know enough
> about Word internals to know if Word styles are sufficient to make this
> possible today, but with a bit of semantic mark-up (e.g., surround the
> abstract with tags), this shouldn't be too hard.

has anyone proved by demonstration that this is possible?
It doesn't have to be part of the rules...

> people care to write tools.

You can't have two authoritative versions..........

> or other appropriate elements.

How would the translation know when U+ is appropriate...?
> diagrams. The XML schema already supports the ability to link alternative
> renditions of graphics, so this requires minimal effort.

I suspect that there are dragons here too.... but I've never tried to do 
anything with SVG, so I don't know the tools for it....

> requires a major change in process, rules or procedures. The only 'tools'
> effort would be to create a suitable DOC template. Given that converting
> existing late-stage drafts may be onerous, this can be phased in over
> time.

Just nibbling at the details.... the big question is whether this will be 
felt as help or hindrance to the people who do the real work...

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Nov 2005 04:01:45 +0900

Henning Schulzrinne wrote:

> This format is the long-term archival format, as it 
> interpret XML in any timeframe we care about.

Can you say TeX?

						Masataka Ohta

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Nov 2005 14:24:53 -0500

> It doesn't have to be part of the rules...

I don't think translating any Word style that kind of looks like an I-D 
is likely to be feasible.

A slightly different question is whether we can come up with a Word 
template that makes this feasible or at least minimizes the manual 
conversion labor at the end. I don't see why asking authors for another 
30 minute of XML tweaking after 3 years of document editing is 
excessive. The IETF is not a vanity press, and the authors serve the 
community, not the other way around.

> You can't have two authoritative versions..........

As long as the text has been known to have been generated from the XML, 
this is not fundamentally different from the PDF versions of ASCII that 
have been mentioned on this list. Nominally, the XML would be 
authoritative if available, but for all practical purposes, the ASCII 
would be sufficient as a working document. I don't see that this is a 
real, practical problem.

> How would the translation know when U+ is appropriate...?

This is probably a side issue, but the assumption would be that you'd 
only be allowed to put in UTF-8 if indeed the U+ notation can be 
substituted there.

> anything with SVG, so I don't know the tools for it....

I'm sure we can find reasons not to try anything new. We could take an 
attitude that experiments might help us decide whether these are real 
problems. I'm not very good at anticipating all the problems - and 
comparing any problems to the positive effects that change might bring.

> Just nibbling at the details.... the big question is whether this will 
> be felt as help or hindrance to the people who do the real work...

One example of the cost of doing business in the old way: I know that 
the current system of only having ASCII available is a pain in the neck 
when you try to write the "bis" version, requiring manual conversion and 
hoping that nothing got lost in the manual translation. Often, we have 
to back-port AUTHOR48 changes into the author-available XML-RFC (if that 
can be located after a few years) when it's time to work on the "bis" 
version. This is tedious and error-prone.

Henning

---

From: Ted Faber <[email-masked]>
Date: Wed, 23 Nov 2005 11:36:22 -0800

On Wed, Nov 23, 2005 at 02:24:53PM -0500, Henning Schulzrinne wrote:
> conversion labor at the end. 

http://www.ietf.org/internet-drafts/draft-touch-msword-template-v2.0-03.txt

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 23 Nov 2005 20:43:41 +0100

(trimming this branch of the thread to only one point...)

> comparing any problems to the positive effects that change might bring.

To be specific.... if you can make up an example XML I-D with an embedded 
SVG diagram, and tell me which tool I can use to manipulate the diagram 
inside the XML I-D, I'll have a much bigger basis (1 example rather than 
zero) on which to evaluate whether I think it's feasible or not.

I'm hesitant to *mandate* something that I don't even know how to *try*, so 
I prefer to do the trying first... or point to people who have tried it 
successfully.... that may be the only point I'm making...

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Nov 2005 13:54:49 -0800

> http://www.ietf.org/internet-drafts/draft-touch-msword-template-v2.0-03.txt

Thanks for posting the pointer, Ted.

To others:

	I'm seeking help with two aspects of this template:

	a) being able to generate ASCII printer output from Macs and
	under OpenOffice
		the current template has been tested only under
		Office XP with the "Generic / Text Only" print driver

	b) being able to generate XML output
		the current version can print to any printer,
		or output HTML,
		and can output ASCII text as above,
		but needs to be augmented to dump XML

		(NOTE: I'm still unconvinced of the utility of this
		exercise; at the end of the day, most of what I need
		a document to do I get out of .txt, .html, and .doc,
		including access to databases of BibTex references
		via EndNote)

If any of you would like to help, drop me an email (ASCII, please ;-)

Joe

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Nov 2005 17:01:39 -0500

> 		including access to databases of BibTex references

Unless you are proposing to keep DOC files as permanent references, I 
don't see how you can get reasonable (rather than guess-work) HTML back 
after the RFC editor is done with the document. This approach would only 
work if all consumers of the document use Word, including future editors 
of follow-on ("bis") versions. Then we might as well join 3GPP and 
declare Word to be the official format of the IETF.

That said, I'm hoping that there are Word experts out there who can help 
Joe...

Henning

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Nov 2005 18:27:08 -0500

> If any of you would like to help, drop me an email (ASCII,

Joe,

Getting a simulation of XML out can be done simply by doing a
"save as" from the version of Word included in Office
Professional 2003.  The difficulty is that it is
XML-used-as-format-markup, not XML-as-generic markup, and
"MS-XML" at that (i.e., if there is a defined DTD or Schema, it
appears to be only available to and manipulable by their
proprietary tools (and license-prohibited against reverse
engineering).

I tried to do that conversion with a version of RFC2821bis that
was composed using the  RFC3285 template plus a few corrections/
twitches suggested by colleagues at Microsoft for better Office
2003 compatibility.   I can show pictures of  the dents made in
the nearest brick wall by my head, a problem that was aggravated
by the fact that introducing either the 3285 template or yours
into my environment screws up the normal Word working
environment, which I need to keep pretty standard.

RFC2821bis was finally converted to rfc2xml format on a
one-time, no going back, basis by Tony Hanson.  I'm not sure of
exactly what he did, and suspect it involved some hand tuning,
but I at least ended up with something I can work with, get into
I-D form, and revise as I go along.  The difficulty, of course,
is that I lost all of the finely-tuned Word change tracking and
comment stuff which was why I used Word in the first place: Tony
converted the comments to XML comments, but that just isn't the
same thing.

Microsoft announced yesterday that Word 12 (Office 2006?) will
have an XML output/ input/ archival format that they are going
to make public and submit to ECMA for standardization.  Whether
that will actually be any better or is just a ploy to keep a few
states (including Massachusetts) from standardizing on OpenDoc
is something that we won't know until the next version of Office
and the draft spec actually appear.

    john

---

From: Bill Fenner <[email-masked]>
Date: Wed, 23 Nov 2005 16:29:53 -0800

> zero) on which to evaluate whether I think it's feasible or not.

Harald,

  This is not quite embedded, but that's a detail:

  I created a random svg file with Inkscape, a cross-platform svg
drawing app.  I created an <artwork> element with src="pretty.svg"; it
displayed inline in the cross-platform xxe XML editor using my xml2rfc
plugin (but no inline editing of the graphic) and converted to PDF
reasonably well:

http://electricrain.com/fenner/tmp/svg-demo.xml is the draft;
http://electricrain.com/fenner/tmp/pretty.svg is the picture;
http://electricrain.com/fenner/tmp/XMLEditorScreenSnapz011.png
http://electricrain.com/fenner/tmp/draft-my-document-00.pdf

(OK, so the graphic is cut off in the PDF, but isn't in the preview or
in the graphic editor.  I don't know exactly whose goof that is --
Inkscape shows it properly, as does Batik; both Apache FOP 0.20.5 and
Adobe's ancient SVG plugin show it cut off.  Perhaps someone who knows
more about SVG can talk about this.)

  Bill

---

From: Tony Hansen <[email-masked]>
Date: Wed, 23 Nov 2005 22:48:31 -0500

John, I also started by looking at the XML output from MS Word. I had
grandiose ideas of writing a converter from that XML form to something
closer to the XML2RFC form, but gave up because it was more daunting
than expected. After that I wound up using lots of emacs macros
operating on the raw text, and then used hand tuning to add in the
comment information.

	Tony Hansen
	[email-masked]

John C Klensin wrote:
> ...

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Nov 2005 23:11:25 -0500

--On Wednesday, 23 November, 2005 22:48 -0500 Tony Hansen
<[email-masked]> wrote:

> John, I also started by looking at the XML output from MS
> Word. I had grandiose ideas of writing a converter from that
> XML form to something closer to the XML2RFC form, but gave up
> because it was more daunting than expected. After that I wound
> up using lots of emacs macros operating on the raw text, and
> then used hand tuning to add in the comment information.

Kind of what I expected given my attempt to investigate a
similar converter.  Thanks again for the effort and results.

best,
    john

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Nov 2005 20:57:18 -0800

> proprietary tools (and license-prohibited against reverse

That's the rub. There's allegedly a way to import DTDs into Word and
apply them, but I haven't figured out how to use them.

> converted the comments to XML comments, but that just isn't the

Yeah - just outputting XML isn't enough. I need to be able to import it
as well. As per below, I thought Word 2003 was supposed to be capable of
this - though, as below, full transition to XML is 'forthcoming'. As
with the custom DTDs noted above, it's not clear that's going to help
us, even if the spec is open. This thread was talking about the IETF's
DTD, which wasn't designed with word processors in mind.