Re: [xml2rfc] [Ext] [Rfc-markdown] [Tools-discuss] New xml2rfc release: v3.16.0

Marc Petit-Huguenin <marc@petit-huguenin.org> Fri, 20 January 2023 13:08 UTC

Return-Path: <marc@petit-huguenin.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01E6C1524AC; Fri, 20 Jan 2023 05:08:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4Vo7Fr-qmn4; Fri, 20 Jan 2023 05:08:23 -0800 (PST)
Received: from implementers.org (implementers.org [92.243.22.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1ADC1524A6; Fri, 20 Jan 2023 05:08:22 -0800 (PST)
Received: from [IPV6:2601:204:e37f:a6af:d250:99ff:fedf:93cf] (unknown [IPv6:2601:204:e37f:a6af:d250:99ff:fedf:93cf]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 19D48AE232; Fri, 20 Jan 2023 14:08:17 +0100 (CET)
Message-ID: <f9b0e322-1cca-5d1a-3b7e-7f9960818974@petit-huguenin.org>
Date: Fri, 20 Jan 2023 05:08:15 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0
Content-Language: en-US
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Paul Hoffman <paul.hoffman@icann.org>
Cc: "xml2rfc-dev@ietf.org" <xml2rfc-dev@ietf.org>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>, tools-discuss <tools-discuss@ietf.org>, "rfc-markdown@ietf.org" <rfc-markdown@ietf.org>
References: <CAD2=Z87EMetcpv66YY_b2+X1-yFy4cTpKMjPoJL=cH99c7P_Uw@mail.gmail.com> <9d719176-a4eb-7cce-e706-10325700531c@petit-huguenin.org> <4925CBA6-6CF4-40F7-9CF5-E55D2F9CD438@icann.org> <e462d4d3-f121-1fe0-993f-04141fcb614f@petit-huguenin.org> <55552a7a-dca7-31c0-d890-85cf8856a5ef@it.aoyama.ac.jp>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
In-Reply-To: <55552a7a-dca7-31c0-d890-85cf8856a5ef@it.aoyama.ac.jp>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------ow1wn00jlxjABN7AXR5sqL4u"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/6Wj0JtxuAwKM7h6mI9R9hR3gZQ4>
Subject: Re: [xml2rfc] [Ext] [Rfc-markdown] [Tools-discuss] New xml2rfc release: v3.16.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: XML2RFC discussion list <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jan 2023 13:08:27 -0000

On 1/19/23 21:16, Martin J. Dürst wrote:
> On 2023-01-20 02:28, Marc Petit-Huguenin wrote:
> 
>> Responding in the order I received answer.
>>
>> On 1/19/23 08:12, Paul Hoffman wrote:
>>>
>>> On Jan 19, 2023, at 7:41 AM, Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:
>>>>
>>>> On 1/18/23 14:09, Kesara Rathnayake wrote:
>>>>> See https://github.com/ietf-tools/xml2rfc/releases/tag/v3.16.0 for
>>>>> release details.
>>>>>
>>>>> New changes include,
>>>>> * Permit non-ASCII within <t> without the use of <u>.
>>>>
>>>> Isn't an unconditional use of non-ASCII a violation of RFC 7997?
>>>
>>> It should not be, but it would be good to hear which parts of 7997 you think would be violated so we can update the RFC.
>>>
>>
>> I summarized the rules in my response to Jay.  As RFC 7997 clearly listed a finite list of exceptions to the "no Unicode rule".  Permitting Unicode characters in <t> element clearly extends that list, and so violates RFC 7997.
> 
> Let's say I have a draft/RFC-to-be that contains the word "protokol" (Javanese (and probably a few other languages, although not German, that would be Protokoll) for protocol) somewhere inside <t>. As Jay has mentioned (and everybody here knows), our documents are in English, and so the word "protokol" is an error. Can you explain why it is technically allowed inside the <t> element?

I fail to see how this example is related to allowing all Unicode codepoints in <t> or to RFC 7997.

> 
> Please note that the improvement made in xml2rfc v3.16.0 wasn't because somebody wanted to use non-ASCII characters willy-nilly, but because they wanted to follow RFC 7997, but had to resort to hacks to get around unjustified tool limitations.

Again, there was better ways to do that than giving up entirely.

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug