IETF Logo Mail Archive

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

Henrik Levkowetz <henrik@levkowetz.com> Mon, 26 August 2019 23:46 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 77A45120EE0; Mon, 26 Aug 2019 16:46:56 -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 2G7q2l5rPOv9; Mon, 26 Aug 2019 16:46:55 -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 5197B120811; Mon, 26 Aug 2019 16:46:55 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:61412 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 1i2OhK-000183-En; Mon, 26 Aug 2019 16:46:54 -0700
To: Dave Lawrence <tale@dd.org>, 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> <40d507f2-ed78-e09f-ae96-c64333a91547@levkowetz.com> <07f24586-9540-5170-e11c-9fca3c858b73@gmx.de> <23908.26097.125524.792528@gro.dd.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <1eff2a94-3cf1-4fcd-a0f9-b2b12230d894@levkowetz.com>
Date: Tue, 27 Aug 2019 01:46:46 +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: <23908.26097.125524.792528@gro.dd.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="qsCq5VRFIsGLk3qelLPoT77KoBh9CNNRJ"
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, tale@dd.org
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/dguJhazZ5a3Am8nPKxVefhbR_14>
Subject: Re: [Rfc-markdown] [xml2rfc-dev] bcp14, was: 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 23:46:57 -0000

Hi Dave,

On 2019-08-27 01:06, Dave Lawrence wrote:
> Julian Reschke writes:
>> If the sole reason for this change is to avoid breaking up MUST_NOT (and
>> friends), why not hard-wire that into the renderers (for HTML, I believe
>> it could be done with CSS...)?
> 
> And I readily admit I might have missed a memo, but if that is the
> sole reason then how did we arrive at the conclusion that they needed
> to be inseparable?

They don't.  There's no such rule that I know of, and I don't think there
should be one.

But if an RPC editor decides to make it so in some cases, why should xml2rfc
get in the way and issue an inappropriate warning about unrecognised keywords?

No reason to do so that I can see.  Which is why I made xml2rfc recognize
both "MUST NOT" and "MUST&nbsp;NOT" (and "MUST\tNOT", and "MUST\nNOT", and
some others) as a BCP 14 key word.


	Henrik

v2.23.0 | Report a Bug | By Email