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

Sandy Ginoza <sginoza@amsl.com> Fri, 04 October 2019 19:01 UTC

Return-Path: <sginoza@amsl.com>
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 1B3AB1209FF; Fri, 4 Oct 2019 12:01:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 Wad6G1DiSYdc; Fri, 4 Oct 2019 12:01:01 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD6E1209BC; Fri, 4 Oct 2019 12:01:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 2ECA7203370; Fri, 4 Oct 2019 12:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btb94PEPrarE; Fri, 4 Oct 2019 12:00:13 -0700 (PDT)
Received: from [IPv6:2605:e000:1524:de:7c43:ae21:e098:86ba] (unknown [IPv6:2605:e000:1524:de:7c43:ae21:e098:86ba]) by c8a.amsl.com (Postfix) with ESMTPSA id B7E2A20336C; Fri, 4 Oct 2019 12:00:13 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sandy Ginoza <sginoza@amsl.com>
In-Reply-To: <1f18382c-d830-b887-f5d3-3f376ae4fdd7@gmx.de>
Date: Fri, 4 Oct 2019 12:00:58 -0700
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B15F7AF0-F5A0-401A-9F6E-F7E0E466B6A7@amsl.com>
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>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/OKP4QPLgZLI-tsNyAj-GpdDuT5M>
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: Fri, 04 Oct 2019 19:01:10 -0000

Julian,

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. 

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>


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)

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



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

 
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)


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

Thanks,
Sandy





> On Oct 4, 2019, at 10:23 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 04.10.2019 18:29, Julian Reschke wrote:
>> On 04.10.2019 17:34, Henrik Levkowetz wrote:
>>> ...
>>> I'm strongly for having an explicit <br/> element.
>>> 
>>> Given a clearly expressed need from the RPC, I will always try to provide
>>> tools to make it possible for them to do their work.  Without having
>>> <br/>
>>> available, this was a fallback solution.  Continuing to ignore clearly
>>> expressed needs of the RPC seems unproductive.
>>> ...
>> 
>> I would like the RPC to actually raise these issues here, so that we can
>> discuss them.
>> 
>> In this case, I'd really like to understand in which contexts this was
>> considered to be needed.
>> ...
> 
> So in the current AUTH48 XML files, I see one case where U+2028 is used:
> apparently, to force breaks line breaks into the content of a
> <blockquote>. However, the content model for <blockquote> actually
> allows multiple paragraphs; see
> <https://greenbytes.de/tech/webdav/rfc7991.html#element.blockquote>. I
> really like to understand why that approach did not work for the RPC.
> 
> Best regards, Julian
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc