Subject: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Jun 2006 15:15:26 -0400

I am personally skeptical about the value of the this experiment.

I am concerned about the long term viability of this particular 
format.  (I saw a recent note about a postscript document that 
supposedly used only core features of postscript, but still could not 
be printed on a modern printer.)

I am also concerned that the document does not specify versions and 
features.  I understand that people may have trouble knowing what 
versions and features of PDF they are using, it is important to 
remember that PDF is an active format, and I have seen reports that 
suitably arranged PDF can carry content which causes harm.

Another concern is that this increases the work on the RFC 
Editor.  After performing the editing, and receiving the normative 
PDF, the RFC Editor must carefully determine if it actually matches 
the agreed text changes.  (Let us assume the author was trying in 
good faith to do so.  Mistakes still get made.)  When the PDF was 
secondary to the text, this was not as large a concern.

Finally, this experiment will produce a set of RFCs which live 
forever with the limitation that those RFCs do not have normative 
ASCII.  What if we decide that this is a bad idea?  How do we fix it?

Yours,
Joel M. Halpern

At 10:56 AM 6/14/2006, The IESG wrote:
>The IESG has received a request from an individual submitter to consider the
>following document:
>
>- 'Proposed Experiment: Normative Format in Addition to ASCII Text '
>    <draft-ash-alt-formats-02.txt> as an Experimental RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2006-07-12.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.txt
>
>
>_______________________________________________
>IETF-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf-announce

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

---

From: John Levine <[email-masked]>
Date: 14 Jun 2006 22:00:37 -0000

This draft addresses none of the problems identified the last time it
came around, and I strongly encourage the IESG to say no.

Although I sympathize with the concern that some RFCs would work
better with fancier graphics, "PDF" isn't a solution to any problem I
understand.

Most importantly, PDF is not one format, it is a family of formats,
and it is all too common to find "PDF" documents that do not display
properly, most often because they depend on non-standard fonts, but
sometimes because they depend on features not found in all PDF viewers
or printers.  I see that librarians who are concerned about archival
documents have defined a profile called PDF/A intended for documents
with long lifetimes that should work reliably.  But I don't know any
more about it than that, and in particular I don't know what tools are
available to produce PDF/A or to verify that a purported PDF document
is indeed compliant with PDF/A.

Since the main concern in this draft is that RFCs need better
graphics, I would suggest that a simple solution would be to permit
ASCII drafts to have accompanying illustrations in a well standardized
graphic file format such as GIF (which I think is now out of patent
everywhere) or PNG.  That would require little change to the editorial
process.

Finally, I have to say that some of the concerns in this draft are
just silly, notably the complaint that ASCII documents look lousy when
loaded into Microsoft Word and printed.  It's true, but if you think
ASCII documents look bad in Word, try loading a PDF into Word and
printing that.  If someone is using a Windows system, the Notepad
program included with all versions of Windows can load and print ASCII
files quite nicely.

So anyway, please do not conduct this experiment.  If we agree that
better graphics are important, there are simpler and less risky ways
to accomodate them.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Bob Braden <[email-masked]>
Date: Wed, 14 Jun 2006 15:37:34 -0700

Joel Halpern's comments (below) are right on  target.  However, Joel is 
rather too polite.

First, I must request that the Internet Draft be retracted in its present 
form.  Section 4
contains a direct quote from one of my messages.  However, the quoted 
sentence was taken
brazenly out of context; its sense is quite the opposite of the sense of my 
original
message. This is intolerable.  That kind of behavior may get you elected in 
the US ;-)
but it does not belong in the IETF.

Now, on to the substance.  As the author notes, there was indeed a replay 
of the usual
discussion about RFC formats in winter 2006.  The author says, "... the 
quite thoughtful,
extended, and detailed discussion ... resulted in no change".  There is a 
reason it did
not result in change... there were cogent arguments against all proposals 
that were
made. So, when it has no good ideas, the IETF randomly picks one of the bad 
ones?
That is apparently happening here.

