Subject: Re: Why the normative form of IETF Standards is ASCII

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 12 Mar 2010 10:24:06 +0100

Hi

A favourite topic revisited :-)

Frankly speaking, all other standards foras use MS-word (or simular) format and as far as I can see it they seem to manage it, for instance OpenOffice can be selected as document tool.
Plain ASCII worked well when RFC768 was specified. Today protocols and algorithms are much more complex. You can easily find RFCs with flowcharts that spans two pages, they easly get difficult to follow. Don't even think about forumating complex equations...
If the intention is that the RFCs should survive a global nuclear war then plain ASCII on stone tablets stored in some cave on Svalbard is likely the best choice but I would not believe that people care about RFCs if sh-t hits the fan.
I strongly believe that it is at some stage time to consider more modern document formats.

Regards
Ingemar

> Message: 3
> Date: Thu, 11 Mar 2010 20:24:58 +0100
> From: Julian Reschke <[email-masked]>
> Subject: Re: Why the normative form of IETF Standards is ASCII
> To: Jorge Amodio <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 11.03.2010 19:44, Jorge Amodio wrote:
> > On Thu, Mar 11, 2010 at 11:12 AM, Julian 
> Reschke<[email-masked]>  wrote:
> >> On 11.03.2010 17:54, Jorge Amodio wrote:
> >>>
> >>> Besides your eyes, (only one in some cases), you don't need any 
> >>> extra junkware to be able to read the RFCs, even better, without 
> >>> eyes you still can do it since text to speech works very 
> nicely with ASCII.
> >>> ...
> >>
> >> I'd claim that accessibility for properly authored HTML 
> will actually 
> >> be better, for instance the markup can express whether 
> something is 
> >> prose or artwork.
> >
> > HTML uses ASCII as far as I remember, some tags, URIs and 
> URLs may be 
> > impossible to decipher these days but still ASCII (I've to 
> admit that 
> > some folks still use-abuse extended ASCII on HTML pages 
> instead proper 
> > encoding and lang selection).
> 
> HTML actually uses Unicode. All current element and attribute 
> names are ASCII, in case you meant that.
> 
> I don't understand the second statement, you appear to mix up 
> character sets, encodings (and their declarations) with 
> language information.
> 
> > About text to speech, it only takes a forward or going 
> trough one of 
> > the stupid no context aware robo-translators and you will 
> get your t2s 
> > interface reciting "gee tee ampersand semicolon greater 
> than eich ref 
> > equal lower than bee greater than ..." I guess you get the point.
> 
> I believe this to be not true, as long as you use the right 
> tools (such as an HTML UA instead of a text editor).
> 
> > And I agree with Martin, all other formats add a lot of unnecessary 
> > crap to the documents, embedded fonts, meta-crap data, 
> hooks to track 
> > document changes.
> 
> That's why we would need to talk about a profile of the 
> available features.
> 
> > And ASCII is more eco-friendly :-)
> 
> I'd potentially agree if the format we actually use wouldn't 
> have useless page breaks that leave 25% of the pages unused. 
> At least over here. I'd also agree if that format would 
> actually be usable on small devices like ebook readers (where 
> it's essential that you can reflow the text).
> 
> Best regards, Julian
> 
> 
> ------------------------------

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 12 Mar 2010 07:11:05 -0700

I wrote:

> A space character (which looks like an ordinary U+0020 space to me, in 
> both the plain-text message I received and in the Web archive) got 
> erroneously converted to a question mark in Tim's plain-text mail.

Actually, I take that back.  All the spaces in Tim's message look fine 
to me; only in Ohta-san's quoting of Tim's message do I see the question 
mark.

Regardless of where the question mark came from, this still has nothing 
to do with PDF.  It has only to do with tools that misinterpret 
character sets or transform plain text.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s