IETF Logo Mail Archive

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

"HANSEN, TONY L" <tony@att.com> Fri, 04 October 2019 20:57 UTC

Return-Path: <tony@att.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 3654E12001A; Fri, 4 Oct 2019 13:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 azt4NWLW-Gt4; Fri, 4 Oct 2019 13:57:29 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699A1120013; Fri, 4 Oct 2019 13:57:29 -0700 (PDT)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id x94KurId039202; Fri, 4 Oct 2019 16:57:24 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 2vedjgg09m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Oct 2019 16:57:24 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x94KvMW0024189; Fri, 4 Oct 2019 16:57:23 -0400
Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x94KvHNr024125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Oct 2019 16:57:17 -0400
Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 1802B402EFAA; Fri, 4 Oct 2019 20:57:17 +0000 (GMT)
Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (unknown [130.9.129.151]) by zlp27126.vci.att.com (Service) with ESMTPS id 02D05402EF95; Fri, 4 Oct 2019 20:57:17 +0000 (GMT)
Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.170]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0468.000; Fri, 4 Oct 2019 16:57:16 -0400
From: "HANSEN, TONY L" <tony@att.com>
To: Sandy Ginoza <sginoza@amsl.com>, Julian Reschke <julian.reschke@gmx.de>
CC: Henrik Levkowetz <henrik@levkowetz.com>, "xml2rfc-dev@ietf.org" <xml2rfc-dev@ietf.org>, "xml2rfc@ietf.org" <xml2rfc@ietf.org>, "rfc-markdown@ietf.org" <rfc-markdown@ietf.org>
Thread-Topic: [xml2rfc] [Rfc-markdown] [xml2rfc-dev] <br> is back, was: New xml2rfc release: v2.32.0
Thread-Index: AQHVeuYThB0olIDTkESgZHm19MAO+KdK9s8A
Date: Fri, 04 Oct 2019 20:57:16 +0000
Message-ID: <5AF324E8-4A08-4AD0-AD18-A0719A4F39A8@att.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> <B15F7AF0-F5A0-401A-9F6E-F7E0E466B6A7@amsl.com>
In-Reply-To: <B15F7AF0-F5A0-401A-9F6E-F7E0E466B6A7@amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.210.249.225]
Content-Type: text/plain; charset="utf-8"
Content-ID: <AC9C58DD4C454646AD7ED2C58DB3E951@LOCAL>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-04_12:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=332 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910040172
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/34pD5X2IqaAGrIgZj3EIE3SnEkk>
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 20:57:31 -0000

On 10/4/19, 3:01 PM, "Sandy Ginoza" <sginoza@amsl.com> wrote:

    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.
     . . .
 
On 10/4/19, 3:42 PM, "Sandy Ginoza" <sginoza@amsl.com> wrote:
    Just an additional point on this one.  Henrik has already suggested differently handling — looks like we haven’t implemented yet.  This one is included to show where a <br> could have been useful instead of looking for creative ways to workaround not having it.  
    . . .


Thank you, Sandy.

I think these examples are very creative and horrendous at the same time. What should be a simple thing instead has become a time sink figuring out workarounds. IMO, that is NOT the best use of the RFP's time.

If the RPC sees a continued need for this capability, I think it should be made easy.

	Tony

v2.23.0 | Report a Bug | By Email