[rfc-i] Data point [Re: Fwd:I-D ACTION:draft-hoffman-utf8-rfcs-03.txt]

Joe Touch touch at ISI.EDU
Tue Oct 7 10:35:36 PDT 2008

Hash: SHA1

Julian Reschke wrote:
> Joe Touch wrote:
>>> Joe Touch wrote:
>>>> OK; that means that Wordpad doesn't generate UTF-8. That was the one
>>>> editor that appeared to support at least some of the cut/paste tests.
>>>> If that doesn't work, then we don't have a viable UTF-8 editor
>>>> identified for Windows.
>>> What's wrong with Notepad? (except for LF only?)
>> Except for...? Well, that's the problem, isn't it?
> Well, strip the CRs before submitting.
> Besides, I'd be really surprised if anybody would edit RFCs or Internet
> Drafts in Notepad anyway.
> I though the question we were dealing with is *reading* RFCs/I-Ds that
> contain non-ASCII characters encoded in UTF-8?

Right - the one tool I had that understood ASCII, CRs, and FFs was
Wordpad. It worked for reading RFCs on the screen and for printing them
(to printers I've used, e.g., inkjets, lasers, save as PDF, PS, etc.)

That tool will display UTF-8 correctly on the screen, but will not print
the special characters properly.

So I can have EITHER UTF-8 special characters or FFs, but not both.
That's not a path forward, IMO.

>>>>> Between the two CR/LF pairs I see something with code point 18; so
>>>>> your
>>>>> method of entry apparently didn't produce the desired result.
>>>> Hmm. I did what the web pages for UTF-8 said:
>>>> http://www.fileformat.info/info/unicode/char/000c/index.htm
>>>> (see "how to type in Windows")
>>>> It appears that this is incorrect, but further points to the immaturity
>>>> of this format.
>>> The inability to type a form feed character in some Windows application
>>> shows that UTF-8 is immature??? The same would apply to ASCII, unless
>>> I'm missing something.
>> I'm referring to a web page that has detailed instructions that are
>> incorrect. Sure, that's common on the Internet (the "zero-sum of all
>> knowledge"), but this is a fairly comprehensive site on this issue
>> otherwise...
> At this point I'm really not sure what your point is.
> - LF as a line separator is a problem in Windows? Agreed.

Nope - it works fine in Wordpad.

> - It's hard to enter formfeed characters in Windows editors? Agreed.

Well, a fairly definitive site on how to enter FFs in UTF-8 apparently
gets it incorrect. I don't recall similar issues with ASCII tables being

> (These problems go away as soon as the author chooses one of the tools
> we have for the job)

They go away only if we chose to generate RFCs using xml2rfc, for which
I have yet to see a WYSIWYG editor.

For reading the docs, we can use Wordpad.

As to printing the docs, there's NO path forward yet that preserves both
UTF-8 and FFs.

At this point, I'm wondering why I'm involved in proving that UTF-8
can't be done on Vista. IMO, a viable proposal needs to include a test
coordinate by the author that involves a set of currently used common
platforms - i.e., the onus of proof is on them.

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the rfc-interest mailing list