How DID it get last called, by the way?  If I write up a arbitrary process 
experiment,
will the IESG automatically last call it?  Yummy.

The experiment picks on  two working groups and specifies that for one year 
it will
treat the results of these working groups differently from all other 
working group
output. How will a future implementor know which version is normative?  At 
present,
there is a simple rule... it is always the ASCII version.  If this exercise 
goes
ahead, some PDF files (which ones?) will be normative, and some ASCII
files won't.  This seems like a little hint that "process experiment" is not
a useful procedure for changing the fundamentals of standards publication
by the IETF.

Besides the misquote of myself, the I-D has some misleading examples of
bad ASCII art.  You cannot honestly prove that ASCII art is unusable
by abusing it.  I spent a few minutes cleaning up the terrible example
in the I-D (Sorry, I am in Washington and don't have ready access to
it; I will forward it when I get back.)

As Joel mentions, this experiment will have a negative impact on
RFC Editor throughput.  Shouldn't the IAB and perhaps the IAD
have some part in this?

For all the reasons that Joel said, plus the reasons I have given, I
request that the IESG reject this last call.  At the very least, the
base document needs more work, and the implications need
more mature thought.  And it seems to there is a badly broken
process lurking here.

I am somewhat astonished that the IESG chose to last call
'this document.

Bob Braden

At 03:15 PM 6/14/2006 -0400, Joel M. Halpern wrote:
>format.  (I saw a recent note about a postscript document that supposedly 
>used only core features of postscript, but still could not be printed on a 
>modern printer.)
>
>features.  I understand that people may have trouble knowing what versions 
>and features of PDF they are using, it is important to remember that PDF 
>is an active format, and I have seen reports that suitably arranged PDF 
>can carry content which causes harm.
>
>Another concern is that this increases the work on the RFC Editor.  After 
>performing the editing, and receiving the normative PDF, the RFC Editor 
>must carefully determine if it actually matches the agreed text 
>changes.  (Let us assume the author was trying in good faith to do 
>so.  Mistakes still get made.)  When the PDF was secondary to the text, 
>this was not as large a concern.
>
>Finally, this experiment will produce a set of RFCs which live forever 
>with the limitation that those RFCs do not have normative ASCII.  What if 
>we decide that this is a bad idea?  How do we fix it?
>
>Yours,
>Joel M. Halpern
>

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 15 Jun 2006 00:51:17 +0200

> I am somewhat astonished that the IESG chose to last call

The document does not specify a particular variety of PDF. There are many.

The document does not specify the permitted embedded data formats. PDF
allows raster and vector images, JavaScript, form validation, fonts,
and much more.

PDF and some possible embedded data formats are patent encumbered.
There are IPR disclosures available.

The document incorrectly states that RFC 1119 is available in
"PDF/PostScript", when it is only available in PostScript.

The authors state that "commercial" software does support ASCII well.
Their stated favorite editor, Microsoft Word, does not and will not
support PDF:

<http://www.mercurynews.com/mld/mercurynews/business/14748212.htm>

PDF/UA is the "universally accessible" flavor of PDF, but it is not
yet standardized, AFAIK.

The process outlined in this document is completely inappropriate for
an archival document series, for the reasons outlined above. Those
were just the glaringly obvious concerns. There are probably more.

-- 

Robert Sayre

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 17:18:35 -0700

> everywhere) or PNG.  That would require little change to the editorial

If we're talking about line drawings, an object format is more useful
than a bitmap such as GIF or PNG. However, like Bob, I don't see the
format as the issue, but often the illustrator. It's possible to write
poor text and draw poor pictures in ASCII and PDF.

The key question is whether there exists a format which is likely to be
sufficiently stable that we won't have to revisit this decision in
another 35 years. All the proposed formats - including PDF, XML, etc. -
are moving targets at this time.

Joe

---

From: John L <[email-masked]>
Date: Wed, 14 Jun 2006 22:16:53 -0400 (EDT)

> are moving targets at this time.

