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

Marc Blanchet marc.blanchet at viagenie.ca
Wed Dec 19 09:41:12 PST 2012


Le 2012-12-19 à 10:51, Tim Bray a écrit :

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

I agree with this.

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

Agree.

Marc.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20121219/e59a6782/attachment-0001.htm>


More information about the rfc-interest mailing list