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

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Julian Reschke wrote:
> Joe Touch wrote:
...
>> I have no similar path for UTF-8, at least not yet - the tools I use
>> today that preserve page boundaries (only Wordpad) fails on UTF-8  - it
>> renders them fine on the screen, but when I print them, they are
>> corrupted (they print as if the content is ASCII).
> 
> So, the inability of your preferred tool chain to produce UTF-8 is a
> reason not to *allow* it?

I've shown you that the one I currently use does not. Show me a tool
chain that works.

> Keep in mind that nobody is *requiring* use of UTF-8 (that would be
> silly anyway because any given ASCII text/plain document *is* a UTF-8
> text/plain document by definition).

If you allow the use, and disable my ability to view and print them and
preserve line/page breaks, you've broken functionality I have with ASCII.

> I think it's totally acceptable to allow an extension that helps with
> I18N, even if one of the tools in use to produce RFCs doesn't support it.

"one of the tools" is not the issue; the issue is:

- - is there a writing tool for each major platform we currently use?
	so I can't see how to generate a useful tool for Windows that
	will generate UTF-8. that itself is not a deal-breaker,
	since we have stone-age tools that do work (xml2rfc).

- - is there a reading/printing tool for each major platform, and even
some minor ones, that works?
	that, IMO, is the deal-breaker.

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

iEYEARECAAYFAkjrsk0ACgkQE5f5cImnZrv1jgCgiPnFNJDMV4xgoQHsoHUnP2ku
ITkAoN8ACeLjp60uvgApFMXuBe+tTTQA
=jkpM
-----END PGP SIGNATURE-----