[rfc-i] Character sets, was Comments on draft-iab-rfcformat
Brian E Carpenter
brian.e.carpenter at gmail.com
Wed Dec 19 08:14:05 PST 2012
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 printer,
>>> 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
> At least one of the formats for a particular RFC should be printable on a wide variety of printers.
>> I don't think that imposes ASCII,
>> but it is still a very strong constraint.
> We disagree that it is a constraint. If some of the formats are aimed at ASCII-based readers, that's great. Hobbling all the formats of an RFC for this rule makes RFCs more ambiguous.
>> In a sense, ASCII is the
>> lazy way to implement that constraint. Saying "any Unicode and any
>> font is allowed" clearly does not meet the constraint. We have to be
>> somewhere in between.
> Why? If some of the formats allow any Unicode character, and those are useful to the developers involved, what is the problem?
> --Paul Hoffman
More information about the rfc-interest