[rfc-i] Character sets, was Comments on draft-iab-rfcformat
hallam at gmail.com
Wed Dec 19 08:24:26 PST 2012
On Wed, Dec 19, 2012 at 11:14 AM, Brian E Carpenter <
brian.e.carpenter at gmail.com> wrote:
> On 19/12/2012 15:29, Paul Hoffman wrote:
> > On Dec 19, 2012, at 12:09 AM, Brian E Carpenter <
> brian.e.carpenter at gmail.com> wrote:
> >> On 19/12/2012 04:59, John R Levine wrote:
> >> ...
> >>>> I am a developer, and when I have to carefully read each word and
> >>>> analyze the meaning of each sentence, there is no better support for
> >>>> me than a printed page in ASCII.
> >>> I also write my share of code that implmenents various standards, and I
> >>> prefer a printed page that looks typeset, not like a 1960s line
> >>> or maybe something on my tablet, or legible on my screen.
> >> Isn't the point that the normative text MUST be unambiguous and
> >> universally displayable/printable?
> > No. The normative text must be unambiguous and displayable by all
> developers of the relevant spec. If one display format of an
> internationalization-related RFC cannot be printed by a routing developer,
> there is no loss to the Internet development community, and a definite gain.
> I disagree. One of the virtues of our way of doing business is that our
> standards are open in principle *and* in practice. I'm not arguing,
> as Phill seems to think, for backwards compatibility with 029 card
> punches and 1960s chain printers. We can assume some degree of modern
> equipment among our readers. But very specifically, a format that
> router developers can't display on their everyday equipment would
> bother me a lot. That would suggest we are partitioning our space.
> So I think we still need a lowest common denominator.
> The problem here is that the lowest common denominator is a moving
> target. We (well, they) set the level about thirty years ago,
> when the DECwriter and the VT05 were the LCD. Now we're trying to
> pick a new level, and it's much harder because there are vastly more
I do not read RFCs on a router LCD.
The issue here that I think should drive the process is enabling the vendor
who wants to sell that router in Russia or Japan to provide a product that
the non-English speaker can use. That means describing how to cope with
passwords and usernames that are expressed in Cyrilic or Kanji including
all the encoding and byte ordering issues that arise from that.
One of the side effects of deciding on UTF-8 as a character encoding is
that suddenly all the traditional arguments over byte alignment become
obsolete as the transmission format of the message is no longer going to be
the same as the in-memory representation (which is typically optimized to
allow indexing by character).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rfc-interest