That's why I suggested GIF.  Like ASCII, GIF has its shortcomings, but its 
definition hasn't changed in 16 years and I've never seen GIF software 
that doesn't interoperate.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Jun 2006 21:36:33 -0500

> that doesn't interoperate.

I did want to distinguish between targets that someone else moves and 
targets we move. If we care, we can make sure that some variant of XML2RFC 
continues to work even if "XML is a moving target", so relying on our 
ability to process XML and produce RFCs in 35 years is probably pretty 
darned safe.

If someone else can move a target, that's more likely to be living 
dangerously, I think.

Thanks,

Spencer

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 22:31:07 -0700

Spencer Dawkins wrote:
>> That's why I suggested GIF.  Like ASCII, GIF has its shortcomings, but
>> its definition hasn't changed in 16 years and I've never seen GIF
>> software that doesn't interoperate.
> 
> targets we move. If we care, we can make sure that some variant of
> XML2RFC continues to work even if "XML is a moving target", so relying
> on our ability to process XML and produce RFCs in 35 years is probably
> pretty darned safe.

And forces us to use a single version of a tool in which to write I-Ds.
By that argument, any format we define is a static target, but equally
useless in a fairly short time.

It'd also be nice for us to be able to use modern editing tools, rather
than chiseling out drafts in source code like we did in the 1970s.

Joe

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Jun 2006 03:42:46 -0400

Two observations on this...

--On Wednesday, June 14, 2006 22:16 -0400 John L 
<[email-masked]> wrote:

>> The key question is whether there exists a format which is
>> likely to be sufficiently stable that we won't have to
>> revisit this decision in another 35 years. All the proposed
>> formats - including PDF, XML, etc. - are moving targets at
>> this time.
>
> That's why I suggested GIF.  Like ASCII, GIF has its
> shortcomings, but its definition hasn't changed in 16 years
> and I've never seen GIF software that doesn't interoperate.

But one of the important criteria for an acceptable alternate 
form, one which came up in the earlier discussion on this list, 
is that the format be searchable.   With PDF, page-image forms 
may not permit that but, as far as I know, searching inside GIFs 
is impossible except perhaps via fancy AI tools and heuristics.

More generally and to reinforce a point that I think Bob Braden 
made, I believe there was general consensus on this IETF list 
when the earlier discussion occurred that PDF, if it was to be 
used, be narrowly profiled so as to permit only those variations 
that appeared to be stable and meet various other criteria, 
notably ease of searching and extraction by text copying 
operations.  It seems to me that this draft, by omitting 
specifics about versions and features of PDF to be permitted 
and, if it isn't obvious, how the submission or editing process 
automatically verifies that those rules were followed, is not 
responsive to that consensus.  Arguably, on that basis, it 
should never have been Last Called.

      john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Jun 2006 14:06:32 +0200

Bob,

> First, I must request that the Internet Draft be retracted in its 
> present form.  Section 4
> brazenly out of context; its sense is quite the opposite of the sense of 
> my original
> message. This is intolerable.  That kind of behavior may get you elected 
> in the US ;-)

Please take that up directly with the author. We don't 'retract' I-Ds
but we certainly update them.
...
> 
> How DID it get last called, by the way?  If I write up a arbitrary 
> process experiment,

No. It requires an AD (Bill Fenner in this case) who is willing to
shepherd the draft. The IESG as a whole doesn't normally review
drafts until after the Last Call has ended - that's why we have
Last Calls.

     Brian

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 15 Jun 2006 17:58:13 +0200

> The document does not specify a particular variety of PDF. There are
many.

This comment has been made many times, and answered equally many.
One of the objects of the experiment os to determine the details of the
PDF to be used.
PDF/A has been suggested.

> The document does not specify the permitted embedded data formats. 
> PDF allows raster and vector images, JavaScript, form validation,
fonts, and much more.

Once again, this has been discussed to death on this list.

> There are IPR disclosures available.

