IETF Logo Mail Archive

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

Marc Petit-Huguenin <marc@petit-huguenin.org> Thu, 19 January 2023 20:46 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 3E359C14F74A; Thu, 19 Jan 2023 12:46:25 -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 S28E4L49ri9K; Thu, 19 Jan 2023 12:46:21 -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)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36AEC14F5E0; Thu, 19 Jan 2023 12:46:20 -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 70EDDAE232; Thu, 19 Jan 2023 21:46:17 +0100 (CET)
Message-ID: <6d55cf67-1ce2-8094-dda4-ab877ac2a1d7@petit-huguenin.org>
Date: Thu, 19 Jan 2023 12:46: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: "Salz, Rich" <rsalz@akamai.com>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>, tools-discuss <tools-discuss@ietf.org>
References: <CAD2=Z87EMetcpv66YY_b2+X1-yFy4cTpKMjPoJL=cH99c7P_Uw@mail.gmail.com> <9d719176-a4eb-7cce-e706-10325700531c@petit-huguenin.org> <F1A5624B-16D0-4463-AC5F-B0A03F3B94B6@ietf.org> <8f5a497e-4135-7c0c-46cb-c3fe4791e9f3@petit-huguenin.org> <3B53040D-9B5F-4410-9029-459729ADFDF8@ietf.org> <7d532a76-c750-8cb6-fc86-f6242da2bc77@petit-huguenin.org> <27182BDD-899E-4238-9DF8-7AE3E0F0C18F@akamai.com> <11a20f42-4fe6-8d8d-1d76-54049d0bdb68@petit-huguenin.org> <6179D431-EC33-49B9-A793-805E926C1050@akamai.com>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
In-Reply-To: <6179D431-EC33-49B9-A793-805E926C1050@akamai.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------D2bcidYpD3E3oYbamdIDKqpG"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/RQFeA_vP-Dzy68g7WdZEwqmILg8>
Subject: Re: [xml2rfc] [Tools-discuss] [Rfc-markdown] 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: Thu, 19 Jan 2023 20:46:25 -0000

On 1/19/23 12:35, Salz, Rich wrote:
> Thank you for your reply.
> 
>> Obviously when I say add a new element to the language, it means create a RFC7991bis that does that modification. And then modify the xml2rfc tool to match the new spec.
> 
> Wasn't obvious, I appreciate the clarification. But if you're modifying the XML language, why not just remove the limitations on non-ASCII that have been found to be problematic?

Because what I find to be problematic is allowing Unicode everywhere.  My proposal of following RFC 7997 to the letter instead of sneakily circumvent it has, among others, the advantage of not allowing emojis in a document generated by xml2rfc.  I cannot think of a more important goal for the future of humanity.

> 
> I would also appreciate your thoughts on this point as it seems your rationale is all about the "violations" you cite.
> 
>> I'm not even sure "violate 7997" is even a sensible thing to say, since that is an INFORMATIONAL RFC. So, for that matter, is RFC 7322.
>>
>> See, for example, https://www.ietf.org/standards/process/informational-vs-experimental/ <https://www.ietf.org/standards/process/informational-vs-experimental/> and RFC 2026.
> 
> 
> 

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

v2.30.2 | Report a Bug | By Email | System Status