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]