Read Adobe's RFC 3667 disclosure. They grant a royalty-free license
to anyone who wants to write software to manipulate PDFs,
as long as they are compliant to the specification.
Sounds sufficient to my (IPR trained) eyes.

Go to the RFC editor page and serach for 1119.
You will get the following screen:

 Choose a file format
  Text   rfc1119.txt
  PDF   rfc1119.pdf
  PS     rfc1119.ps

The filenames all have simple links to files, nothing is generated
on-the-fly.

I agree that clicking on the txt version gives an incorrect message that
the file is only available in ps.

support PDF:

As one of the authors I hereby state that Word is not my favorite editor
(if it is an editor at all).  However, the clear intent was that IF the
IETF
does not want to use a commercially available tool, then the next
possibility
is to use a well-defined format.

> The process outlined in this document is completely inappropriate for
an archival document series, for the reasons outlined above. 
> Those were just the glaringly obvious concerns. There are probably
more.

What seems to be glaringly obvious is that the same reasons are brought
up time and time again,
as if for the first time.  I assume that the strategy is to bore the
authors of this draft into submission
(or in this case into retraction of a submission).

Y(J)S

---

From: "nathaniel Borenstein" <[email-masked]>
Date: Thu, 15 Jun 2006 11:33:45 -0400 (EDT)

Although I, too, am tired of seeing this discussion arise again every few
years, it occurs to me that there is one new possibility that exists now,
but did not exist in previous incarnations of this discussion:  Open
Document Format.

I expect that ODF is still too young and immature for use in archival
standards documents today.  But it is worth pointing out that IF (a big
if) ODF succeeds in becoming a widely-used standard, it will have nearly
all of the right properties for a long term IETF archival format.

I know this stirs up yet another batch of hornets, but it might really be
the right solution in the long term.  -- Nathaniel

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 15 Jun 2006 18:04:32 +0200

> (or in this case into retraction of a submission).

I moved this up to the top. Other responses follow. The text above is
pretty intellectually dishonest coming from someone who ignored the
opinion of a large number of commenters and went ahead with
essentially the same text they had before. The draft is a joke.

> PDF/A has been suggested.

Then I don't think you've put much effort into this proposal. Be more specific.

> Once again, this has been discussed to death on this list.

Yes, and there was no satisfactory resolution, so why should the
"experiment" go forward.

> Sounds sufficient to my (IPR trained) eyes.

Your IPR-trained opinion doesn't mean much to me when Adobe is
threatening to sue people (even if it is MS).

> the file is only available in ps.

Fair enough.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Ned Freed <[email-masked]>
Date: Thu, 15 Jun 2006 09:32:57 -0700 (PDT)

> is impossible except perhaps via fancy AI tools and heuristics.

Complete agreement here. GIF may win on stability, but loses badly in several
other ways. In addition to not being searchable, I really don't relish having
to create a revision to a long document starting with only pictures of the text
the document contains.

> operations.

Bingo. And this is the problem with the experiment as it is presently
formulated: It tests nothing of significance. It's completely obvious that we
can create PDF RFCs. It is equally obvious that block diagrams and equations
done in ASCII are inferior in appearance to those done using more powerful
formatting tools. All of these things get a 10 on the "duh" scale.

A genuinely useful process experiment in this space would have to:

(0) Nail down format requirements. Perhaps the requirements are the same
    as for ASCII documents, but I doubt it.
(1) Carefully examine the subsetting and profiling issue and decide what
    does or does not need to be done.
(2) If subsetting is needed tools need to be identified that conform to
    those subsetting guidelines. Additionally, we almost certainly need a
    validation tool that checks to see if the guidelines are being followed.
(3) Given how popular xml2rfc is I think it makes sense to at least look at
    how it would best be used to produce PDF documents containing equations and
    block diagrams.
(4) The criteria for assessing the experiemnt need to address our need for
    long term accessibility.

Now, it may or may not be appropriate for the document defining the experiment
to specify all of this stuff. But if the document doesn't specify these things
it at least has to specify the processes that are going to be used to create
these specifications.

