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

"HANSEN, TONY L" <> Mon, 07 October 2019 02:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB88D120152; Sun, 6 Oct 2019 19:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id urYfef5J21SF; Sun, 6 Oct 2019 19:20:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2488712001E; Sun, 6 Oct 2019 19:20:46 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x972FtCH021087; Sun, 6 Oct 2019 22:20:30 -0400
Received: from ( []) by with ESMTP id 2vfjyu0ckv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 06 Oct 2019 22:20:30 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id x972KThL029621; Sun, 6 Oct 2019 22:20:29 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id x972KORu029577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 6 Oct 2019 22:20:24 -0400
Received: from ( []) by (Service) with ESMTP id 4903C4039341; Mon, 7 Oct 2019 02:20:24 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id 34B814039340; Mon, 7 Oct 2019 02:20:24 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0468.000; Sun, 6 Oct 2019 22:20:23 -0400
From: "HANSEN, TONY L" <>
To: Brian E Carpenter <>, Julian Reschke <>, Sandy Ginoza <>
CC: "" <>, "" <>, "" <>
Thread-Topic: [xml2rfc-dev] [xml2rfc] [Rfc-markdown] <br> is back, was: New xml2rfc release: v2.32.0
Thread-Index: AQHVezaFMEgSoF1oAEOT9Ggohrbn56dOdR0A
Date: Mon, 7 Oct 2019 02:20:22 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <19D71E6AAA279047A1DEE7A1305701EE@LOCAL>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-06_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910070023
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: Mon, 07 Oct 2019 02:20:48 -0000

On 10/5/19, 12:36 AM, "xml2rfc-dev on behalf of Brian E Carpenter" < on behalf of> wrote:

    Hi Julian,
    On 05-Oct-19 17:08, Julian Reschke wrote:
    ....> The point of the xml2rfc vocabulary is to markup things based on their
    > semantics, not based on a certain desired plain text output.
    Fair enough; if we want to illustrate a point with a plain text example, then <artwork> seems appropriate. But I think we are talking about something else: cases where we *want* the text to stop here
    and continue on the next line, whatever output format (including HTML) we are using.
    > If we can't get acceptable *HTML* output, let's consider the use case
    > and come up with a proper solution (which might be <br/>).
    It applies to PDF etc too.
    > Why do these need to be on separate lines? (I don't understand the
    > context yet...)
    Ah, but a tool designer doesn't *need* to understand the context. If the author *wants* a line break, that's all we need to know.
    > (And yes, there was ample time to have this dicussion; RFC 7991 finished
    > three years ago).
    I'm a bit confused:

And one of the things that is SUPPOSED to happen post publication is for real use to provide feedback on how to fix any glitches that were found trying to use it.

Well, we're trying to use it for real now.

Sandy, does the RPC feel that the ability to add a line break is needed? If so, I think the answer is clear on what to do.