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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 16 Jun 2006 13:39:37 -0700

John,

	You mean that we should update the current medieval print format to take advantage of the best technology available to the Victorians?

	Why go to all that trouble to create infrastructure to support an obsolete document format when we can get all the infrastructure required to support a modern, open format that delivers professional results for free?

	Moreover there is a much higher probability that third party tools will support a common W3C/IETF format than an IETF only format. 

		Phill

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]] 
> Sent: Friday, June 16, 2006 1:14 PM
> To: John R Levine
> Cc: [email-masked]
> Subject: Image attachments to ASCII RFCs (was: Re: Last Call: 
> 'Proposed Experiment: Normative Format in Addition to ASCII 
> Text' to Experimental RFC (draft-ash-alt-formats))
> 
> 
> 
> --On Thursday, June 15, 2006 09:39 -0400 John R Levine 
> <[email-masked]> wrote:
> 
> >> 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.
> >
> > In case it wasn't clear, my quite informal suggestion was that one 
> > might attach a few GIF illusttrations to an ASCII document, sort of 
> > like a paper book that has a few color plates glued in the back.  I 
> > agree it would be nuts to put text into GIF.
> 
> I continue to wonder whether what we should be doing here is 
> not to invent a new normative document format, but to figure out how 
> attach image-type figures to ASCII RFCs.   "plates glued in the 
> back" is almost exactly the same as the analogy I have been 
> thinking about.
> 
> So, while I don't think this particular experiment, as 
> described, is plausible, there are two ideas I'd like to see 
> proposed, perhaps experimentally, for the future:
> 
> (1) A PDF approach, but with PDF carefully researched and 
> profiled (to include searchability and copy-and-paste 
> extraction in addition to stability and very wide 
> availability for readers and formatters) and a back-out plan 
> should the community not be happy about the experimental results.
> 
> (2) Some specific and well-thought out proposals for a 
> "figure supplement" to RFCs with multiple figures in a single 
> file, good naming conventions, and so on.  A PDF file of 
> figure-images might be the right thing to use; there might be 
> better ones. 
> But, as a strawman, we might have.
> 
> 	    rfcNNNN.txt   (as now)  and
> 	    rfcNNNN-figs.pdf
> 	
> 	Where rfcNNNN.txt would contain things like
> 	
> 	    Figure 3. A Left Handed Foogle (please see
> 	supplement)
> 	with or without a rudimentary ASCII drawing.
> 	
> 	and rfcNNNN-figs.pdf would contain numbered and
> 	captioned figures, one per page.
> 
> There are probably better ways to do this -- I haven't 
> thought through the details -- but I think that there is the 
> core of an interesting idea in this.
> 
> It would _not_ be a small experiment: it implies changes to 
> our archives, changes to indexing systems, more work for the 
> RFC Editor in verifying that figure numbers, captions, and 
> content were consistent between the ASCII RFC and the 
> "plates", and so on.  But it would appear to me to point to a 
> way forward that would not share most of the disadvantages of 
> normative PDF files.
> 
>         john
> 
> p.s. When I said "should not have been last-called" in a 
> prior note, I wasn't trying to suggest that the _idea_ was 
> obviously dead or bad.  I was trying to suggest, instead, 
> that, when an idea is discussed at length on the IETF list 
> and a number of issues raised with it, it is normal for the 
> IESG to insist that any version of the idea that is 
> subsequently to be last-called 
> address most of those issues in some substantive way.   "We 
> don't see X as a problem" may be appropriate; pretending 
> (deliberately or by accidental omission) that X was not 
> raised or discussed as an issue is usually not.  The fraction 
> of the Last Call discussion that essentially duplicates the 
> discussions of some months ago is probably testimony to the 
> wisdom of that principle.
> 
> 
> 
> _______________________________________________
> 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: Michael Thomas <[email-masked]>
Date: Fri, 16 Jun 2006 14:12:09 -0700

>	Moreover there is a much higher probability that third party tools will support a common W3C/IETF format than an IETF only format. 
Which tools would those be? Cat, tr, emacs, vi, grep, cut, sed, curses, 
wc, more or less?

Am a Luddite. I like ASCII. I despise PDF, and most especially its 
hideous anti-aliased
fonts. As software engineer, I don't need drawings that I can use to run 
a lathe or a
milling machine. Simple stick figures, ladder diagrams, and boxes for 
bits and bytes
are about all I really need to see to transform an RFC into code. As 
protocol designer,
the fewer Paper Clips sent by Beelzebub himself, the better. If it can't 
be edited using
the buffer gap method, I'm not interested.

Victorian? Pah. The death of Prince Albert of Ascii would require a 
minimum of a
year of  mourning, and a smart new black wardrobe for Phill. Not to 
mention a
cross sovereign.

       Mike, we are not amused.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Jun 2006 23:13:30 +0200

On 16-jun-2006, at 22:39, Hallam-Baker, Phillip wrote:

> 	You mean that we should update the current medieval print format  
> to take advantage of the best technology available to the Victorians?

> 	Why go to all that trouble to create infrastructure to support an  
> obsolete document format when we can get all the infrastructure  
> required to support a modern, open format that delivers  
> professional results for free?

> 	Moreover there is a much higher probability that third party tools  
> will support a common W3C/IETF format than an IETF only format.

Don't diss medieval archiving: that stuff is still around. That's  
very different for a plethora of more modern ways to archive stuff,  
especially in the digital domain. (Ever looked at a two year old fax?)

When I was 16 years old, I wrote a text editor in BASIC that would  
probably have allowed me to edit RFCs. In the intervening decades I  
went to software engineering school, but I'm pretty sure that unless  
I want to dedicate one or more years of my life to it, I can't write  
something that can decode and display, let alone edit, PDF.

Having RFCs only available in a format encumbered with the complexity  
and ambiguity of PDF (I'm not even mentioning patent/copyright/ 
trademark issues) is just asking for trouble. And there is absolutely  
no need for it: it's possible NOW to create a pretty PDF version when  
you write an RFC. You just have to create an ASCII version too. Is  
that such a big deal that we're willing to risk losing the ability to  
access our past work?

Although common wisdom tells us that a picture is worth a thousand  
words, I doubt that greatly in the area of technical documents: yes,  
they can be useful but they can also be misleading. The text should  
be able to stand on its own. I'm not opposed to having images  
attached to (ASCII) RFCs (but not in PDF or another complex format!)  
but I don't really see the need.

This goes double for formulas: those can be rewritten into pseudo  
code, which generally makes them more accessible to boot.

---

From: Peter Dambier <[email-masked]>
Date: Fri, 16 Jun 2006 23:55:14 +0200

Michael Thomas wrote:
>> required to support a modern, open format that delivers professional 
>> results for free?
>>

I absolutely need vi and grep. PDF is nasty because is lacks these tools.

> year of  mourning, and a smart new black wardrobe for Phill. Not to 

By the way, might we - - - perhaps EBCDIC ???

It is much better than ASCII because it sorts numbers where they belong,
behind the letters and not in front of them.

And please keep a space not a tab and no printable character in column one.
I need it for printcontrol.

EBCDIC has got all the graphic characters you  ever need. It is a standart
and it is multiplatform.

Both kermit and ftp can handle EBCDIC. Even the PC and Apple addicts can
use it.

You can use dd to translate between ASCII and EBCDIC

http://www.scit.wlv.ac.uk/cgi-bin/mansec?1M+dd

So it is already present on all decent operating systems.

Using the 3270 telnet option, all decent browsers allow reading EBCDIC
pages. No need for plugins.

Any comments? lol and rofl favoured :)

