Re: [Rfc-markdown] bcp14, was: [xml2rfc-dev] New xml2rfc release: v2.25.0

Henrik Levkowetz <henrik@levkowetz.com> Mon, 26 August 2019 17:14 UTC

Return-Path: <henrik@levkowetz.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 2B4AC120AEF; Mon, 26 Aug 2019 10:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9G2SobvD-brm; Mon, 26 Aug 2019 10:14:16 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69851120AFD; Mon, 26 Aug 2019 10:14:16 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:59767 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1i2IZL-00037L-CP; Mon, 26 Aug 2019 10:14:15 -0700
To: Julian Reschke <julian.reschke@gmx.de>, xml2rfc-dev@ietf.org, xml2rfc@ietf.org, rfc-markdown@ietf.org
References: <E1i2EMD-0002SA-UW@durif.tools.ietf.org> <22880345-a324-8dfd-a08c-e8ec89aeb9b5@gmx.de> <20190826144520.GA19037@miek.nl>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <40d507f2-ed78-e09f-ae96-c64333a91547@levkowetz.com>
Date: Mon, 26 Aug 2019 19:14: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: <20190826144520.GA19037@miek.nl>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E2LeFpkgvxm4rJxC3xhT39pbxhB2ewDRI"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org, julian.reschke@gmx.de
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/jpqUAedihVgPr9g675kM0COFwdg>
Subject: Re: [Rfc-markdown] bcp14, was: [xml2rfc-dev] New xml2rfc release: v2.25.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: Mon, 26 Aug 2019 17:14:21 -0000

On 2019-08-26 16:45, Miek Gieben wrote:
> [ Quoting <julian.reschke@gmx.de> in "[Rfc-markdown] bcp14, was: [xml2rfc..." ]
>>On 26.08.2019 14:44, Henrik Levkowetz wrote:
>>>...
>>>   * Moved the check for appropriate <bcp14> content from the text renderer
>>>     to the preptool, and tweaked it to permit &nbsp;, e.g., 'MUST&nbsp;NOT'.
>>>...
>>
>>IMHO a bad idea, because now rendering preferences leak into the
>>content. It means that tools that do something meaningful with <bcp14>
>>will have to process variations of whitespace characters (just NBSP or
>>more??).
>>
>>If the desire is to consistently keep together keywords in output, it
>>might be a better idea to let the renderer do that automatically.
>>
>>Whatever the outcome is, this should be precisely described in RFC 7991bis.
> 
> I tend to agree with Julian. This mean I'm better of always outputing
> "MUST&nbsp;NOT" instead of just using a normal space.

It seems to me that the alternative to recognising "MUST&nbsp;NOT" as a
valid keyword, and not emit warnings for it, is to disallow U+00A0 (which
is equivalent to &nbsp; occurring in our XML) in this position.  To me,
that seems worse than the original problem. 

It seems to me that future tools that process our XML should be prepared
to deal with unicode whitespace generally, not only ASCII space.


	Henrik