I will also point out that the current draft talks about there being
a "phase 2" experiment involving XML or OpenOffice as input formats. The
vagueness of this part of the proposal is very disturbing - additional
details either need to be given or this material needs to be removed.

Yet another problem with the current proposal is the security considerations
section, which basically says there aren't any. Given that this document
proposes using PDF in its full and unrestricted glory it should be obvious why
this isn't true.

> It seems to me that this draft, by omitting

I can sort of justify last calling it in order to force people to review it. I
certainly hadn't read it all that carefully before. But now that I have read
it, my position is that we urgently need a process experiment in this space,
but this is absolutely not the right one to run.

				Ned

---

From: Bill Fenner <[email-masked]>
Date: Thu, 15 Jun 2006 11:23:58 -0700

>    how it would best be used to produce PDF documents containing equations and

I did this the N-2nd (or maybe 3rd) time we had
this discussion and have refined it since.  See, e.g.,
http://electricrain.com/fenner/tmp/draft-my-document-01.pdf .
That's svg for the picture (also supported are gif, png, jpg,
etc.) and latex for the equation.  It's obviously just a proof
of concept implementation.

The editor screen when working on this document is something
like http://electricrain.com/fenner/tmp/svg_eqn_editing.png .
There's no WYSIWYG editing of the svn or latex, but you get
to see what they look like.

This is a $220 XML editor, but its job is mostly to string
together other pieces of software so although it's not free
software in this implementation, I don't think that means that
the same thing can't be implemented with free software (e.g.,
it uses Batik to render the svg, and if Apache FOP improved
some perhaps it could render the FOP to PDF instead of the
for-pay (or free-to-download-personal-edition) RenderX)

  Bill

---

From: Eliot Lear <[email-masked]>
Date: Sat, 17 Jun 2006 16:59:26 +0200

For many of the reasons Joel mentioned, I also do not support the
experiment as stated in the draft.  I want to amplify one point:

Joel M. Halpern wrote:
> with the limitation that those RFCs do not have normative ASCII.  What
> if we decide that this is a bad idea?  How do we fix it?
A change from ASCII should not be a flag day, as this document would do
to two WGs, but rather based on more experience retrieving the
appropriate format.  So for instance, it might be interesting if the RFC
Editor made available HTML versions of documents produced with XML2RFC,
with a caveat that the normative form is still ASCII.  This also allows
for the continued evolution of XML2RFC to include other objects in a
more planned manner.  The costs of doing this sort of thing are a
concern, of course.

I do think that ASCII art has its limits, particularly when it comes to
mathematics.  But I think a more gradual evolution is called for in this
case, with more consideration given to not only the normative issue but
all the others Joel raised.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 18 Jun 2006 11:37:19 +0200

On 17-jun-2006, at 16:59, Eliot Lear wrote:

> mathematics.

I'm pretty sure I read as many RFCs as the next IETF participant  
(well, the ones that don't have a three or four letter acronym  
starting with "I" in their job description, anyway) and the only  
formula I seem to remember is this one:

               log(number of allocated objects)
    HD = ------------------------------------------
          log(maximum number of allocatable objects)

In other words: is this really a significant issue in practice?

It's much better to use the way this is expressed in well-known  
programming languages anyway, like:

hd = log(numberofallocatedobjects) / log 
(maximumnumberofallocatableobjects)

This also gets around the limitation that exists in math and perl  
where you're lost if you don't know the meaning of a certain symbol  
because you can't easily look up unknown symbols like you can with  
unknown words.

An interesting side-issue is that if RFCs are no longer plain ASCII,  
it gets a lot more difficult to discuss them in email.

> But I think a more gradual evolution is called for in this

Looks to me that we don't even agree on what the problem is yet.

---

From: "Clement Cherlin" <[email-masked]>
Date: Sun, 18 Jun 2006 04:08:38 -0700

> all the others Joel raised.

I believe one gradual approach that hasn't been discussed is using
Unicode instead of ASCII.  Many of the problems of representing
mathematics and diagrams could be resolved that way, while still
retaining the compatibility and portability advantages of plain text.
The majority of the solutions I've seen proposed would end up using
Unicode as their base character set, so why not cut out the elaborate
markup languages and use Unicode directly?

I just whipped up some sample fixed-width Unicode art, to illustrate
the possibilities:

Unicode Math

    ______
−b±√b²−4ac
──────────
    2a

Unicode Box Drawing

┌────────────────┐
│ This is a box  │
├────────────────┤
│With another box│
│   underneath   │
└────────────────┘

---

From: Peter Dambier <[email-masked]>
Date: Sun, 18 Jun 2006 14:17:26 +0200

Clement Cherlin wrote:
> -b±?b²-4ac
> ??????????

The Math I could see, except for the divider line, Iguess.

> ??????????????????
> ? This is a box  ?
> ??????????????????
> ?With another box?
> ?   underneath   ?
> ??????????????????

There were no boxes but a peculiar line below.

> 
> ------------------------------------------------------------------------
> 

How about Tex?

It is as old as the internet and you can use vi to read and edit.
You still can use grep to scan all old documents to find something.

ASCII has its limits, yes.

All the alternatives mentioned are even more limited.
Except EBCDIC of course :)

I dont mind getting something new - if somebody else pays for it :)
But I dont like to lose something I need.

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/

---

From: Julian Reschke <[email-masked]>
Date: Sun, 18 Jun 2006 16:18:51 +0200

> There were no boxes but a peculiar line below.

Well, that indicates that your mail program either didn't understand the 
character encoding, or that the font you are using is missing glyphs for 
some of the Unicode box drawing characters.

As far as I am concerned, at some point the IETF should start on relying 
on some of 1990's technology being present, such as relying on certain 
Unicode code points to be readable by everybody. That being said, at 
least on Win XP the standard fonts seem to support only a subset of the 
  Unicode box drawing characters, which is a shame.

Best regards, Julian

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 18 Jun 2006 19:45:31 +0200

> You still can use grep to scan all old documents to find something.

It is also the only method to always get precisely the same printout,
has the best equation typesetting, makes perfectly good diagrams,
and the source is pure future-proof ASCII.

And there are advanced tools for editing and comparison on all platforms

of which I know, for those who desire something a bit stronger than vi
and grep.

As I have said before, if we decide on TeX instead of XML
we solve all the problems.

Y(J)S

---

From: Julian Reschke <[email-masked]>
Date: Sun, 18 Jun 2006 18:54:58 +0200

> and the source is pure future-proof ASCII.

I would say that getting always the same printout is a non-goal.

> we solve all the problems.

You're comparing apples and oranges here. For instance, you could use 
XSL-FO (an XML format...) which also is closer to presentation markup 
than the RFC2629 XML format.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 18 Jun 2006 20:48:56 +0200

> Unicode Box Drawing

I like that. In fact I like it so much that I did add some machinery to 
rfc2629.xslt that helps in producing those (based on existing ASCII line 
art). Example at:

<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.14>

Best regards, Julian

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 19 Jun 2006 09:12:28 +0200

> I would say that getting always the same printout is a non-goal.

Why? As has been stated previously, in most SDOs the "printed page"
is the final word. One of the many inconveniences of xml2rfc is the need
to add "vspace blankLines" to avoid unfortunate page breaks.

>You're comparing apples and oranges here. 
>For instance, you could use XSL-FO (an XML format...) which also is
closer to presentation markup than the RFC2629 XML format.

Why should the IETF be inventing new tools to create documents at all?
Why aren't we focusing on developing protocols for the IP world,
and adopting existing tools for the mundane task of document creation?

Y(J)S

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Jun 2006 08:23:16 +0200

> to add "vspace blankLines" to avoid unfortunate page breaks.

Because it's sufficient to generate the ASCII version once on 
publication and then keep it. Keeping the source is essential for 
completely separate tasks (meta data extraction, document revision, 
generating other formats such as HTML or PDF).

> and adopting existing tools for the mundane task of document creation?

