Re: [xml2rfc] Multiple email addresses in <address/>

Carsten Bormann <cabo@tzi.org> Mon, 08 March 2021 20:25 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE523A16C2 for <xml2rfc@ietfa.amsl.com>; Mon, 8 Mar 2021 12:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GP4zskVrW3vR for <xml2rfc@ietfa.amsl.com>; Mon, 8 Mar 2021 12:25:56 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6193A3A164D for <xml2rfc@ietf.org>; Mon, 8 Mar 2021 12:25:56 -0800 (PST)
Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DvVGV2rWjz10W3; Mon, 8 Mar 2021 21:25:54 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <1f1f6eb8-c8a1-e7ac-361c-7590be6d1e6f@gmx.de>
Date: Mon, 8 Mar 2021 21:25:53 +0100
Cc: xml2rfc@ietf.org
X-Mao-Original-Outgoing-Id: 636927951.89657-d1a6c42eb41a90ef2267e3721e408991
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4EA1B3A-41E0-41A0-8863-80E9C780183E@tzi.org>
References: <CA+RyBmWJNTd3kZDswwF9iC1BB_SojseDR6Litk7msQpA94sLAQ@mail.gmail.com> <af32fd74-0eca-aa86-2078-f53f327bacfc@gmx.de> <CA+RyBmX+8ZaSsAkW590g6=3+kR3YA-x0-77kcb71+a2DrjCGSQ@mail.gmail.com> <48a9e368-6a0e-357a-75e5-9e1d3135a0b5@gmx.de> <CA+RyBmUrUJgwJ8JBTmhdomYA0aK02akvxsSH-s6KiQaRZsJ8kQ@mail.gmail.com> <9FF645F2-7982-4B6A-935A-A96167BBF887@tzi.org> <CA+RyBmWcNt2KytnUj=B=qo7-W+zycKT7Jv7qRKiUF10FcV+oUg@mail.gmail.com> <50135A5A-1322-4653-B0B5-04356ECB405C@tzi.org> <CA+RyBmXyJecr9m8PqJuTdA4bZ9PJD=F8vLxnFgm6C652KK3wFA@mail.gmail.com> <4bb32ea2-9802-3899-de6e-e0411876b89b@gmx.de> <CA+RyBmWUYdL519pb7fY9p24v-4ySeqnq8hpb9NCvpbkpbfwmiQ@mail.gmail.com> <25C8BB41-D34A-479E-8380-AE1D453F6882@gmail.com> <CA+RyBmXUcc2ORLgH4=jAf5QVNpjG9C8q5Gu+5ROAk8b-AVZ3CQ@mail.gmail.com> <1BA13676-4DD5-4A48-8C9F-EDBBD79BCD9E@tzi.org> <1f1f6eb8-c8a1-e7ac-361c-7590be6d1e6f@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/4pakNJrcsrmmdPJS3y30HMhpOcM>
Subject: Re: [xml2rfc] Multiple email addresses in <address/>
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2021 20:25:59 -0000

On 2021-03-08, at 17:20, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> Am 08.03.2021 um 16:37 schrieb Carsten Bormann:
>> On 2021-03-08, at 16:11, Greg Mirsky <gregimirsky@gmail.com> wrote:
>>> 
>>> Now it works with two <email/> lines.
>> 
>> It is somewhat suboptimal that these relaxations of the v3.rnc were not grandfathered into the v2 support.
>> ...
> 
> That's essentially true for *everything* in v3, for xml2rfc.
> 
> The original idea was that a v3 processor would accept *all* of v2
> (that's why we did *deprecate* things in the spec, not *remove* them).
> Unfortunately, the v2 and v3 modes in xml2rfc are entirely different
> code paths, and you can't easily mix new stuff with elements that were
> deprecated.

I understand that (and agree) there was a desire to preserve the v2 codepaths in xml2rfc as a safety measure.

However, the xml2rfc migration path works very well when --v3 is given to xml2rfc.
All v2 constructions (with very few bugs) are supported well by the v2v3 converter.

The problem is in the way the submission interface treats its input.

I haven’t checked the code, but it seems it does a v3 conformance check and only uses the --v3 mode if that succeeds.  But that is not the way the “v2 with some v3” documents look like.  These also should be treated with --v3, but they aren’t.

Again, running the v2 code paths from the submission interface may initially have been a prudent safety hedge, but by now it is creating more way more damage than it helps.

Grüße, Carsten