[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.

Yours,
Joel

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
> 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.
>
>   -Tim
>
> 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>>
>     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 <mailto:rfc-interest at rfc-editor.org>
>     https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>
>
>
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>


More information about the rfc-interest mailing list