So far the IETF hasn't done that. The format is ASCII.

One good reason to use a specific XML grammar is that when the only 
thing that's available is a presentation-oriented format (such as Word 
or PDF), it gets *much* harder to do meaningful things with the source. 
And that's one of the reasons why volunteers maintain xml2rfc (both the 
format itself and various implementations). Speaking of which, that's 
probably the reason why the W3C is doing the same with their xmlspec XML 
format.

Best regards, Julian

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 19 Jun 2006 10:05:30 +0200

> Because it's sufficient to generate the ASCII version once on
publication and then keep it. 
> Keeping the source is essential for completely separate tasks (meta
data extraction, document revision, generating other formats such as
HTML or PDF).

You are using "the ASCII version" as a proxy for a printed page 
(and as I once complained, it is not a faithful proxy on all platforms).
However, the problems we wanted to solve were precisely those where
ASCII
is not sufficient, namely graphics and equations, and so we need
to return to the printed page as the final word.

> So far the IETF hasn't done that. The format is ASCII.

See above.

> One good reason to use a specific XML grammar is that when the only
thing that's available is a presentation-oriented format 
> (such as Word or PDF), it gets *much* harder to do meaningful things
with the source. 

You are making assumptions about presentation formats.  
It is quite easy to do meaningful manipulations on TeX source.

> And that's one of the reasons why volunteers maintain xml2rfc (both
the format itself and various implementations). 

And here is precisely where we are expending efforts.
I too enjoy coding, but why are we recreating for the XML2RFC
environment
mechanisms that exist in available tools?

The zenith of these efforts is a script to extract TeX-style math
expressions, run TeX on each separately, 
create images, and then embed them into a PDF created from the xml.
... and all that just to avoid using TeX.

Y(J)S

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Jun 2006 09:18:20 +0200

Yaakov Stein schrieb:
> ..
> ..

Bah.

I personally like TeX a lot, and I've used it a lot in the early 
nineties. But face it, you won't be able to convince people to pick up 
TeX as a single source format for RFC production.

Best regards, Julian

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 19 Jun 2006 03:43:02 -0400

> mechanisms that exist in available tools?

"We" aren't expending any effort.  The IETF has not spent any resources on 
defining the xml2rfc grammar or implementing tools that operate on it.  We 
haven't formed a working group, spent any meeting time, or done anything to 
suggest that people are required to use it.

A few volunteers developed a language and some tools, not in an effort to 
define a standard source format, but because they wanted to make life 
easier for themselves as document authors.  They were kind enough to share 
their tools with the community, and other people started using them, and 
contributing to their maintenance and development.  I find those tools to 
be quite useful, as do many other people.  Please stop suggesting that 
these people are somehow wasting "our" time with their efforts.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 18 Jun 2006 19:09:38 +0100

> it; I will forward it when I get back.)

The example of the network in ASCII art was from a real ID that is
being discussed in one of the WG that the experiment is targeting.
We can find many others from active work in the IETF.

The equations are also from active drafts or from RFCs.

This in itself set a limit on the examples that were included in
the draft.

Perhaps we should have included examples of things beyond ASCII art,
for example the formal diagrams employed by the ITU, or the state
tables used by the IEEE.

- Stewart

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 19 Jun 2006 09:01:14 -0400

Dear Jeffrey;

I would tend to disagree.

The IETF is mostly a volunteer effort. Unless the volunteers have  
secret time machines in
their basements (I wonder about the IESG...), their time is limited.  
Time spent on one thing is not available for another.

Also, as the IETF is not entirely a volunteer effort, it has a  
budget, the current version of
which is here :

http://koi.uoregon.edu/~iaoc/docs/IETF-Budget-FY06-02-16-06.pdf

You will notice $ 100 K USD is going in 2006 to "Tools." (Not enough,  
IMHO, and this is
likely to increase in the future.) This money is
largely going to maintain the tools that the volunteers make. Now, I  
am not sure
whether or not xml2rfc is currently being supported by this, but if it
isn't, it will be.

