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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 29 June 2021 22:36 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 30F223A157A for <tools-discuss@ietfa.amsl.com>; Tue, 29 Jun 2021 15:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level:
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 v_HKBugbZdVW for <tools-discuss@ietfa.amsl.com>; Tue, 29 Jun 2021 15:36:15 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385783A1579 for <tools-discuss@ietf.org>; Tue, 29 Jun 2021 15:36:15 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id z4so354296plg.8 for <tools-discuss@ietf.org>; Tue, 29 Jun 2021 15:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=I5Ie7iJlTG3mIPrKlCUca5faPn/PWYTQv6FVd9TAmOk=; b=OCMVCNBrgKTRo6WNZ4I6G6fQMDxKXiQbhOqrbuL8qMCpEnUNAJDCR5q1imar9EwO+J uFnW+F3wIEaFndr4G4v03AoubuTlez1IIVS0r+p+AaIjyiLbt48RGg19be1cj4O0Nd+l TBT4FieQCrgs5RS7XdhG8M19FN9lnJk6NY3BwKVxjkNQ7+Q08XBzA05B6LagsZZAl/N/ rtzp7rUXI0h4GsuhWLlM4Vt0PuZLpxzjMCXMXdyLXxd4xhkkQIqIIW9JEu1L+gBNdArt D3hSRKJsJk27ZTycHxLMGVoqABEP3BXpntk2FFqR5P7aHElpRbIIh/3H++s1Ut+RyPVB WkEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=I5Ie7iJlTG3mIPrKlCUca5faPn/PWYTQv6FVd9TAmOk=; b=bkwQIa9D1QpyhP4uZl0oprwoH7O7dLaaxpF0fqEbdxoYgLst1JNeutUc/tx6Sxo0mB 6SF+XzW+80qh/bCaPlKNcbD+RpVXqWE3cxb0tSedhC1NTdwXrmTLJU6rgL33OS/rB+Wf Iycmbe6vcvmeM3X/TqKi4hEC5Pct44i+ncFGsq0Dnh8ADsX/kSFW1KjuH5X/Yy4/wUtb UyYxEUM7yBIf7x7LhAfQTK8SiKc8TVuCK3ZmSp8ZEXbvkbod772fNH15ZJK3h2gpKqBP 1+RW9S2gimG4ZJTFMYBvq64KooJhH+MmTJcmTYGVtrbYE0ze/7RHVudJX7dB12k7yMcN 7LYA==
X-Gm-Message-State: AOAM5300ubziPjrBbESxFrt1a2kArbYUTJ3FS+DbyQU9nFC2BSar4nei w1RBlZQw75OukbvDiMAxGusqUs0FB9jKPg==
X-Google-Smtp-Source: ABdhPJw35NhL/CsBwgg/QOlvlzhDjP1QiKEKMuWXSWPyVA3YXxPfblZHDN5YRheJVXxeDES/+13EwQ==
X-Received: by 2002:a17:90b:f91:: with SMTP id ft17mr1092374pjb.97.1625006173774; Tue, 29 Jun 2021 15:36:13 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id w8sm20952975pgf.81.2021.06.29.15.36.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 15:36:13 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>
Cc: Warren Kumari <warren@kumari.net>, John R Levine <johnl@taugh.com>, Tools Discussion <tools-discuss@ietf.org>
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> <20210629163133.GP5057@faui48e.informatik.uni-erlangen.de> <80b85906-b524-9793-f05d-fdfcf51eade9@gmail.com> <20210629214541.GU5057@faui48e.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <c6178486-f08b-7af3-8e8d-d04a9f8b40c6@gmail.com>
Date: Wed, 30 Jun 2021 10:36:09 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <20210629214541.GU5057@faui48e.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/i52d5AxJp8J9-F8p8DiLl4K4e7k>
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 22:36:20 -0000

On 30-Jun-21 09:45, Toerless Eckert wrote:
> On Wed, Jun 30, 2021 at 09:34:52AM +1200, Brian E Carpenter wrote:
>>> 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
>>
>> Well, see the two attached files. The first one is png produced by gnuplot. The second one is SVG produced by gnuplot, and then run through my SVG color fixer followed by the IETF's SVG checker.
> 
> Thanks for the effort, but:
> 
> I don't know how to use he tool-chains to use SVG (outside of drafts or 
for drafts)
> Is there an easy to rmember URL where to find such instructions to start using SVG ?

I suspect not. Maybe we need to crowd-source that somehow.
 
>> Since gnuplot is the de facto standard for producing plots in academic 
articles, I think we are fine.
> 
> Ok, thats great, but that still leaves all those hand-drawn diagrams of 
architecures,
> designs, topologies, concepts or the like, whee i for example have accustomed to
> use powerpoint and am most productive with. Is there a tool-chain to convert such
> powerpoint output to SVG ?

I tried quite hard to convert diagrams that work with LibreOffice to SVG, 
using LibreOffice's export mechanism. The results were hopeless, mainly due to LibreOffice
producing enormous complexity (including built-in scripts, a complete no-no for
our Tiny SVG dialect) for very simple diagrams. I have no access to Microsoft Office, so I don't know if that is any better. Use a simple tool like dia and things work out better.

You can convert a sketch from (say) PNG to SVG at https://convertio.co/png-svg/ but the results are mediocre. As John pointed out, the V means Vector, so going through a bitmap format will never be satisfactory.

  Brian
 
> Cheers
>     toerless
> 
>>     Brian
>>
>>>
>>>>> 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
>>>
> 
> 
> 
>