Re: [xml2rfc-dev] [Ext] <author> below <section>

Paul Hoffman <paul.hoffman@icann.org> Wed, 27 November 2019 21:18 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15ED5120AAD for <xml2rfc-dev@ietfa.amsl.com>; Wed, 27 Nov 2019 13:18:04 -0800 (PST)
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 4MUPzwocoZuK for <xml2rfc-dev@ietfa.amsl.com>; Wed, 27 Nov 2019 13:18:02 -0800 (PST)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 C0DAF120088 for <xml2rfc-dev@ietf.org>; Wed, 27 Nov 2019 13:18:02 -0800 (PST)
Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa3.lax.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id xARLI23J008627 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <xml2rfc-dev@ietf.org>; Wed, 27 Nov 2019 21:18:02 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 Nov 2019 13:18:00 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.000; Wed, 27 Nov 2019 13:18:00 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: XML Developer List <xml2rfc-dev@ietf.org>
Thread-Topic: [Ext] [xml2rfc-dev] <author> below <section>
Thread-Index: AQHVpV0N0HhhpanfZUSN7vS5Awe7GaegC6uA
Date: Wed, 27 Nov 2019 21:17:59 +0000
Message-ID: <8D4AAAB9-DEE3-41CB-9629-8B88F868F42C@icann.org>
References: <42165850-8c17-49c0-c98a-7829936c848f@gmx.de>
In-Reply-To: <42165850-8c17-49c0-c98a-7829936c848f@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_28AC6407-2DC3-4C75-9934-BE81C0556FCA"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-27_04:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/5n5FAjzHINQpTn3VZ-6ji7QsRck>
Subject: Re: [xml2rfc-dev] [Ext] <author> below <section>
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2019 21:18:04 -0000

On Nov 27, 2019, at 11:52 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> Hi there,
> 
> So I was looking at <https://www.rfc-editor.org/rfc/rfc8673.xml>, and,
> to my huge surprise, found <author> elements below <section>, apparently
> generated by the preptool step.
> 
> I checked, and this doesn't seem to be documented anywhere (not even
> Henrik's implementation notes), but yet it turns up in "canonical XML".
> 
> Just to clarify - there are two issues here:
> 
> 1) The technical issue: adding author information a second time in the
> canonical XML does not make any sense to me.

Nor to me. 

> 2) The process issue: this isn't documented anywhere, but yet appears in
> the so-called "canonical XML".

In fact, this usage is fully prohibited in draft-iab-rfc7991bis. <author> is only allowed as part of <front>.

It is also contra-indicated in the prose:
   The <author> elements contained within the document's <front> element
   are used to fill the boilerplate and also to generate the "Author's
   Address" section (see [RFC7322]).

--Paul Hoffman