Re: [Tools-discuss] Sup to nuts

Carsten Bormann <> Wed, 07 July 2021 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE8F03A1F02 for <>; Wed, 7 Jul 2021 09:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id da-q_0QHgLwQ for <>; Wed, 7 Jul 2021 09:59:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5581B3A1EFE for <>; Wed, 7 Jul 2021 09:59:28 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4GKlyK4FpRz2xFw; Wed, 7 Jul 2021 18:59:21 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Wed, 7 Jul 2021 18:59:21 +0200
Cc: tools-discuss <>
X-Mao-Original-Outgoing-Id: 647369961.043116-79d70975f1e0873b0f21e85d2f629107
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Yaron Sheffer <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Tools-discuss] Sup to nuts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Jul 2021 16:59:33 -0000

On 2021-07-07, at 18:14, Yaron Sheffer <> wrote:
> Hi,
> I’ve been using the “sup” XML element (superscript). It goes well through the Markdown tooling, and through xml2rfc v3.4.0 (with –v3). But then it bombs when I submit the I-D. Is this just a version difference, or should I somehow set xml2rfc to be more strict?
> FWIW, this message “Element sup is not declared in t list of possible children” appears to contradict RFC 7991.

Hi Yaron,

you are submitting something that the nostalgic software at the submission point believes to be a pure v2 document, and this it enforces historic purity.

In order to persuade this software that it’s 2021, you need to convert it to pristine v3 first.

You can do that with

kdrfc -3c

or, if you prefer to work from the xml output, by 

kdrfc -3c foo.xml
xml2rfc --v2v3 foo.xml

In all of these cases, you get a foo.v2v3.xml that can be submitted without invoking v2 nostalgia in the submission software.

Grüße, Carsten

(Yes, I know that the submission service will be fixed very soon.)