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

[Jay Daley <[e-mail]>]

> On 19 Jan 2023, at 15:41, Marc Petit-Huguenin <[e-mail]> wrote:
> 
> Signed PGP part
> 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?

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
       point.

   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
       letters.

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

Jay

> 
>> * 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 https://github.com/ietf-tools/xml2rfc/issues
>> 
> 
> --
> Marc Petit-Huguenin
> Email: [e-mail]
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
> 
> 
> 

--
Jay Daley
IETF Executive Director
[e-mail]