Re: [Tools-discuss] Why post text and not XML?

[John C Klensin <[e-mail]>]

--On Saturday, March 16, 2024 16:16 -0500 Jean Mahoney
<[e-mail]> wrote:

> Hi all,
> 
> On 3/16/24 3:36 PM, Brian E Carpenter wrote:
>> John,
>> 
>> Thanks for explaining.
>> 
>> In line...
>> 
>> 
>> On 17-Mar-24 07:51, John C Klensin wrote:
>>> 
>>> 
>>> --On Saturday, March 16, 2024 17:13 +1300 Brian E Carpenter
>>> <[e-mail]> wrote:
>>> 
>>>> ...
>>>> More confusingly, there are still a few current drafts
>>>> submitted as txt only. No XML at all. I wonder why we still
>>>> allow that, and what tools people are using. 
> 
> [JM] The RPC still allows the submission of text files, but
> only 3% of the documents that entered the queue in 2023 were
> text only.

Jean, my apologies but I'm going to keep pushing on this... and
pointing out that we are moving into community policy issues
that really belong on the IETF list or someplace else designated
by the IESG, not on this list.

Anyway, that is an interesting statistic.  I believe (based on
anecdotal observations but no firm data at all) that it would
have been higher six or ten years ago.  If I am correct, would
you or something else care to guess what proportions of those
earlier authors have:

 * Converted to some mechanism that produces XML2RFC?
 * Stopped authoring documents but remained active in the IETF?
 * Been driven off, and out of the IETF entirely, by assorted
comments (on or offlist) about how they should become "modern"?
 * Dropped out for other reasons?

I suppose an additional question is whether anyone who provides
only text (or, given Brian's question below, text and HTML)
versions of an I-D but who supplies RFCXML to the RPC soon after
the document is passed to you for processing counts in that 3%
or not.  If so, the percentage of documents you have to rework
via id2xml is lower than 3%.  If not, the 3% number does not
tell us very much about the number of I-Ds that are posted only
in text form (or even in text and HTML form) before the stream
signs off on them for publication.
 
>> I certainly don't care about the XML as such; what I miss
>> is the HTML version, which is much nicer to read than either
>> the plain text or the HTMLized version. My problem statement
>> was too simple.
>> 
>> Is it possible for you to submit the .txt and the .html
>> versions?

See my prior note and above.

>>>> Doesn't this
>>>> create busywork if the document progresses?
>>> 
>>> As one of the offenders, I think I have explained this before
>>> but let me do it again.  Short answer: it is a side-effect
>>> of work that makes the document development process in WGs
>>> much more efficient in part because it makes "we have been
>>> over that before, in YYYYMM, and reached those conclusions
>>> because..." input much easier and more accessible.  It also
>>> helps in preparation of accurate final change summaries and
>>> acknowledgment easier and more accurate.  The "tools" are an
>>> emacs-clone editor with an XML mode and a handful of personal
>>> macros and templates.   The only "busywork" is stripping
>>> that stuff out just before the XML is handed to the RPC.
>> 
>> Good. I was concerned about the RPC having to synthesize the
>> XML from a plain text submission.
> 
> [JM] The RPC uses id2xml to covert text documents to RFCXML
> v3, but it is a time-consuming process to get those documents
> into good shape. The id2xml conversion step only gets a text
> document part of the way there.

So then we get to a different policy question.  That is whether
it is worth having the RPC to do that work in order to
accommodate the fraction of the community who, regardless of the
details of their habits or reasons, are inclined to use other
tools and preparation methods for I-Ds.   The alternative, which
I have not seen anyone propose, is whether, to reduce those
costs, the community is willing to make those potential
participants and the perspectives they might represent unwelcome
and possibly to drive those perspectives out of the community's
considerations and decision-making mechanisms.   And whether, by
adopting and requiring a set of tools that are, at least in the
details, unique to the IETF, we would do a better job of pushing
newcomers and those who are not part of "the club" away than any
Guides, education, or outreach programs could overcome.

So let's be careful about superficial statistics, ok?

best,
   john