Re: [rfc-i] Unicode in xml2rfc v3

On 12/18/20 2:38 PM, Eric Rescorla wrote:
> On Fri, Dec 18, 2020 at 9:16 AM Marc Petit-Huguenin <marc@petit-huguenin.org>
> wrote:
> 
>> On 12/17/20 12:10 PM, Jay Daley wrote:
>>>
>>>
>>>> On 18/12/2020, at 9:00 AM, Brian E Carpenter <
>> brian.e.carpenter@gmail.com> wrote:
>>>>
>>>> On 17-Dec-20 19:57, Lars Eggert wrote:
>>>>> Hi,
>>>>>
>>>>> On 2020-12-16, at 20:48, John Levine <johnl@taugh.com> wrote:
>>>>>> In article <BB864858-1E71-45CF-9411-2ECB003B5EC0@eggert.org> you
>> write:
>>>>>>> It's ridiculous that I can't just write α when I mean α.
>>>>>>
>>>>>> I agree with you but I don't yet see how we get from here to there or
>> exactly
>>>>>> where there is.
>>>>>
>>>>> I think it was Julian who proposed to lift the restriction on Unicode
>> to only be allowed in <contact> and instead rely on the community (at the
>> I-D stage) and the IESG/ISE/RPC for when I-Ds become RFCs to check for
>> "abuse" of Unicode (which I struggle to see happening in practice.)
>>>>
>>>> Agreed. I think the original decision to be very restrictive was due to
>> general concerns about moving away from .txt as the primary format. How π,
>> still less emojis, will be rendered in ASCII remains an issue, but just as
>> RFC1119 worked out fine, I think we should get over the fact that some (or
>> most) future RFCs simply won't work in .txt.
>>>
>>> Can someone explain to me why our .txt files have to be ASCII?  I doubt
>> I have a single text tool left that can’t process UTF-8.
>>>
>>
>> Because non-ASCII characters cannot improve a well-written RFC -- or a
>> well-written program for that matter.
> 
> 
> I don't think I agree with this. For instance, while yes it's possible to
> formally specify the code points for emoji in hex or whatever, it's
> certainly easier to read the text if you can see them, I think.
> 

CLDR short names, prefixed in a similar way than Unicode codepoints (e.g. <N+ROMAN NUMERAL NINE> for <U+2178>) could still be translated to their graphical equivalent in HTML and PDF, but will not make me want to gouge my eyes when implementing from the text format.

In a way, this is to programmers what the alt attribute is for the blind and visually impaired.

(Yes, I believe that the printed paginated text version of a standard is the proper way to implement a standard.  And carrying non-hypertext files in HTTP is in bad taste.  And milk should be poured first in the tea cup)

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest