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

[Toerless Eckert <[e-mail]>]

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, [e-mail], Taughannock Networks, Trumansburg NY
> > >> Please consider the environment before reading this e-mail. https://jl.ly
> > >>
> > >> ___________________________________________________________
> > >> Tools-discuss mailing list - [e-mail]
> > >> This list is for discussion, not for action requests or bug reports.
> > >> * Report datatracker and mailarchive bugs to: [e-mail]
> > >> * Report tools.ietf.org bugs to: [e-mail]
> > >> * Report all other bugs or issues to: [e-mail]
> > >> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
> > >
> >
> > ___________________________________________________________
> > Tools-discuss mailing list - [e-mail]
> > This list is for discussion, not for action requests or bug reports.
> > * Report datatracker and mailarchive bugs to: [e-mail]
> > * Report tools.ietf.org bugs to: [e-mail]
> > * Report all other bugs or issues to: [e-mail]
> > 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

-- 
---
[e-mail]