I feel fairly sure that Yaakov was not trying to denigrate the tools  
team in any way,
just to point out the choices made will impact the way resources are  
spent, and in that
I think he is correct.

Regards
Marshall Eubanks

On Jun 19, 2006, at 3:43 AM, Jeffrey Hutzelman wrote:

>
>
> On Monday, June 19, 2006 10:05:30 AM +0200 Yaakov Stein  
> <[email-masked]> wrote:
>
> "We" aren't expending any effort.  The IETF has not spent any  
> resources on defining the xml2rfc grammar or implementing tools  
> that operate on it.  We haven't formed a working group, spent any  
> meeting time, or done anything to suggest that people are required  
> to use it.
>
> A few volunteers developed a language and some tools, not in an  
> effort to define a standard source format, but because they wanted  
> to make life easier for themselves as document authors.  They were  
> kind enough to share their tools with the community, and other  
> people started using them, and contributing to their maintenance  
> and development.  I find those tools to be quite useful, as do many  
> other people.  Please stop suggesting that these people are somehow  
> wasting "our" time with their efforts.
>

---

From: Peter Dambier <[email-masked]>
Date: Mon, 19 Jun 2006 17:24:08 +0200

Just try this good example:

http://www.nasa.gov/pdf/133654main_ESAS_charts.pdf

It is a nice promotion for the successor to the space shuttle.
Best store it localy before viewing.

It is a nice document with wonderful pictures. But building
the screens takes me hours.

That is one of the reasons why I am afraid of pdf.

Cheers
Peter and Karin Dambier

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Mon, 19 Jun 2006 17:53:33 +0200

> That is one of the reasons why I am afraid of pdf.

Why be afraid of PDF? This document just a PDF conversion of a PowerPoint
document.  The document is large because it contains a lot of
graphics, mostly bitmap graphics.

---

From: "Clement Cherlin" <[email-masked]>
Date: Mon, 19 Jun 2006 10:49:18 -0700

> <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.14>

Very nice.  That's a good example of the sorts of diagram that could
be displayed in an easier-to-read manner in an RFC using Unicode.  And
that's only a small sample; there are even more box-drawing
characters, arrows and math symbols available in Unicode.  Charts are
available at <http://www.unicode.org/charts/symbols.html>,
particularly the "Mathematical Symbols" section.

> Unicode box drawing characters, which is a shame.

It's true that Unicode font support is somewhat spotty.  If Unicode
were to be specified as the standard for RFCs, there would first need
to be an effort to determine which codepoints are available in good
quality, freely-available monospace fonts.
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Mon, 19 Jun 2006 14:16:19 -0400

> That is one of the reasons why I am afraid of pdf.

Peter,

I don't reach the same conclusion you do.  Yes, it is possible
to use PDF to construct large files, full of very high
resolution and possibly even tricky images.   It is also
possible to use it to generate callouts to serious security
problems and/or to make a document unreadable unless one is
online.   The inference I draw from these things for IETF use of
PDF is that we need to both

	* profile the features that can be used and 
	
	* to generate some enforceable guidelines about
	moderation.  I believe Wirth's adage about making things
	as complex as it needs to be, but no more complex is
	appropriate to this, but hard to define in a way that
	can be enforced without a few subjective measures too
	many.

I've complained about the first of those vis-a-vis this
proposal.  Perhaps others should be thinking about the second,
since it would apply, to different degrees, to any publication
form with more capabilities than ASCII text.

     john

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Tue, 20 Jun 2006 04:05:40 +0200

Clement Cherlin writes:

> It's true that Unicode font support is somewhat spotty.

It's worse than spotty; it is quite poor.

---

From: Tim Bray <[email-masked]>
Date: Mon, 19 Jun 2006 19:12:51 -0700

> It's worse than spotty; it is quite poor.

It's pretty good on modern Mac & Windows boxes.   When I go to a page  
in Devanagari or Chinese or Russian, it usually displays OK.   -Tim