[rfc-i] Following up from Atlanta

[Nico Williams]

On Wed, Dec 5, 2012 at 1:18 PM, Steve Slevinski <slevin at signpuddle.net> wrote:
> On 12/5/12 11:47 AM, Nico Williams wrote:
>> On Wed, Dec 5, 2012 at 7:20 AM, Ted Lemon <mellon at fugue.com> wrote:
>>> Personally, though, I'd rather that drawings were done with SVG or
>>> something, and then rendered as ascii art for tty-lovers, because I find
>>> that in general it's quite difficult to express anything interesting using
>>> hand-drawn ascii art.
>>
>> +1.  Though I should point out that JavE is a really cool GUI ASCII art
>> editor.
>
> +2.  I edit XML directly in a plain text editor.  I am a fan of the ASCII
> version of the RFC.  ASCII art created from SVG sounds plausible.  Can a
> tool chain be built into xml2rfc processing?  SVG could easily satisfy XML
> users with either a WYSIWYG or a plain text editor.

A couple of tools that work together and may help with this:

 - JavE, an ACII art editor that rocks (http://www.jave.de/)

 - ASCIIToSVG, a tool for converting ASCII art to SVG
(https://bitbucket.org/dhobsd/asciitosvg)

> For other image formats, having the text [Image Deleted] in the ASCII would
> be disappointing.

Agreed.  If browsers had what I need then I might drop my request for
text.  Eventually the browsers will all get there (and maybe Opera has
all that I need); maybe I should preemptively stop asking for text.
Something for me to think about.

> Regarding Unicode and internationalization, tough nut to crack.  If any
> information is missing from the ASCII version, then the RFC in question is
> tied to the encoding being used, probably UTF-8, although UTF-32 is an
> option.  Long after UTF-8 has fallen from favor, the ASCII RFCs will be easy
> to process on any system that supports ASCII.

I don't buy any arguments for not putting UTF-8 in .txt files, or not
introducing a variant of .txt that includes UTF-8.  By now just about
everyone can display UTF-8.

Also, UTF-8 will not likely lose favor anytime soon.  Unicode will not
likely lose favor anytime soon.  At most I could imagine a new codeset
for internal use for efficiency reasons (namely, to have a fixed-width
codeset so that length in chars can be quickly computed from length in
bytes), but UTF-32 w/ pre-composition is basically that.

> For the current international generation, being tied to UTF-8 is preferable
> to ASCII.

Yes.

> While UTF-8 is the basis of modern internationalization, it is not as simple
> or stable as ASCII.  ASCII's common use will far surpass UTF-8.

UTF-8 is as stable as ASCII.  Unicode may not be too stable, but where
Unicode has had backwards-incompatible changes it's been in rare
corner cases, and we can expect fewer such changes going forward.

> Functionality wise, it's great to be able to use the XML to create the ASCII
> version, 2 styles of PDF, 2 styles of HTML, and use a stylesheet to preview
> live changes.  I look forward to creating epub books in the near future.

Yes.  +1 to epub/mobi.  I want to be able to use e-ink book readers to
read RFCs on airplanes, or at least try -- I really do need a fairly
large display to read RFCs, at least tablet sized.

Nico
--