Re: [Tools-discuss] placing < and > in artwork renders broken html

Carsten Bormann <cabo@tzi.org> Thu, 06 May 2021 04:58 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAA63A0AF9 for <tools-discuss@ietfa.amsl.com>; Wed, 5 May 2021 21:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.217
X-Spam-Level:
X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w9diHHBpygc for <tools-discuss@ietfa.amsl.com>; Wed, 5 May 2021 21:58:49 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3223A0AF7 for <tools-discuss@ietf.org>; Wed, 5 May 2021 21:58:49 -0700 (PDT)
Received: from smtpclient.apple (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FbLvV3JQ7z101m; Thu, 6 May 2021 06:58:46 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_26408F39-51CE-4B7C-8CC5-9B9055C0FC69"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <3b649680-b123-781b-e81b-f129f2a146fe@nohats.ca>
Date: Thu, 06 May 2021 06:58:45 +0200
Cc: tools-discuss@ietf.org
Message-Id: <8DF71730-F34D-41D1-863F-2CDCACEBEB21@tzi.org>
References: <3b649680-b123-781b-e81b-f129f2a146fe@nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/GgorZoWoibd1XmJX9Jtfcy6-_ew>
Subject: Re: [Tools-discuss] placing < and > in artwork renders broken html
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2021 04:58:54 -0000

Hi Paul,

> <artwork>    struct {
>        uint16 ExtSupportLifetime;
>        opaque AuthenticationChain&lt;1..2^16-1&gt;;
>    } DnssecChainExtension;
> </artwork>

That is what <[CDATA[ sections are good for:

<artwork><![CDATA[
  struct {
      uint16 ExtSupportLifetime;
      opaque AuthenticationChain<1..2^16-1>
  } DnssecChainExtension;
]]></artwork>

(This example generated by “the rfc markdown stuff”.)

> but the rendered html (from www.ietf.org/staging/) displays:
> 
>    struct {
>        uint16 ExtSupportLifetime;
>        opaque AuthenticationChain&lt;1..2^16-1&gt;
>    } DnssecChainExtension;

Care linking to the specific file?

The specific example above generates this html for me:

<div class="artwork art-text alignLeft" id="section-1-10">
<pre>
  struct {
      uint16 ExtSupportLifetime;
      opaque AuthenticationChain&lt;1..2^16-1&gt;
  } DnssecChainExtension;
</pre><a href="#section-1-10" class="pilcrow">¶</a>
</div>

Which renders as attached below (not sure that will make it through this ML).

> If use literal < or >, then xml2rfc complains and won't render my .txt output.

As it should.

> Worse but unrelated, the rfc markdown stuff generates &amp;lt; _and_
> changes all quotes to &quot; and yes these two bugs amplify each other.

I don’t know which rfc markdown stuff you are referring to (there is a choice!), but see above for what is generated by rfc-kramdown.

We wouldn’t have got to RFC 9000 if what you are experiencing were a common problem, so we do need to know some details.

Grüße, Carsten