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]
