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

Henrik Levkowetz <> Fri, 18 October 2019 17:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29F9412011F; Fri, 18 Oct 2019 10:36:18 -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 wKbVRf2N1e_E; Fri, 18 Oct 2019 10:36:17 -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 01E98120118; Fri, 18 Oct 2019 10:36:17 -0700 (PDT)
Received: from ([]:51755 helo=tannat.localdomain) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1iLWAh-0001xp-Nq; Fri, 18 Oct 2019 10:36:16 -0700
To: Carsten Bormann <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Cc: Julian Reschke <>, "" <>, "" <>, "" <>
From: Henrik Levkowetz <>
Message-ID: <>
Date: Fri, 18 Oct 2019 19:36:07 +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="hfiKNBooMjpfaF72Rip1vowbKvlva4N9D"
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 17:36:18 -0000

Hi Carsten,

On 2019-10-18 18:53, Carsten Bormann wrote:
> On Oct 18, 2019, at 18:05, Henrik Levkowetz <> wrote:
>> 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?
> To me this sounds like any use cases would involve math, which should be handled separately.
> If we are unsure about the semantics, we should not put that nesting in.
> We can always amend the schema; we just don’t want to amend the existing instances that need to conform to any new version.
> I share Julian’s curiosity about the use cases (really: intended semantics) for title/br.

I wrote about this last year.  But essentially, it's a matter of how to
break a long title; of making it possible to break a long title in at a
point that makes sense for a reader.  Two cases where the document title
is too long to display nicely, and line breaking helps/would help:

    (or, if you prefer)

 2) In a PDF rendering received from the RPC, the title of RFC8648-to-be,
    "RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)"
    broke across lines as follows:

      RADIUS Attributes for Softwire
      Mechanisms Based on Address plus Port (A

    which is less than perfect.  Having <br/> as a tool makes sense to me
    here too.

> The one example we can see in RFC-8668-to-be is
>   <li><t>L2 Bundle Member Link Local Identifiers&br;
>   (4 * Number of L2 Bundle Member Descriptors octets)</t>
> where I think we already have consensus that this should go in.


> (And, yes, defining the entity as <br/> is a nice way to make that transition.)