Re: [Rfc-markdown] [xml2rfc-dev] [xml2rfc] <br> is back, was: New xml2rfc release: v2.32.0

Henrik Levkowetz <> Fri, 18 October 2019 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B576D120878; Fri, 18 Oct 2019 09:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ePYN0oGurL01; Fri, 18 Oct 2019 09:05:41 -0700 (PDT)
Received: from (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E0F512008A; Fri, 18 Oct 2019 09:05:41 -0700 (PDT)
Received: from ([]:51353 helo=tannat.localdomain) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1iLUl1-0001nH-NF; Fri, 18 Oct 2019 09:05:41 -0700
To: Carsten Bormann <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Cc: Julian Reschke <>, "" <>, "" <>, "" <>
From: Henrik Levkowetz <>
Message-ID: <>
Date: Fri, 18 Oct 2019 18:05:31 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2Oc65U1nxlR1Gcgf740avqkWm18pj7Thn"
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <>
Subject: Re: [Rfc-markdown] [xml2rfc-dev] [xml2rfc] <br> is back, was: New xml2rfc release: v2.32.0
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "rfc-markdown is a discussion list for people writing I-Ds and RFCs in Markdown and the authors of the tools used for that." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Oct 2019 16:05:43 -0000

On 2019-10-18 17:49, Carsten Bormann wrote:
> On Oct 18, 2019, at 16:54, Henrik Levkowetz <> wrote:
>> I'd be more than happy to move to <br/> if we could make that useful for
>> the RPC.
>> I think most people who voiced an viewpoint on that was for making it
>> generally available, but when I proposed how to do that, it seemed to
>> run into opposition again.
> There were some questions about line-breaking in titles in general
> (whether <br/> or U+2028).
> I think that there is wide consensus about using <br/> in favor of
> U+2028.
> The fact that unlike the former, the latter is not visible in the
> schemas makes U+2028 a great way to cheat around the consensus. We
> should not do that.
> As in the question about restricting Unicode character sets, I
> believe that — as long as the vocabulary has a meaning — the schema
> (mechanism) is not the place to make restrictions based on beauty,
> style etc. (policy). So I would prefer to have <br/> in the places in
> the schema where it has well-defined semantics. We can figure out
> later whether this is always, only exceptionally, or never good
> style.

I agree with this.  So again, I propose to permit <br> as a child element
of these elements, where I think the semantics of a <br> would be well-


Should <sub> and <sup> be in that list?  If we compare with the places where
for instance <bcp14> is permitted, the answer would be 'yes'; but I'm not
sure it's the right thing to do.

Coming back to Carsten's point about well-defined semantics, I'm not sure
that is the case for <sub> and <sup>.  Should that imply text stacking
within for instance the <sup>, or should the whole line be broken and the
superscript continued on the next line?  Does that even make sense?