apropos

There exist readers for ASCII and EBCDIC either Braille or literally
readers for the blind and for people with reading disabilities.

Internet sans frontiers.

Cheers
Peter

-- 
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: John L <[email-masked]>
Date: Fri, 16 Jun 2006 20:26:48 -0400 (EDT)

> You mean that we should update the current medieval print format to take 
> advantage of the best technology available to the Victorians?

Yeah.  I realize that it's appealing to upgrade to the latest half inch 
nine track tapes (a format that lasted 20 years, after all), but I get the 
impression that I'm not the only person who would prefer to move with 
greater caution.

> will support a common W3C/IETF format than an IETF only format.

Part of the charm of ASCII and GIF is that they already widely supported 
by tools that have nothing to do with either the W3C or IETF.

It seems to me that a good next move would be to figure out if we can 
arrive at some consensus about what problem we're trying to solve.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Fri, 16 Jun 2006 18:15:28 -0700 (PDT)

> Any comments?

Well, you left out my personal favorite: In ASCII:

   'z' - 'a' + 1 = 26

but in EBCDIC:

   'z' - 'a' + 1 = 41

(or something close to that - it has been a while since I had to deal
with EBCDIC.)

With cool properties like this, EBCDIC sure seems like a winner to me...

> lol and rofl favoured :)

Agreed!

				Ned