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

Miek Gieben <> Mon, 26 August 2019 14:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98060120113 for <>; Mon, 26 Aug 2019 07:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MZMulF22v1OI for <>; Mon, 26 Aug 2019 07:45:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6570B1200C5 for <>; Mon, 26 Aug 2019 07:45:25 -0700 (PDT)
Received: by with SMTP id f72so15743573wmf.5 for <>; Mon, 26 Aug 2019 07:45:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=F3E+cc9+HVvJHtlAOv647JgZhnm8Kutcbfm3cI0qvck=; b=luVbFBK8Wx6omi80sSaNjTk9fpaa5yfrhXuA6JC/2cYyYhwRj4fujDvD1t1M3Er/7b xGGB9Vkf5cGEWUGhtl3x7wyNXCmJMgOIgEFJ9m1ZD8eBjWYKJ9mjL74xzMzu2abO7TeM obS9486AEPuJ5tY6navTm24c7/Okl2dzw76EMJvDdxUGMv/cBBqR85KCGj5gF6wvLZn9 CTWNFqVqWTqbOcgrTDfLPPzc4Ut1AkrNQQsFhLpqZTURHd22fGkqgWx+Tg97xMRbz4Nc 6RQMEO/apYxmBvfEN9tKT3wxDZyV/gZm8HTHQ4e8hNiZun/EFvVeKidXARJFghpetpvV Wlpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=F3E+cc9+HVvJHtlAOv647JgZhnm8Kutcbfm3cI0qvck=; b=RshltGSW5+bMjxW+ht5I9oH7eS53hPFfX6nROuM0SpxWZF/9MpXd5a+wbFZpMY5HRz NLDvKvQSzv1FyURevJ9LCPTKGZSqaS3Ztd3Ql26QrEfZdwjpIkVoyvGKM2sDpnbCIIId oixtPf3aLaQhEFiGdrXKRSkk9zCowuUH1gnjuxpFO8rf60vgDYUBEqVHkmMem7Ouyzlh zCiBEOxZ4y8fb42ehpkGqi2KL7TUpIvuApr7rwfvbsbeyQiFreQ/p5pYMhtX/KhqsHSp kVt9qnApu9djNpot6TGtkXgGlAhVXZ5lfzO0DYNMsaL4jN8PD+YTtQyBg239HbV93uor ZoAg==
X-Gm-Message-State: APjAAAXra6QH9Qb6xheYynEp7b+bZqkZbzLRxhj1EpXs430Gyx9Jw8Gg NEf71eQvdZNP/opLeyPVx82Hmg==
X-Google-Smtp-Source: APXvYqzRxCe94gcOuD1y3LceUVy5OwIYWT/gKfy9nkibfxDhwDeqho5OciP/cIKwHTEQk3fMv9rqwg==
X-Received: by 2002:a7b:ca5a:: with SMTP id m26mr20920269wml.134.1566830723575; Mon, 26 Aug 2019 07:45:23 -0700 (PDT)
Received: from ( []) by with ESMTPSA id 74sm21999792wma.15.2019. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Aug 2019 07:45:21 -0700 (PDT)
Date: Mon, 26 Aug 2019 15:45:20 +0100
From: Miek Gieben <>
To: Julian Reschke <>
Cc: Henrik Levkowetz <>,,,
Message-ID: <>
Mail-Followup-To: Julian Reschke <>, Henrik Levkowetz <>,,,
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Rfc-markdown] bcp14, was: [xml2rfc-dev] New xml2rfc release: v2.25.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, 26 Aug 2019 14:45:28 -0000

[ Quoting <> 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
>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.