Subject: RE: ASCII art

From: "Gray, Eric" <[email-masked]>
Date: Wed, 23 Nov 2005 11:26:30 -0500

I would find this problematic.  I often submit in the "final"
form because I started in the "final" form.  I have no *roff
or XML form to submit. 

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Henning Schulzrinne
--> Sent: Wednesday, November 23, 2005 9:58 AM
--> To: Eliot Lear
--> Cc: Dave Aronson (re IETF); [email-masked]
--> Subject: Re: ASCII art
--> 
--> 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
--> 
--> _______________________________________________
--> 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: "Spencer Dawkins" <[email-masked]>
Date: Wed, 23 Nov 2005 11:09:28 -0600

(With some hesitation, but if we're discussing a specific proposal, I guess 
this is more than just cycling)

> form because I started in the "final" form.  I have no *roff

Well, this can go a few different ways:

- "the authors must submit XML2RFC or plain text", where what you submit is 
what's used as the canonical source, or

- We can assume that an author of any draft that genrates any interest can 
dragoon someone among the thousands of IETF participants to spin plain text 
as XML2RFC, at some point in time (note that we practice the reverse art 
today; anyone wanting to modify a specification will often start out with 
the plain text of an I-D or an RFC and reverse-engineer it into XML2RFC, or 
into nroff, or into MS-Word, so the burden is already "out there", and we're 
just talking about whether we inflict it on the original author, or on 
subsequent authors), or

- We can say that it's time to require XML2RFC for all drafts.

I wasn't there, at the time, but am interested in the early history of 
programming languages, and you read about a LOT of resistence to the use of 
high level languages by programmers who already knew assembler. At some 
point, most shops said, "it's time to change, for most programs, because 
high level languages are good enough in most cases, and are easier for 
maintainers to maintain", but that trend happened over something like a 
generation or two of programmers, and I'm sure there are still people who 
program in assembler today because that's what they know.

This discussion seems quite like that discussion.

Spencer

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Nov 2005 09:59:15 -0800

> - We can say that it's time to require XML2RFC for all drafts.

there is a variant of this that i think i like:

do not impose this switch onto those submitting, but change the formatting 
language used by the rfc editor to be xml2rfc.

so, submissions in xml2rfc are highly welcome, but pure text is still 
welcome, with hand-conversion by the editor staff.

so i guess the bit that would be visible to submitters is permitting ONLY 
pure text or xml2rfc submission formats. no submissions in 1970's formatting 
languages...

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

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

I personally would welcome any pragmatic approach that maximizes the 
long-term usefulness of our output. I hope we have general agreement 
that a structured document format is better long-term than any 
unstructured, presentation-oriented format, be it ASCII, Word or PDF. 
The latter all lose information that then has to be manually added later 
or guessed, with some probability of error, by tools.

Beyond that, we can be pragmatic and rather than fight a small, but 
determined, minority, hope that almost all drafts will be available in a 
content-oriented format that can be easily transformed. That certainly 
beats another round of IETF list philosophy discussions and 0% availability.

As a community, we need to distinguish what works for the vast majority 
of contributors and for our "customers" (implementors, readers) from 
what's convenient for some subset of authors. Good organizations serve 
their customers and their long-term interests, not primarily the 
convenience of their own staff.

I'd much rather move now to some version of strong encouragement of XML 
submission. This encouragement can take multiple forms: For example, I 
see nothing wrong with a WG or area deciding that all of their WG drafts 
will be kept in XML, since they might value the long-term usability of 
their output. (Drafts now routinely cycle through "bis" stages and the 
original editor may not be the "bis" editor. Thus, having the 
convenience of the current editor outweigh the long-term cost to the 
working group just doesn't seem right.)

Summary of suggestions:

- Official statement of encouragement from the IESG that WG drafts 
submitted for IESG action SHOULD be in XML-RFC format when being 
submitted (but can be in any format the working group feels like and the 
I-D editor accepts during the early stages).

- Allow submission of XML-RFC format to the I-D editor, as part of the 
automation of that part of our process.

- (Semi-serious) Have an earlier IETF cut-off date for I-Ds in ASCII, 
since it takes longer to automatically check them for compliance. This 
will solve our format problem in one IETF round :-)

- Making XML-RFC versions of existing or new RFCs available to the public.

Henning

Spencer Dawkins wrote:
> (With some hesitation, but if we're discussing a specific proposal, I 
> guess this is more than just cycling)
> 
> 
> - "the authors must submit XML2RFC or plain text", where what you submit 
> is what's used as the canonical source, or
> 
> - We can assume that an author of any draft that genrates any interest 
> can dragoon someone among the thousands of IETF participants to spin 
> plain text as XML2RFC, at some point in time (note that we practice the 
> reverse art today; anyone wanting to modify a specification will often 
> start out with the plain text of an I-D or an RFC and reverse-engineer 
> it into XML2RFC, or into nroff, or into MS-Word, so the burden is 
> already "out there", and we're just talking about whether we inflict it 
> on the original author, or on subsequent authors), or
>

---

From: Tony Hansen <[email-masked]>
Date: Wed, 23 Nov 2005 13:47:40 -0500

> will solve our format problem in one IETF round :-)

I love it!

> - Making XML-RFC versions of existing or new RFCs available to the public.

absolutely!

The RFC Editors actually have source versions of most existing RFCs,
either as nroff or xml. They're just not easily accessible; you have to
ask to get a specific copy. I've always been surprised that they haven't
been accessible right next to the .txt files.

	Tony Hansen
	[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Nov 2005 10:50:22 -0800

> Summary of suggestions:

This looks like quite a good list.  The only thing I would add is an 
interactive submission tool that validates the xml2rfc document being 
submitted.

Rather than explicitly penalize the text submitters with an earlier date, 
I'd suggest providing a bonus extension deadline for those submitting via 
this interactive path, since it would require NO human intervention on the 
I-D publishing side... after the tool gets built.

d/
-- 

Dave Crocker

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 23 Nov 2005 13:15:28 -0600

> interactive submission tool that validates the xml2rfc document being 

If the Proto Tools group hasn't already started on such a thing, it's only 
because they are already working on something that we need more, but I 
thought Henrik and I have already discussed this (so it's only a matter of 
time).

> I-D publishing side... after the tool gets built.

We don't create text in face-to-face meetings, but we do have discussions 
that affect text; a submission tool that runs on autopilot would allow us to 
submit updated drafts based on discussions, and "make sure we got it right" 
while we still have face-to-face time with people.

I note that we are now publishing drafts during IETF week; the tool would 
simply make this easier for the secretariat.

And if the tool only runs on autopilot for xml2rfc inputs, that could be OK 
with me...

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Nov 2005 20:27:42 +0100

> or guessed, with some probability of error, by tools.

The nice thing about ASCII is that you don't need Word or a PostScript
viewer  -- or for that matter a graphical O/S to read them.  And it's
stable.  VERY stable.  Show me something that is vendor neutral for five
years AND A REAL REASON TO GO TO IT, and I'm mostly there.

On the other hand, here's a reason to NOT go away from ASCII.  As
someone mentioned to me today, ASCII art forces people to think about
conciseness and complexity.  If you can't reasonably depict it in ASCII
art perhaps you have a problem with one or the other.

Eliot

---

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

That's helpful - maybe the tools team can start a more centralized 
collection. As I noted in another context, the problem today is that 
changes during AUTH48 often don't make it into the author (XML) version 
since the editing is based on the RFC editor's ASCII and the OLD/NEW 
batch editor. It would be really bad if a collection of XML were to show 
the state just before AUTH48 (and maybe even before any IESG notes to 
the RFC editor).

Marshall Rose wrote:
> many can be found at http://xml.resource.org/public/rfc/xml/
> 
> i'm sure that other people have other repositories.
> 
> /mtr

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Nov 2005 11:36:14 -0800

Henning Schulzrinne wrote:
>    It would be really bad if a collection of XML were to show 

that is why the core to any format change needs to be the format the editor 
uses.  moving them from nroff to xml2rfc is key to any strategic improvement 
in things.

they probably would not mind being moved from a simple text editor, that 
requires they get all the formatting commands exactly right, so some that is 
format-aware and can help, or even entirely do, the formatting...

d/

-- 

Dave Crocker

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 23 Nov 2005 20:44:21 +0100

> interactive submission tool that validates the xml2rfc document being 

The tool has been specified (draft-ietf-tools-draft-submission) and approved
by the IESG (the document is in the RFC editor's queue).  The Tools Team has
requested that implementing this be placed high on the list of things to be
taken on by the secretariat once the contract with the new service provider
is in place.

> I-D publishing side... after the tool gets built.

I agree.

	Henrik

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 23 Nov 2005 13:59:59 -0600

You guys are awesome...

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Nov 2005 20:31:58 -0500

Folks, not to be a stick-in-the-mud, but one of the things that
has made  the RFC Editor process attractive for authors is that
it is possible to design and use the right format for a
particular presentation.  Sometimes that means "interesting"
page layouts and indentations.  Sometimes it means
cross-references within a document to, e.g., numbered paragraphs
or list elements within a section (and those are different, at
least in the ways that the RFC Editor has been willing to format
them in the past).  Sometimes it means reference forms that are
consistent with library or scholarly standards for the materials
being referenced, rather than forms that are optimized for
RFC-style references.

"Attractive for authors" _is_ important: while it is all very
well to say that the goal is the end user (which the authors
would typically agree with), if we make things unpleasant or
uncomfortable enough for the authors --who are, by and large,
volunteers-- we will lose some of them.  That isn't healthy for
the IETF either.

It is possible to do any of the things I've mentioned above in
the xml2rfc context.  However, sometimes it requires external
formatting followed by the use of <artwork> elements, which can
defeat the whole purpose of content-oriented markup.  Other
times it requires tricking the processor into doing the right
thing by use of <annotation> elements or clever and undocumented
uses of <seriesInfo> and/or <format> elements.

These things are not often necessary.  But they are, I would
suggest, necessary as often (or more so) than fancy graphics are.

Of the I-Ds and RFCs I have out there, some have been developed
and edited by working directly on the ASCII text.  At least two
or three were developed in Word and then (painfully) converted.
One was initially developed, long ago, in SGML (!) markup but
then forced into ASCII text and continued that way.   For the
last year or three, I've been using XML2RFC almost exclusively,
but I have had to make a few compromises that the RFC Editor
ultimately had to straighten out in nroff or that made the
relevant documents much harder to read and understand (as one
example, find the document-within-a-document examples of ISDs in
draft-klensin-newtrk-sample-isd-00.txt).

In addition, for I-Ds at least, making the XML generally
available raises some of the "IPR rights reserved for the author
except insofar as the IETF needs them for standards-related
work" issues raised on the IPR list -- where copyrights are
concerned, presentation formats are important.  (Issues about
whether those rights are important and what they are belong on
another list.)

So, while I'm generally in favor of the "submit XML" and "keep
XML" trends and discussions, I think we need to be quite careful
that XML2RFC and its format conventions and limitations don't
become a Procrustean bed into which authors and documents either
need to fit or to find somewhere to do work besides the IETF.

    john

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Nov 2005 09:26:40 -0800

On Wed, 2005-11-23 at 20:31 -0500, John C Klensin wrote:
> page layouts and indentations.

An extension in the XML2RFC conversion permits better control of the
formating.  

<figure title="">
  <artwork name="" type="" height="" width="" xml:space="preserve">

 ASCII artwork or fixed formatting (with XML characters escaped).
 i.e. &lt; or &gt;  Of course &quot; is needed elsewhere as well.

  </artwork>
</figure>

Is there something prohibiting the IETF from controlling the RFC2XML and
XML2RFC process?  Perhaps XML2RFC could be improved with schemas as
better guides authors using more modern (OS independent) editors.
Following the web2 trend, there could be a web based application to
further simply this process, perhaps even allowing entry of an text RFC.

Some suggested PDF or or PS.  These represent the output of the document
and not the input, meaning subsequent changes would be difficult.  At
least with XML, moving ASCII back into a document is not too cumbersome.
With a XML as an input, then including links or references within
various "spiffy" outputs would not be problematic.

As with anything, there is a learning curve. Including links and
references would be improved by having access to the source document
rather than amorphous output text that requires a display application
before it can be understood.

-Doug

---

From: Marshall Rose <[email-masked]>
Date: Wed, 23 Nov 2005 11:18:47 -0800

/mtr