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]
