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

Julian Reschke <julian.reschke@gmx.de> Sat, 05 October 2019 04:14 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: rfc-markdown@ietfa.amsl.com
Delivered-To: rfc-markdown@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C166A120086 for <rfc-markdown@ietfa.amsl.com>; Fri, 4 Oct 2019 21:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 8L5fK0lhD0jY for <rfc-markdown@ietfa.amsl.com>; Fri, 4 Oct 2019 21:14:47 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67544120020 for <rfc-markdown@ietf.org>; Fri, 4 Oct 2019 21:14:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1570248884; bh=8cYXg9L10SGHk1rOHP0c+UA1nxDoX4uPp8hALpGqPpo=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=XTbozNkeDZUCdDiMIAOE21gKgxhKb/blxgXPu2PmaquuCHY34uIPsWCYpGv0L2uEy KwJjKF1R1FqYEn35JA7ClNC1NRHMGreRWTrhNyXJqNQ73/27f53kf39Ars9+NFVZtD tJ5y2m+Nx3P+BVxZFmWQacjjwWHhZWJqPcCZBc0w=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([91.61.50.178]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MPGW7-1iT1xt2DHR-00PZho; Sat, 05 Oct 2019 06:09:04 +0200
To: Sandy Ginoza <sginoza@amsl.com>
Cc: Henrik Levkowetz <henrik@levkowetz.com>, "HANSEN, TONY L" <tony@att.com>, "xml2rfc-dev@ietf.org" <xml2rfc-dev@ietf.org>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>, "rfc-markdown@ietf.org" <rfc-markdown@ietf.org>
References: <E1iGMu9-00055y-Ui@durif.tools.ietf.org> <8304e61d-c550-91ea-9e23-eef2cd31240b@gmx.de> <A3513970-EEB0-4DBD-9E6F-A87EBFAF886D@att.com> <de4feaff-8f71-cd38-545c-2d848749251b@levkowetz.com> <f00a671a-6fe4-f5ae-2582-0b78ffa1c256@gmx.de> <1f18382c-d830-b887-f5d3-3f376ae4fdd7@gmx.de> <B15F7AF0-F5A0-401A-9F6E-F7E0E466B6A7@amsl.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <f4f1b7ba-127a-fbfa-531b-eeff03814281@gmx.de>
Date: Sat, 5 Oct 2019 06:08:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <B15F7AF0-F5A0-401A-9F6E-F7E0E466B6A7@amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:adh2zlOcPIxymhuU/ZZ8VSv9fAn10aqVimGFz4oMVNxeWgwbrzE hQjinKDNSu7E7HE+wRC7u0p3Q/ytZgS01wvcJ1x7s6a6LKGe8kH8g11VC7VjRYr5rmBirn2 ALXfekh/XO2V8aQ3+KaMDO1pLTa6CzkECr2hthMMDGJJX36Ex1FVhmUwJg49yrRRt9IKJY3 KNTjpg0qXmo8gx5bpgj0w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:VNrweocjzuU=:ErOlBw5k1Sb8frSEai8+AP ogIhuq4cgzSsd5oy6Y9116tEvXipzaCg//BFQJahqKxFu9G6BAz6BVc9jqCt+AKAu+u/syxf0 Uwa70m8abRb1R0XPjYjtzbhgjj+hhCKuI6ApIBOzEUeMcrVxUccd8/6hYUFWJdDQkp9gzyrp1 DATB2OwjsIwy53bXi4+cQNQSUkSXNBJoWwprLXYn2DIcS9nem8Sio7RtdbGd8D3T+RFYebXJ0 LJQbgj0aG3ZsK6iWI+SsiSgtBJoJLrQS4Pem0jBbEK7mLo47s1AcJQhL24ylbgnJT+Ck+lnZN ndsPbrhXIGprPGDvyp0g3m9bQQhmJf42y4V7SJuMJmH48uX6mjnSBhgqEtFU6A84cTmcPkUEC vJQyCMK6uhmFWsuutQyOC2cMwS7DS0vHegR0ScZBKB5EGrmrZM3o4BZkcA1eXLiNbjCbNpFqF TCHeAZXIL1DZK4P61czrSTB/Wv/kEPH0X8aUOZWM7iure4hjy9714FGf4HBRD/Dq1qwXp5uNB /52ppIcbWcx2MRrv2I1R0ZlEpz8SK2/EC7cZNf1krYlcG4NOA0GTmkoqsqiWcwdbATMBzgr7Z Lkp4In4CnyJ3bBl7faVEC9FuqIJ1kaEgeGDm+eF/JB/ryQfPvWLTjZxqfOUBgJvWnsZqeyJhR CpjtIti1IPspmHbF7JfVOvLj49nxpQds69iStA049QKzrdFCSlxkMoz7Z76BDIUPaJ7mSCS4u Ol+wS5B88KQyGsY4W9P2ncpXt3z2Gkeb1PSldNnEYsUOeAKOOwZOBe6Rb3fUBy4rUfTprQ6tx 9c5gdT/Ypqg2Qmpj3mktgbTBUR7vqcr5/6icGzfxk9yzG3ZHanesHWFuZTBeQWfECeF45V0J+ AAVVjd7t8cNH+BAbwc2UXr5ICrPGdUMQCYU2BfPVK3FAxqz8y+PqAjvPKHcAGX0XfxDs0ePPI bn/16XfWO4fb82pRuNIfLIBytICqoIgFCb8/GvNpu2/7pcYpPibVkiEx3Expfjns2ldPa9c31 26G9BT7lySjzEKYyyehvRiW8ozGjH0s2jzn+AJW6xJNH2X9kAiTpNChwgSsnvuuZ4sIqMQLcZ cFe/ERHmwDgkjdlaQpYfjDy416DokpwairCOk4OrfcflQOEr1pPf4cP3P7S0gIL0C/paEkxMq 12dI3kklZBTFzaPNb/AjrDI8jY3Slr5qBgU7vMUYGe68vjA8YM4350zTYCwLrNAedhTtP280O iwJ1WSzQDoTMpt7oAXBmbZdDnxktwdJ1ej4CtgQn7wRoUMWzzvfip9KqmjcQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/WVOY65t_N9jR8zwqSc24yOt6y64>
Subject: Re: [Rfc-markdown] [xml2rfc] [xml2rfc-dev] <br> is back, was: New xml2rfc release: v2.32.0
X-BeenThere: rfc-markdown@ietf.org
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." <rfc-markdown.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-markdown/>
List-Post: <mailto:rfc-markdown@ietf.org>
List-Help: <mailto:rfc-markdown-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Oct 2019 04:14:50 -0000

On 04.10.2019 21:00, Sandy Ginoza wrote:
> ... > I believe the editor used U+2028 here to avoid additional blank lines
within the quote.  This is what we get when we use <t> tags.
>
>    |  The packet PW appears as a single point-to-point link to the
>    |  client layer.  Network-layer adjacency formation and maintenance
>    |  between the client equipments will follow the normal practice
>    |  needed to support the required relationship in the client layer.
>    |
>    |  ...
>    |
>    |  This packet pseudowire is used to transport all of the required
>    |  layer 2 and layer 3 protocols between LSR1 and LSR2.
>
>
> I don’t think &br; is needed here, but see the examples below.

My first reaction was that if the citation skips a paragraph, then
having the dots on a separate line would be the right thing.
Alternatively, if text inside a paragraph was skipped, I'd use inline "
... " or " (...) ".

So I checked the source of the citation and found that the first part is
from <https://tools.ietf.org/html/rfc6658#section-3>, while the second
part is extracted from the previous section. So I would argue that this
is a strange use of <blockquote>. These should be *two* <blockquote>s.

 > ...
> a) This issue has come up quite a bit when we were trying to update lists/sublists where the authors want no whitespace between the indented items (no bullets; just a line break).  For example, RFC 8668 (v3 files not yet posted) contains the following in the v2 text:
>
>        L2 Bundle Member Attributes
>
>           Type:  25
>           Length:  Number of octets to follow
>
>        Parent L3 Neighbor Descriptor
>
>           L3 Neighbor System ID + pseudonode ID (7 octets)
>           Flags: 1-octet field of the following flags:
>
> We were able to replicate this spacing with the following XML, which seems bad because we have empty <dd/> to get the right spacing.  If there is a better way to do this, please let us know.
>
> <ul empty="true">
> <li>
> <dl spacing="compact"><dt>L3 Neighbor System ID + pseudonode ID (7 octets)
> </dt><dd></dd>
> <dt>Flags: 1-octet field of the following flags:</dt><dd></dd>
> </dl>

Well, the obvious answer is: don't. If it's not a definition list, don't
use <dl>.

In general, we really need to stop to focus on the TXT output. Bending
the vocabulary to get precisely a certain text output is the wrong path.
What's really relevant is getting proper *HTML* output.

I have my doubts that an extra blank line here is really a problem.

> b) A similar example about trying to force a line break: Is there a better way to do this?
>
> section 3 of https://www.rfc-editor.org/v3test/rfc8668_AR2.txt
> https://www.rfc-editor.org/v3test/rfc8668_AR2.xml
>
> Desired output:
>
>           L2 Bundle Member Link Local Identifiers
>           (4 * Number of L2 Bundle Member Descriptors octets)
>
> How we forced the break in XML:
>
>      <t>L2 Bundle Member Link Local Identifiers (4&nbsp;*&nbsp;Number&nbsp;of&nb\
> sp;L2&nbsp;Bundle&nbsp;Member&nbsp;Descriptors&nbsp;octets)</t>
>
> text output is good enough:
>           L2 Bundle Member Link Local Identifiers
>              (4 * Number of L2 Bundle Member Descriptors octets)

But HTML will put it onto one line is the viewport is wide enough.

> ----
> same thing as above, but with a different use of <ol>:
>
> section 3 of https://www.rfc-editor.org/v3test/rfc8668_AR4.txt
> https://www.rfc-editor.org/v3test/rfc8668_AR4.xml
>
> text output:
>        -  L2 Bundle Member Link Local Identifiers
>           (4 * Number of L2 Bundle Member Descriptors octets)

