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

Jay Daley <> Thu, 19 January 2023 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BFF5C151525 for <>; Thu, 19 Jan 2023 08:01:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OkyQS9fk78gH for <>; Thu, 19 Jan 2023 08:01:05 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 04C56C14CE5F for <>; Thu, 19 Jan 2023 08:01:04 -0800 (PST)
Received: by with SMTP id fl11-20020a05600c0b8b00b003daf72fc844so3910765wmb.0 for <>; Thu, 19 Jan 2023 08:01:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cYtpciCVbvbfEZrU8p72X1pzDcGiAYv7Z0/uFjWCSmE=; b=5JKUFfzC1cMBvdkJU2p73BzXsHLSgjd3qvuQctwjM04KWzpFKrYbyhLgqWU36PSDuQ KVTt/Qj1H+Ap238mcqpZxgJ+uDJ3hys34rOxAuNowNYOy39HRD1ZWOC4a4Vnn5NbD201 TE61yREvjekPK4wm7kUg9VJqG0A4wlIzlqlt+vAy+nFQMu/dyAh+XpHsMDfJ607GQPHt 5mfXVYPanaQjf/W10HUtS64J+cZi76BgPUhDVxuL/scOy051msDYd6tc4hmraaYEiyBu 13u7knOQAg4tNTCj35i4w4MBfuUe4wbgIQREyHvuvoNDZvEZPnDyQSusuDWwYNQY8teP GXnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cYtpciCVbvbfEZrU8p72X1pzDcGiAYv7Z0/uFjWCSmE=; b=zIB12QFjgQsBhhk+S2T52obr7blzx3ybptwbn9axbQulE7O4hJO67qs8isrpEway1v GJZEqpNSbljKi5ltUQODP5ya5wHgvxo/nYAa+7qPS+v0xgOmBCkosd6zUcM81lE1vB9X VKy6jdc9PBhzsrbC4DCzwLJzcOtjb2xVrNjzgseGXfkeCO0eFm/fDhW59C+4kj/FF6C0 eHatreMYiPwF26+Fz2+0QL5cF/QOUHuyKbJPejWOfApnj4OV2SBDE11peNSO8f2aBdzn h8WLuo3bt9A4WnXXxUTo49vP87qlUf4bVo8KFwH3VoVPkRNfbBIfBA0CZmX2GLqv86y8 HsGw==
X-Gm-Message-State: AFqh2kpog7qK/OvkX5Io1L2RI6XPI0VZSg43ndSnnk6jfqKEMEMHo+ww zT99J2zeGKK14C1xS4Y19ayTXFf5os11xilRmgAn6g==
X-Google-Smtp-Source: AMrXdXvV5fs5IjN9CAznvoB4mcPgK3XphaezNkiCWuM4IxJIsoPCmfwuSQUCfJwv7b/DvQNv371ybA==
X-Received: by 2002:a05:600c:3d10:b0:3d9:ee3d:2f54 with SMTP id bh16-20020a05600c3d1000b003d9ee3d2f54mr19381236wmb.13.1674144062900; Thu, 19 Jan 2023 08:01:02 -0800 (PST)
Received: from ( []) by with ESMTPSA id r8-20020a05600c35c800b003daf672a616sm6160174wmq.22.2023. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2023 08:01:02 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_404EFD7F-788A-44FB-8327-6D2DB0F7BBE0"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
From: Jay Daley <>
In-Reply-To: <>
Date: Thu, 19 Jan 2023 16:01:00 +0000
Cc: Kesara Rathnayake <>,, tools-discuss <>
Message-Id: <>
References: <> <>
To: Marc Petit-Huguenin <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
Subject: Re: [xml2rfc] [Rfc-markdown] [Tools-discuss] New xml2rfc release: v3.16.0
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: XML2RFC discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jan 2023 16:01:10 -0000

> On 19 Jan 2023, at 15:41, Marc Petit-Huguenin <> wrote:
> Signed PGP part
> On 1/18/23 14:09, Kesara Rathnayake wrote:
>> See 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?

Section 3.4 says:

   When the mention of non-ASCII characters is required for correct
   protocol operation and understanding, the characters' Unicode code
   points must be used in the text.  The addition of each character name
   is encouraged.

   o  Non-ASCII characters will require identifying the Unicode code

   o  Use of the actual UTF-8 character (e.g., (See PDF for non-ASCII
       character string)) is encouraged so that a reader can more easily
       see what the character is, if their device can render the text.

   o  The use of the Unicode character names like "INCREMENT" in
       addition to the use of Unicode code points is also encouraged.
       When used, Unicode character names should be in all capital

<u> is a convenient way of ensuring that this happens because it is recognised by xml2rfc and processed in line with those bullets above.  However, note that the text says "is required for correct protocol operation" and that does not cover such usage an example where the specific character chosen for that example doesn’t matter (e.g. when demonstrating output using RTL script).  Under such circumstances non-ASCII characters should be allowed without the adornment listed above.

The previous implementation of <u> (which btw was added after RFC 7991 and so never had consensus) requires a <u> for *all* non-ASCII characters and so exceeded the requirement of 3.4 above.  This change now allows non-ASCII to be used without a <u> being enforced automatically but it does not mean that 3.4 will be ignored for RFCs.  <u> will still be required for RFCs to follow the principle of "required for correct protocol operation" and it will for the RPC, authors and stream owners to work that out.


>> * Add editorial stream.
>> * New flag --warn-bare-unicode when set, xml2rfc warns about bare
>> Unicode in the <t> elements. By default, this is set to False.
>> Report any issues on
> --
> Marc Petit-Huguenin
> Email:
> Blog:
> Profile:

Jay Daley
IETF Executive Director