>> For RFC5661 and documents derived from it using Adam’s procedure, that ship has already sailed :-(.
> As the references section needs to be updated anyway (for the DOIs), I’m not sure this is really true. Or, if it is,
.> > > Since RFC 5661, we also got DOIs on RFCs, so it is inevitable there are a lot of diffs.
>>
>> It is not inevitable as shown by the fact that I didn't run into that issue. It's kind of nice to know that there was an issue out there that I didn't run into :-)
>>
>> For reasons I really don't understand, the xml for rfc5661 does not include rfc reference from external libraries. It includes them inline, so a new rfc derived from that xml file will not include DOIs.
> Yes. All these RFC references would be updated by the RFC editor into current references.
> As the references section needs to be updated anyway (for the DOIs), I’m not sure this is really true. Or, if it is,
> RFC 5661 maybe isn’t really a candidate for this process, because it may be impractical to re-generate the exact
> numbering that RFC 5661 used.
I had been assuming that you could turn off sortrefs and construct a reference section in the exact order that the
I had been assuming that you could turn off sortrefs and construct a reference section in the exact order that the
v1 tool. I'll try some experientsto validate that approach.
.> > > Since RFC 5661, we also got DOIs on RFCs, so it is inevitable there are a lot of diffs.
>>
>> It is not inevitable as shown by the fact that I didn't run into that issue. It's kind of nice to know that there was an issue out there that I didn't run into :-)
>>
>> For reasons I really don't understand, the xml for rfc5661 does not include rfc reference from external libraries. It includes them inline, so a new rfc derived from that xml file will not include DOIs.
> Yes. All these RFC references would be updated by the RFC editor into current references.
That's not a problem for Adam's procedure :-). The RFC candidate considred by the IESG would still match
rfc5661. Then, during RFC editing, the reference section could be revised to include the DOI's.
>> That is not a problem for Adam's procedure, but it may be for the IESG or the RFC editor. I hope that, in processing RFC’s using Adam's procedure, people will overlook the lack of DOIs in the same way that they overlook other aspects of the document that would prevent a new document of that form from being published.
>AFAICT, they can’t, as the RFC editor has committed to providing DOIs.
>> That is not a problem for Adam's procedure, but it may be for the IESG or the RFC editor. I hope that, in processing RFC’s using Adam's procedure, people will overlook the lack of DOIs in the same way that they overlook other aspects of the document that would prevent a new document of that form from being published.
>AFAICT, they can’t, as the RFC editor has committed to providing DOIs.
Please see above:
- The IESG doesn't have to deal with the DOI diffs, since it won't see them.
- The RFC editor would create DOI diffs but not be bound by Adam's procedure in doing so.
Where this might be a problem is in document where the existing xml uses external reference libraries. That avoids the need for the RFC to do anything to provide the DOI's other that updating the libraries. However the IESG will see the diffs resulting from the inclusion of DOI's so I would hope that Adam's document is clear thar they should not be considered "spurous".
On Sun, May 12, 2019 at 12:57 PM Carsten Bormann <cabo@xxxxxxx> wrote:
Hi Julian,
> FWIW, I disagree (but I realize that I'm probably in a minority). The
> problem with Markdown is that the simple things are easy, but everything
> else gets messy. I'm looking forward to see how you kram (pun intended)
> the V3 features into your tool…
Do I have to?
If an author wants to use a V3 feature that does not lend itself to authoring in markdown, they can always put the XML tags right into their markdown source.
>>>> but that was the way things were done in 2010.
>>>
>>> I’m prepared to stick with that, unless there is something better about the alternatives.
>>
>> Right, for a minor update, digging out the v1 tools and finding a platform where they can still run may actually be the best way to proceed.
>
> All you need is a TCL processor. Works fine over here on a newly
> installed notebook with Windows 10 and Cygwin.
Haven’t tried that in a while…
Works for me, too (macOS 10.13.6, on a small document, with the usual formatting differences from v2…).
Good to know.
(Although I have heard people have had problems on other platforms recently..)
Grüße, Carsten
