Re: [Rfc-markdown] Carsten: Re: [rfc-i] summary of Removing postal information from RFCs

[Carsten Bormann <[e-mail]>]

On 2021-07-20, at 15:28, Michael Richardson <[e-mail]> wrote:
> 
> 
> Carsten Bormann <[e-mail]> wrote:
>>> So, what is the relationship kramdown-rfc2629 to this ?
>>> 
>>> - Can the kramdown create xmlv3 output ?
> 
>> Yes, via the --v2v3 process in xml2rfc.
> 
> Do you think that you'll change to producing pure v3 output at some point?

Yes.

But since most processing of RFCXML involves xml2rfc already, and that already has a (by definition) perfect v3 generator, this doesn’t have very high priority.
Any mistake I make there in kramdown-rfc leads to a show-stopper for an author, and that is exactly what kramdown-rfc is trying never to create.

> I understand that might be awhile, or that -3 might become the default before
> that point.

Right.  Again, there is very little reason to invalidate existing Makefiles etc., so changing defaults pretty much means making a renamed copy of a wrap-around processor like kdrfc.
That is actually likely to happen quite soon.

(-3 is already default in, and the only way to run, kdwatch [1].)

> I'm just asking about processing plans.

I think progress here will be pretty much issue-driven; if an author finds an inconvenience in the current setup, that is more likely to be addressed than some abstract notion of compliance.
(The main driver is actually AUTH48 processing, as the RPC operates on the converted v3 XML, so making diffs is harder for the authors when there are still pieces of v2 packaging around.  But making that process less impenetrable for authors is currently frustrated in more ways, so that is a larger project.  The other driver is missing features, mainly tables at this point.)

>> With the --v3 (-3) flag, kramdown-rfc2629 produces XML that xml2rfc can
>> process, and that --v2v3 can turn into the current version of v3.
>> This XML is no longer v2 compliant, as it uses the new features of v3.
> 
> So it's some kind of v2 / v3 mutt :-)

It is pretty much one of the two authoring interfaces provided by xml2rfc to v3; it is just weird that the I-D submission interface is in denial about that.

Grüße, Carsten

[1]: https://github.com/cabo/kdwatch