[rfc-i] Character sets, was Comments on draft-iab-rfcformat
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?
More information about the rfc-interest