[rfc-i] Character sets, was Comments on draft-iab-rfcformat

Paul Hoffman paul.hoffman at vpnc.org
Wed Dec 19 07:29:30 PST 2012

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.

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 mailing list