Re: [Tools-discuss] .txt? [I-D Action: draft-xxx.txt]

Toerless Eckert <tte@cs.fau.de> Tue, 29 June 2021 16:31 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC803A39E4 for <tools-discuss@ietfa.amsl.com>; Tue, 29 Jun 2021 09:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 k2q-5T417ajH for <tools-discuss@ietfa.amsl.com>; Tue, 29 Jun 2021 09:31:41 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8AAC3A39E3 for <tools-discuss@ietf.org>; Tue, 29 Jun 2021 09:31:41 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 78A6654806E; Tue, 29 Jun 2021 18:31:33 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6FEFB4E78D6; Tue, 29 Jun 2021 18:31:33 +0200 (CEST)
Date: Tue, 29 Jun 2021 18:31:33 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Warren Kumari <warren@kumari.net>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, John R Levine <johnl@taugh.com>, Tools Discussion <tools-discuss@ietf.org>
Message-ID: <20210629163133.GP5057@faui48e.informatik.uni-erlangen.de>
References: <20210627013258.1D30F188447C@ary.qy> <691b91b6-86d7-2a3d-b9dc-8c19cc507db4@gmail.com> <584d34d6-5630-bbb7-35cc-9459dabc80f0@taugh.com> <82887902-90d0-3616-656b-fc39e4febd47@gmail.com> <70fee53d-28b9-874a-6988-6c1234ca149@taugh.com> <20210628193815.GL5057@faui48e.informatik.uni-erlangen.de> <ffd86c27-82a0-8c92-d270-ab1c770acb99@gmail.com> <CAHw9_iKTh6JBpgVnVh-c4YT1hvg1S7s12xo1dcz7AJ4XCG_ywg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHw9_iKTh6JBpgVnVh-c4YT1hvg1S7s12xo1dcz7AJ4XCG_ywg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/6zL6dH9XAsyxTCorC3D3iR9STUQ>
Subject: Re: [Tools-discuss] .txt? [I-D Action: draft-xxx.txt]
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2021 16:31:47 -0000

On Tue, Jun 29, 2021 at 09:54:24AM -0400, Warren Kumari wrote:
> > 3. SVG. Hard work to use, but well worth it.
> 
> Again, see #1. I believe that requiring that complex things be
> explainable using ASCII art was a feature - if your protocol is
> sufficiently complex that it cannot be easily explained using words
> and ascii art, it's probably too complex.

I looked at the RFCs with SVG given as examples on the URL earlier here
in this thread. Unfortunately, these all had only SVG that where not
a bit more useful than their ASCII renderings. so no points scored for SVG
in the v3 marketing materials.

I am not sure what you call "protocol", , but there is certainly more in
RFCs than just what would fit ASCII art:

Think of all the draft/RFCs in IRTF that want to have actual
measurement diagrams like research papers have them. Try to render those
in ASCII. Or graphics showing some forwarding plane / chip architecture,
or real-world topologies of large networks of interest.

If i could just figure out the workflow to take some existing bitmap
and abuse SVG to include it into a draft. Still not sure if that
(bitmap in SVG) is even allowed by the XMLv3 laws

> > 4. Using tools that are currently maintained.
> 
> Tools like the XML2RFC XMLMind plugin were working just fine with the
> V2 format; every few years I'd release a new version when XMLMind
> updated their major version, but it was literally just a version bump.
> Same thing for my "copy the last RFC, change the title and words". #4
> sounds very much like "people weren't keeping the tools maintained the
> way we liked, so we made a breaking change to force them to abandon
> what they were doing, and use what we think is better.

Did v2 and does v3 have incremental enhancements ? If the language(s)
are themselves fixed, then tool maintenance would only be necessary
if other conditions change, like in your case XMLMind. If one builds a
standalone tool, maintenance might not even be necessary.

Cheers
    Toerless

> Anyway, I realize that this ship has sailed, and I'm doing a good
> impression of "Old Man Yells at Cloud"... but someone asked why more
> stuff wasn't being submitted in v3 format, and this is at least one
> set of reasons why...
> 
> W
> 
> >
> > I've had no trouble at all editing XML in v3. The only real
> > annoyance is that the converter can't do anything sensible with
> > <vspace blankLines="1"/> which I used to use a lot. Everything
> > else is trivial.
> >
> > (The converter insists on inserting lots of format="default"
> > and toc="default" which are just noise and can be deleted.)
> >
> > Regards
> >    Brian
> >
> > On 29-Jun-21 07:38, Toerless Eckert wrote:
> > > I only converted the last rfc i was editor for during the final revisions to go to rfc,
> > > and i only did this so i could use the only one new feature of v3 that i felt i wanted
> > > to use, name the Contributors tag. I still don't know what else i as an author
> > > would benefit from in v3.
> > >
> > > I did find the conversion sufficient for that last mile to RFC editor, but not persuasive to
> > > suggest it to authors if/when they want to continue doing mayor edits to the document. This
> > > is primarily beceause the v3 ended up with a tag-verbose XMLv3 than the v2 i had
> > > edited for years. This specifically included inlining the rfc/draft references as opposed
> > > to keeping the references, but also several other tags that where written out more verbosely
> > > and with a lot of default parameters (unnecessarily).  Hope i remember this all correctly.
> > >
> > > This v2->v3 conversion process feels a bit like attempting to have a good idea but then
> > > outsource the conversion cost.  Reminds me of linux. Great new SDK/Library, but now all
> > > the third-party apps developed against an older version have to be rewritten. In comparison,
> > > in Windows i can have 10 versions of the same core SDK co-installed and all the old but
> > > still useful programs will still run. But no linux distributions do not support such slotting
> > > or do not compile all old library versions, and library developers don't care about supporting
> > > multi-slotting... *sigh*
> > >
> > > Chers
> > >     Toerless
> > >
> > > On Sat, Jun 26, 2021 at 10:40:40PM -0400, John R Levine wrote:
> > >>>> Among the many things on the to-do list is to redo the I-D submission page
> > >>>> to make it clearer that you only need to submit one version of a draft,
> > >>>> and that we'd appreciate the XML version if you have one.
> > >>>
> > >>> Excellent. Is there any reason not to run the v2 to v3 converter automatically?
> > >>
> > >> We really want people to stop using v2.  It's obsolete and missing some
> > >> semantic features of v3.
> > >>
> > >> Regards,
> > >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> > >> Please consider the environment before reading this e-mail. https://jl.ly
> > >>
> > >> ___________________________________________________________
> > >> Tools-discuss mailing list - Tools-discuss@ietf.org
> > >> This list is for discussion, not for action requests or bug reports.
> > >> * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
> > >> * Report tools.ietf.org bugs to: webmaster@tools.ietf.org
> > >> * Report all other bugs or issues to: ietf-action@ietf.org
> > >> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
> > >
> >
> > ___________________________________________________________
> > Tools-discuss mailing list - Tools-discuss@ietf.org
> > This list is for discussion, not for action requests or bug reports.
> > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
> > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org
> > * Report all other bugs or issues to: ietf-action@ietf.org
> > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> 
> 
> -- 
> The computing scientist’s main challenge is not to get confused by the
> complexities of his own making.
>   -- E. W. Dijkstra

-- 
---
tte@cs.fau.de