I believe the answer is the same as above. Don't. Please really consider
whether this is worth the effort. In any case: do not try to add
workarounds to get a certain plain text output. Plain text is a
secondary output format.

The point of the xml2rfc vocabulary is to markup things based on their
semantics, not based on a certain desired plain text output.

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

> c) Re: https://www.rfc-editor.org/authors/rfc8652.html#section-5
>
> Uused two <artwork>s to get
>
> Under /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/igmp-mld:igmp,
>
> and
>
> Under /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/igmp-mld:mld,
>
> to appear w/ the (seemingly) desired line break. If it were considered running text, then <t> would be right, but there's no <br>.
> (Guess we could use <t> and a bunch of &nbsp; and &wj to prevent each 2nd line from breaking, but that seems not ideal.)

Why do these need to be on separate lines? (I don't understand the
context yet...)

> d) The most recent issue has been resolved by the adjustment of font size in the PDF, but the title of the RFC 8658 (also not yet posted) appeared ok in the .html and .txt files, but the PDF was breaking as follows:
>
> RADIUS Attributes for Softwire
> Mechanisms Based on Address plus Port (A
> +P)

If it breaks inside "A+P" instead of using the whitespace two characters
before than this looks like a bug in the formatter to me.

> It has been a struggle to convert some of these files and Henrik has been kind enough to review cases and provide input.

Understood.

I just don't think that re-introducing line breaks through the back door
is the right thing here. If they are needed, let's discuss them as as
part of the vocabulary.

(And yes, there was ample time to have this dicussion; RFC 7991 finished
three years ago).

Best regards, Julian