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:31 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 13893C14CF0D; Thu, 19 Jan 2023 12:31:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rUwYgzwUbY5b; Thu, 19 Jan 2023 12:31:10 -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 BA177C14F738; Thu, 19 Jan 2023 12:31:09 -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 971BAAE232; Thu, 19 Jan 2023 21:31:07 +0100 (CET)
Message-ID: <11a20f42-4fe6-8d8d-1d76-54049d0bdb68@petit-huguenin.org>
Date: Thu, 19 Jan 2023 12:31:05 -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>, Jay Daley <exec-director@ietf.org>
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>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
In-Reply-To: <27182BDD-899E-4238-9DF8-7AE3E0F0C18F@akamai.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------rhJAu0QI2wZUr04k7MPQNA1K"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/_WhVn_yeW_tWPss--iWMcR5RBW4>
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:31:14 -0000

On 1/19/23 11:49, Salz, Rich wrote:
>> Or, as I proposed above, create a new element in the xml2rfc language that tags a word as permitted to use Unicode in it, e.g., "<loanword>attaché</loanword>". That can be mechanically verified against a dictionary, does not require to lookup each word, and clearly prevents things that are not authorized by RFC 7997.
> 
> Doesn't adding a new XML element violate RFC 7997?  

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.

> I'm not sure how that would be used.  Is the new loanword able to appear anywhere in the text?

I would suggest anywhere in <t>.

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