| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| pilot_test_instructions_completing_auth48_using_kramdown [2026/05/07 18:52] – old revision restored (2025/08/29 21:44) sginoza | pilot_test_instructions_completing_auth48_using_kramdown [2026/09/24 18:50] (current) – sginoza |
|---|
| ====== AUTH48 Using kramdown-rfc ====== | ====== Final Review Using kramdown-rfc ====== |
| |
| |
| This page provides instructions and information regarding the AUTH48 process for a document that has been edited in kramdown-rfc. For information on the pilot test, please see "[[https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc|RPC Pilot Test: Editing and AUTH48 in kramdown-rfc]]". | This page provides instructions and information regarding the process for Final Review (formerly called AUTH48) for a document that has been edited in kramdown-rfc. For information on the pilot test, please see "[[https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc|RPC Pilot Test: Editing and Final Review in kramdown-rfc]]". |
| |
| This process requires two approvals from the authors during AUTH48: one for the content review and a final one that includes approval of the formatting and the outputs of XML. | This process requires two approvals from the authors during Final Review: one to indicate the markdown is ready to be converted to XML and a final one that indicates the document is ready for publication as an RFC (final approval of the content and formats). |
| |
| |
| ===== Reviewing content ===== | ===== Initial review ===== |
| |
| When the document enters AUTH48, the authors should review the document content for accuracy and comprehension. Any needed updates should be sent to the RPC per the [[#submitting_updates|"Submitting updates"]] section below. Note that format-related updates that impact the content may be updated during this time. | When the document enters Final Review, the authors should review the document for accuracy and comprehension. Any needed updates should be sent to the RPC per the [[#submitting_updates|"Submitting updates"]] section below. |
| |
| At this stage, updates will be made in the **kramdown-rfc file**. | At this stage, updates will be made in the **kramdown-rfc file**. |
| * **Copyright notices and legends** \\ Authors should review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). | * **Copyright notices and legends** \\ Authors should review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). |
| |
| | ===== Final review and approval ===== |
| |
| ===== Reviewing format ===== | Once all of the authors believe the content is stable and the markdown is ready to be converted to XML, the RPC will a) convert the kramdown-rfc file to RFCXML, b) make any remaining format updates, and c) provide the XML, TXT, |
| | |
| Once all of the authors have approved the content, the RPC will a) convert the kramdown-rfc file to RFCXML, b) format the document, and c) provide the XML, TXT, | |
| HTML, and PDF outputs for authors to review. Any needed updates should be sent to the RPC per the [[#submitting_updates|"Submitting updates"]] section below. | HTML, and PDF outputs for authors to review. Any needed updates should be sent to the RPC per the [[#submitting_updates|"Submitting updates"]] section below. |
| |
| At this stage, all changes will be applied in the **XML file**. | At this stage, all changes will be applied in the **XML file**. |
| |
| Authors should pay particular attention to the following: | Authors should ensure the overall readiness of the document for publication, including the content, semantic markup (e.g., ensure <sourcecode> and <artwork> are set correctly), and formatted outputs (i.e., ensure the PDF, HTML, and TXT files generated from the XML display properly). |
| | |
| * **Semantic markup** \\ Authors should review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. | |
| | |
| * **Formatted output** \\ Authors should review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Note that the TXT will have formatting limitations compared to the PDF and HTML. | |
| |
| |
| ===== Submitting updates ===== | ===== Submitting updates ===== |
| |
| For both content and format-related updates, authors should reply to the AUTH48 email using ‘REPLY ALL’ as all the parties CCed on the message need to see the changes. The parties include: | For both content and format-related updates, authors should reply to the Final Review email using ‘REPLY ALL’ as all the parties CCed on the message need to see the changes. The parties include: |
| |
| * coauthors | * coauthors |
| * rfc-editor@rfc-editor.org (the RPC team) | * rfc-editor@rfc-editor.org (the RPC team) |
| * other document participants, depending on the stream (e.g., IETF Stream participants include working group chairs, the responsible ADs, and the document shepherd). | * other document participants, depending on the stream (e.g., IETF Stream participants include working group chairs, the responsible ADs, and the document shepherd). |
| * auth48archive@rfc-editor.org, which is an archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: | * auth48archive@rfc-editor.org, which is an archival mailing list to preserve Final Review conversations; it is not an active discussion list: |
| * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc | * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc |
| * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ | * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ |
| ===== Sending approval ===== | ===== Sending approval ===== |
| |
| To approve the RFC for publication, all authors should reply to the AUTH48 email stating that they approve the RFC. Please use ‘REPLY ALL’, as all the parties CCed on the message need to see the approval. | Each listed author must approve the document before it can be published as an RFC. To approve the RFC for publication, all authors should reply to the Final Review email stating that they approve the RFC. Please use ‘REPLY ALL’, as all the parties CCed on the message need to see the approval. |
| |
| Coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing approval. | Coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing approval. |
| |
| Note that if an author is no longer available, alternate paths are outlined in the FAQ (https://www.rfc-editor.org/faq/). | Note that if an author is no longer available, alternate paths are outlined in the FAQ (https://www.rfc-editor.org/faq/). |
| |
| |
| ===== Tracking progress ===== | ===== Tracking progress ===== |
| |
| The details of the AUTH48 status of your document are here: | The details of the Final Review status of your document are here: |
| https://www.rfc-editor.org/auth48/rfcXXXX (where XXXX is the RFC number) | https://www.rfc-editor.org/auth48/rfcXXXX (where XXXX is the RFC number) |
| |
| The AUTH48 email contains a direct link. | The Final Review email contains a direct link. |
| |
