Hi Christian, I think I identified a few issues with the markdown that might help with idnits. If it doesn't, let the record show that I only hoped it would.
Let me know if I can further assist. Sincerely, Sarah Tarrant RFC Production Center > On Jun 15, 2026, at 2:03 PM, Christian Bormann <[email protected]> wrote: > > Hi Sarah, > > We have a few code blocks that don’t really fit any of those “normal” types > since they are representations meant mainly for better understanding and not > “normal” encodings. I’ve chosen the normal/fitting identifiers for everything > that fits (cddl, asn.1, json, etc.) and type identifiers that roughly fit for > the few weird ones (like the jwt header + payload example), but happy to > adjust if anyone has better ideas for those. > > I’ve removed all includes and moved the examples into the core markdown file. > PR is currently here: > https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/357 , but I am > getting some weird nits like wrong indentation in the sections if I run the > generated txt through idnits which don’t really seem to make sense to me. > Could I kindly ask you to take a look at the file in that branch > (https://raw.githubusercontent.com/oauth-wg/draft-ietf-oauth-status-list/refs/heads/editorial-fixes-kramdown/draft-ietf-oauth-status-list.md) > and comment if that looks good to you/your tooling? > > Best Regards, > Christian > >> On 15. Jun 2026, at 15:16, Sarah Tarrant <[email protected]> >> wrote: >> >> Hi Christian, >> >> Very good! >> >> For the code blocks, if you need a type, check out our list here: >> https://rpc-wiki.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types. Also, >> anything on IANA's media types list is also acceptable: >> https://www.iana.org/assignments/media-types/media-types.xhtml. >> >> As for the TBDs, please hold off on adding those. We can add those later. >> >> I'll be on the lookout for a new version and a new markdown file! >> >> Thank you, >> Sarah Tarrant >> RFC Production Center >> >>> On Jun 15, 2026, at 7:08 AM, Christian Bormann <[email protected]> wrote: >>> >>> Hi Sarah, >>> >>> I am working on a PR that addresses these points - here are a few comments: >>> >>> B) I believe those are the inline code blocks - I didn’t associate those >>> with your question, sorry! Those are intentional to signal >>> parameters/claims in the text - basically every time a concrete parameter >>> etc. is referenced. >>> >>> C) Sorry, I only thought about source code, not code blocks with JSON/CBOR >>> etc. We have quite a few code blocks that aren’t any of the “normal" formal >>> types - for example annotated cbor or JWT in <header>.<payload> annotation. >>> We weren’t really sure what code-block type to use for those, so we left it >>> empty, but I found custom types in other RFCs that I will re-use. >>> >>> D) I’ll move all examples into the core markdown file and remove the >>> includes. >>> >>> We should be able to publish a new version with those changes this week. >>> Since we also got a mail regarding the pending IANA registrations (that we >>> will answer in a few days) and had a few “TBD”s in the text, should I also >>> update these TBDs to the numbers that were created by IANA now? >>> >>> Best regards, >>> Christian >>> >>>> On 11. Jun 2026, at 16:25, Sarah Tarrant <[email protected]> >>>> wrote: >>>> >>>> Hi Christian, Paul, and Tobias, >>>> >>>> Thank you for your reply! I do have some followup questions/comments: >>>> >>>> A) Regarding 3), yes, please! If you want to fix up those lists, please >>>> submit a new version to the datatracker. Once you do that, be sure to send >>>> me the updated self-contained markdown file as well. >>>> >>>> B) Regarding 5), please take another look at the submitted XML file as I >>>> found <tt> throughout (e.g., bits, StatusList, lst, aggregation_ur, typ, >>>> etc.). If this was done unintentionally, please submit a corrected version >>>> that aligns with your intentions. However, if this was intentional, please >>>> let us know what patten you followed so that we can help keep the usage >>>> consistent in the document. >>>> >>>> C) Regarding 6), I'm seeing sourcecode elements in the XML, particularly >>>> json, cddl, and (possibly) asn.1. This can get blurred between the >>>> markdown and the xml files, as markdown doesn't always have a "type" >>>> selected. If it is helpful to think of these elements as "formal >>>> language", see: https://authors.ietf.org/formal-languages. We just want to >>>> verify that what is in the submitted XML is correct and intentional, so >>>> please let us know that. >>>> >>>> D) Regarding 7), I'm not able to parse the markdown file at: >>>> https://github.com/oauth-wg/draft-ietf-oauth-status-list/blob/main/draft-ietf-oauth-status-list.md?plain=1. >>>> It looks like a couple {::include elements were used; so, if you would >>>> like to proceed with markdown, we would need a self-contained file. >>>> >>>> Sincerely, >>>> Sarah Tarrant >>>> RFC Production Center >>>> >>>>> On Jun 11, 2026, at 2:07 AM, Christian Bormann >>>>> <[email protected]> wrote: >>>>> >>>>> Dear RPC team, >>>>> >>>>> Thanks, below are the answers to the questions: >>>>> >>>>>> 1) As there may have been multiple updates made to the document during >>>>>> Last Call, >>>>>> please review the current version of the document: >>>>>> >>>>>> * Is the text in the Abstract still accurate? >>>>>> * Are the Authors' Addresses, Contributors, and Acknowledgments >>>>>> sections current? >>>>> >>>>> Abstract is still accurate and Author’s names & email addresses are >>>>> current. >>>>> Acknowledgements should be current as well. >>>>> >>>>>> 2) Please share any style information that could help us with editing >>>>>> your >>>>>> document. For example: >>>>>> >>>>>> * Is your document's format or its terminology based on another >>>>>> document, >>>>>> WG style guide, etc.? If so, please provide a pointer to that >>>>>> information >>>>>> (e.g., "This document's terminology should match DNS terminology in >>>>>> RFC 9499." or "This document uses the style info at >>>>>> <https://httpwg.org/admin/editors/style-guide>."). >>>>>> * Is there a general pattern of capitalization or formatting of terms >>>>>> that >>>>>> editors can follow (e.g., "Field names should have initial >>>>>> capitalization." >>>>>> or "Parameter names should be in double quotes." or "<tt/> should be >>>>>> used >>>>>> for token names." etc.)? >>>>> >>>>> Everything introduced in terminology is capitalised. >>>>> In terms of terminology, RFC9901 (SD-JWT) is an important reference for >>>>> the issuer-holder-verifier model that we’ve been following for this draft. >>>>> >>>>>> 3) Please carefully review the entries and their URLs in the >>>>>> References section with the following in mind. Note that we will >>>>>> update as follows unless we hear otherwise at this time: >>>>>> >>>>>> * References to obsoleted RFCs will be updated to point to the current >>>>>> RFC on the topic in accordance with Section 4.8.6 of RFC 7322 >>>>>> (RFC Style Guide). >>>>>> >>>>>> * References to I-Ds that have been replaced by another I-D will be >>>>>> updated to point to the replacement I-D. >>>>>> >>>>>> * References to documents from other organizations that have been >>>>>> superseded will be updated to their superseding version. >>>>>> >>>>>> Note: To check for outdated RFC and I-D references, you can use >>>>>> idnits <https://author-tools.ietf.org/idnits>. You can also help the >>>>>> IETF Tools Team by testing idnits3 >>>>>> <https://author-tools.ietf.org/idnits3/> >>>>>> with your document and reporting any issues to them. >>>>> >>>>> We found a few smaller issues like sd-jwt vc having published a new >>>>> version (and I’d assume they will publish another version before IETF >>>>> Vienna). There also seem to be some minor problems with the txt rendering >>>>> of lists in the IANA section that I will try to resolve. >>>>> Should we release a new version with those fixes? >>>>> >>>>>> 4) Is there any text that requires special handling? For example: >>>>>> * Are there any sections that were contentious when the document was >>>>>> drafted? >>>>>> * Are any sections that need to be removed before publication marked as >>>>>> such >>>>>> (e.g., Implementation Status sections (per RFC 7942)). >>>>>> * Are there any instances of repeated text/sections that should be >>>>>> edited >>>>>> the same way? >>>>> >>>>> Document history is present that is marked as “to be removed from the >>>>> final specification” >>>>> There are some TBD placeholders for IANA registration which need to be >>>>> adjusted once identifiers are assigned >>>>> >>>>>> >>>>>> 5) This document uses one or more of the following text styles. >>>>>> Are these elements used consistently? >>>>>> >>>>>> * fixed width font (<tt/> or `) >>>>>> * italics (<em/> or *) >>>>>> * bold (<strong/> or **) >>>>> >>>>> No >>>>> >>>>>> 6) This document contains sourcecode: >>>>>> >>>>>> * Does the sourcecode validate? >>>>>> * Some sourcecode types (e.g., YANG) require certain references and/or >>>>>> text >>>>>> in the Security Considerations section. Is this information correct? >>>>>> * Is the sourcecode type indicated in the XML? (See information about >>>>>> types: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types.) >>>>> >>>>> No >>>>> >>>>>> 7) Would you like to participate in the RPC Pilot Test for editing in >>>>>> kramdown-rfc? >>>>>> If so, please let us know and provide a self-contained kramdown-rfc >>>>>> file. For more >>>>>> information about this experiment, see: >>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. >>>>> >>>>> If it doesn’t delay publication, sure! Our repository containing the >>>>> markdown is at https://github.com/oauth-wg/draft-ietf-oauth-status-list >>>>> It is not a fully self-contained file right now though with the examples >>>>> in separate files. >>>>> >>>>>> >>>>>> 8) Would you like to participate in the RPC Pilot Test for completing >>>>>> Final Review >>>>>> in GitHub? If so, please let us know and provide all author, AD, and/or >>>>>> document >>>>>> shepherd GitHub usernames. For more information about this experiment, >>>>>> see: >>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test. >>>>> >>>>> Same as 7) >>>>> >>>>> https://github.com/oauth-wg/draft-ietf-oauth-status-list >>>>> Author’s GitHub handles: c2bo, paulbastian, tplooker >>>>> AD: debcooley >>>>> Document Shepherd: rifaat-ietf >>>>> >>>>> (Deb, Rifaat please check, but these seem to be correct?) >>>>> >>>>>> 9) Is there anything else that the RPC should be aware of while editing >>>>>> this >>>>>> document? >>>>> >>>>> >>>>> Nothing we are aware of >>>>> >>>>> --- >>>>> >>>>> Best Regards, >>>>> >>>>> Paul, Tobias, Christian >>>>> >>>>> >>>>>> On 4. Jun 2026, at 23:30, [email protected] wrote: >>>>>> >>>>>> Author(s), >>>>>> >>>>>> Congratulations, your document has been successfully added to the RFC >>>>>> Editor queue! >>>>>> The team at the RFC Production Center (RPC) is looking forward to >>>>>> working with you >>>>>> as your document moves forward toward publication. To help reduce >>>>>> processing time >>>>>> and improve editing accuracy, please respond to the questions below. >>>>>> Please confer >>>>>> with your coauthors (or authors of other documents if your document is >>>>>> in a >>>>>> cluster) as necessary prior to taking action in order to streamline >>>>>> communication. >>>>>> If your document has multiple authors, only one author needs to reply to >>>>>> this >>>>>> message. >>>>>> >>>>>> As you read through the rest of this email: >>>>>> >>>>>> * 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). >>>>>> * If you feel no updates to the document are necessary, please reply >>>>>> with any >>>>>> applicable rationale/comments. >>>>>> >>>>>> >>>>>> Please note that the RPC team will not work on your document until we >>>>>> receive a >>>>>> reply. We require a reply, even if you don’t have guidance or don’t >>>>>> feel that you >>>>>> need to make any updates to the document. After we hear from you, your >>>>>> document >>>>>> will start moving through the queue. You will be able to review and >>>>>> approve our >>>>>> updates during Final Review (formerly AUTH48). >>>>>> >>>>>> Please feel free to contact us with any questions you may have at >>>>>> [email protected]. >>>>>> >>>>>> Thank you! >>>>>> The RPC Team >>>>>> >>>>>> -- >>>>>> >>>>>> 1) As there may have been multiple updates made to the document during >>>>>> Last Call, >>>>>> please review the current version of the document: >>>>>> >>>>>> * Is the text in the Abstract still accurate? >>>>>> * Are the Authors' Addresses, Contributors, and Acknowledgments >>>>>> sections current? >>>>>> >>>>>> >>>>>> 2) Please share any style information that could help us with editing >>>>>> your >>>>>> document. For example: >>>>>> >>>>>> * Is your document's format or its terminology based on another >>>>>> document, >>>>>> WG style guide, etc.? If so, please provide a pointer to that >>>>>> information >>>>>> (e.g., "This document's terminology should match DNS terminology in >>>>>> RFC 9499." or "This document uses the style info at >>>>>> <https://httpwg.org/admin/editors/style-guide>."). >>>>>> * Is there a general pattern of capitalization or formatting of terms >>>>>> that >>>>>> editors can follow (e.g., "Field names should have initial >>>>>> capitalization." >>>>>> or "Parameter names should be in double quotes." or "<tt/> should be >>>>>> used >>>>>> for token names." etc.)? >>>>>> >>>>>> >>>>>> 3) Please carefully review the entries and their URLs in the >>>>>> References section with the following in mind. Note that we will >>>>>> update as follows unless we hear otherwise at this time: >>>>>> >>>>>> * References to obsoleted RFCs will be updated to point to the current >>>>>> RFC on the topic in accordance with Section 4.8.6 of RFC 7322 >>>>>> (RFC Style Guide). >>>>>> >>>>>> * References to I-Ds that have been replaced by another I-D will be >>>>>> updated to point to the replacement I-D. >>>>>> >>>>>> * References to documents from other organizations that have been >>>>>> superseded will be updated to their superseding version. >>>>>> >>>>>> Note: To check for outdated RFC and I-D references, you can use >>>>>> idnits <https://author-tools.ietf.org/idnits>. You can also help the >>>>>> IETF Tools Team by testing idnits3 >>>>>> <https://author-tools.ietf.org/idnits3/> >>>>>> with your document and reporting any issues to them. >>>>>> >>>>>> >>>>>> 4) Is there any text that requires special handling? For example: >>>>>> * Are there any sections that were contentious when the document was >>>>>> drafted? >>>>>> * Are any sections that need to be removed before publication marked as >>>>>> such >>>>>> (e.g., Implementation Status sections (per RFC 7942)). >>>>>> * Are there any instances of repeated text/sections that should be >>>>>> edited >>>>>> the same way? >>>>>> >>>>>> >>>>>> 5) This document uses one or more of the following text styles. >>>>>> Are these elements used consistently? >>>>>> >>>>>> * fixed width font (<tt/> or `) >>>>>> * italics (<em/> or *) >>>>>> * bold (<strong/> or **) >>>>>> >>>>>> >>>>>> 6) This document contains sourcecode: >>>>>> >>>>>> * Does the sourcecode validate? >>>>>> * Some sourcecode types (e.g., YANG) require certain references and/or >>>>>> text >>>>>> in the Security Considerations section. Is this information correct? >>>>>> * Is the sourcecode type indicated in the XML? (See information about >>>>>> types: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types.) >>>>>> >>>>>> >>>>>> 7) Would you like to participate in the RPC Pilot Test for editing in >>>>>> kramdown-rfc? >>>>>> If so, please let us know and provide a self-contained kramdown-rfc >>>>>> file. For more >>>>>> information about this experiment, see: >>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. >>>>>> >>>>>> >>>>>> 8) Would you like to participate in the RPC Pilot Test for completing >>>>>> Final Review >>>>>> in GitHub? If so, please let us know and provide all author, AD, and/or >>>>>> document >>>>>> shepherd GitHub usernames. For more information about this experiment, >>>>>> see: >>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test. >>>>>> >>>>>> >>>>>> 9) Is there anything else that the RPC should be aware of while editing >>>>>> this >>>>>> document? >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
