[rfc-i] Character sets, was Comments on draft-iab-rfcformat
tbray at textuality.com
Wed Dec 19 07:51:22 PST 2012
It’s clear the members of this mailing list are highly unqualified to make
judgment calls as to which characters strike the best balance between
readability and universal availability. It turns out these trade-offs are
more complex than you thought; for example, popular mobile devices leave
out some surprisingly popular non-ASCII characters in the interests of
saving space. Anyone who couches the discussion in terms of supporting (or
not) “UTF-8” reveals their incompetence in these matters.
The constituency urging the preservation of the legacy ASCII-line-printer
format can be safely ignored. There is no constituency calling for the
carefree use of everything in Unicode. I suggest that the selection of
character repertoires be explicitly left to the authors of drafts, the
working groups that review them, and the IESG. In this scenario, arguments
about character sets will happen very rarely, and always in the context of
the specific needs of a specific draft spec, which is as it should be.
Yes, as Paul noted elsewhere, I should express my opinion more specifically
in terms of Heather’s draft. I’ll do that.
On Wed, Dec 19, 2012 at 7:29 AM, Paul Hoffman <paul.hoffman at vpnc.org> 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.
> 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
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rfc-interest