[rfc-i] Character sets, was Comments on draft-iab-rfcformat
Joel M. Halpern
jmh at joelhalpern.com
Wed Dec 19 09:07:55 PST 2012
A couple of minor aspects worth noting:
1) There are RFCs which are not from IETF WGs approed by the IESG.
2) The RFC Editor is specifically harged wit keeping a coherent series.
Saying that each document can do whatever it (the authors, and
whomever they can persuade at the time) wants is not a recipe for coherence.
On 12/19/2012 10:51 AM, Tim Bray wrote:
> 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
> 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
> <mailto:paul.hoffman at vpnc.org>> wrote:
> On Dec 19, 2012, at 12:09 AM, Brian E Carpenter
> <brian.e.carpenter at gmail.com <mailto:brian.e.carpenter at gmail.com>>
> > 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.
> 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 <mailto:rfc-interest at rfc-editor.org>
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest