Hi Carsten, Just a friendly reminder that we await a self-contained markdown file that parses with the most current version of kramdown-rfc.
Thank you, Sarah Tarrant RFC Production Center > On Nov 24, 2025, at 12:38 PM, Sarah Tarrant <[email protected]> > wrote: > > Hi Carsten, > > Thank you for making the updates and providing a self-contained markdown file. > > It appears that we are unable to generate the RFCXML from the markdown file. > We haven't been able to identify the reason, but perhaps you are running a > not-yet-deployed version of kramdown-rfc? > > Could you provide a self-contained markdown file that parses with the most > current version of kramdown-rfc? > > Thank you, > Sarah Tarrant > RFC Production Center > >> On Nov 21, 2025, at 4:02 PM, Carsten Bormann <[email protected]> wrote: >> >> Hi Sarah, >> >> I have submitted a -30 with the two changes mentioned. >> (You cannot see the fix of the sourcecode type in the plaintext rendition, >> so you will only see the address change in a plaintext diff.) >> >>> On 2025-11-21, at 16:54, Sarah Tarrant <[email protected]> >>> wrote: >>> >>> Hi Carsten, >>> >>> Thank you for your reply! And I'm sorry to hear about the fever :( >>> >>> I have some followup questions/comments: >>> >>> a) Regarding: >>>>> * If you need/want to make updates to your document, we encourage you to >>>>> make those >>>>> changes and resubmit to the Datatracker. This allows for the easy >>>>> creation of diffs, >>>>> which facilitates review by interested parties (e.g., authors, ADs, doc >>>>> shepherds). >>>> >>>> We have submitted a -29 in response to the IANA registrations, which >>>> needed a task done (integrate newest URI-Scheme registrations) as well as >>>> follow a new clarification in RFC 9876 for content-format registrations. >>>> The IANA work now seems to be complete. >>>> >>>> We could roll up the changes (author’s address, fixing “coap-diag") >>>> mentioned below in a -30, if that helps. >>>> >>>> We will write a separate response on the validation of the sourcecode >>>> elements; if there are any surprise changes they probably can be >>>> independently integrated. >>> >>> >>> Yes, please incorporate these into that version -30. That way it's clear >>> where the change originated. >> >> There was no change necessary after validating the examples, so they are >> unchanged (with the sourcecode type fix) in -30. >> >>> b) Regarding: >>>>> * Are the Authors' Addresses, Contributors, and Acknowledgments >>>>> sections current? >>>> >>>> The author’s address for Henk Birkholz needs this change: >>>> >>>> OLD: >>>> [email protected] >>>> NEW: >>>> [email protected] >>>> >>>> Sorry for missing this in -29. >>> >>> >>> Could you add this to version -30? >> >> Done. >> >>> c) Regarding: >>>>> * Is the sourcecode type indicated in the XML? (See information about >>>>> sourcecode types.) >>>> >>>> Yes, with one mistake >>>> >>>> OLD: >>>> ~~~ coap-diag >>>> NEW: >>>> ~~~ cbor-diag >>>> >>>> There is no sourcecode-type coap-diag >>>> (Amazingly, this mistake lingered for some four years.) >>> >>> >>> Good catch! Could you also add this to the version -30? >> >> Done. >> >>> d) Regarding: >>>>> The RPC cannot update SVG diagrams, so please ensure that: >>>>> >>>>> * the SVG figures match the ASCII art used in the text output, and >>>>> * the figures fit on the pages of the PDF output. >>>> >>>> Which PDF output? >>> >>> >>> If you made a PDF, you could see if there were a difference. Feel free to >>> disregard at this time, but this might be an additional question in AUTH48 >>> if we notice differences in the PDF / TXT / HTML outputs (e.g., asterisks >>> appearing as large black circles that obscure the diagram). >> >> Right. So I made a PDF and skimmed it. >> As I mentioned, the height attributes of the SVG in Figure 1 may need some >> tweaking. >> >> (I think doing the intake based on datatracker-generated PDFs or the lack of >> such is going to be a recurring problem; it would be better to have a >> RFC-style PDF available at the time of intake. >> With the awareness of everyone, not a problem here.) >> >>> e) Regarding: >>>>> If so, please let us know and provide a self-contained kramdown-rfc file. >>>> >>>> You can extract the markdown source (with the includes performed) from a >>>> RFCXML directly submitted as such in the following way: >>>> >>>> kramdown-rfc-extract-markdown draft-ietf-core-href-29.xml > >>>> draft-ietf-core-href-29.md >>>> >>>> I have attached a markdown file extracted this way. >>>> (This is different from the markdown file in the WG repository [1] because >>>> that does not have the includes performed, so additional files are needed >>>> to compose a complete input.) >>>> >>>> [1]: https://github.com/core-wg/href >>> >>> >>> Unfortunately, we do need a self-contained markdown file with the >>> additional files included. But since there appears to be a need for a >>> version -30, please send the -30 markdown instead. So no need for a -29 >>> markdown. >> >> Self-contained markdown with all files included for -30 is attached. >> >>> f) Regarding: >>>>> 12) Would you like to participate in the RPC Pilot Test for completing >>>>> AUTH48 in >>>>> GitHub? If so, please let us know. For more information about this >>>>> experiment, >>>>> see: >>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test. >>>> >>>> I wonder how this combines with 11, but using individual, separate pull >>>> requests would very much fit our style of working. >>> >>> Yes! We're hoping to build a process that fits authors' working styles! >> >> Looking forward to it! >> >> Grüße, Carsten >> >>> Just for clarity, I'm going to leave this draft in AUTh state until I get >>> notification about the version -30 and subsequently get AD approval. >>> >>> Thank you, >>> Sarah Tarrant >>> RFC Production Center >>> […] >> >> <draft-ietf-core-href-30.md> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
