Subject: [Xml-sg-cmt] agenda item for Monday? Fwd: [C430] Process we're following for AUTH48

From: Sandy Ginoza <[email-masked]>
Date: Fri, 30 Apr 2021 15:34:05 -0700

Hi John and Peter,

I’m hoping we can spend some a little time talking about the QUIC docs Monday, either as part of or separately from our xml-sg meeting.  Martin has some comments about the XML.  His document-specific comments are in the attachments.  He also touches on some potential process issues for authors using/reviewing markdown.  

Thanks,
Sandy 

> Begin forwarded message:
> 
> From: Martin Thomson via C430 <[email-masked]>
> Subject: [C430] Process we're following for AUTH48
> Date: April 27, 2021 at 10:11:43 PM PDT
> To: [email-masked]
> 
> I just wanted to provide an update regarding the process the editor team is planning to use for AUTH48.
> 
> We have decided to port the changes proposed by the RPC back to our source documents.  This will give us the opportunity to use our existing processes for reviewing all of the changes.
> 
> Once we have completed that process, we will provide new XML files.
> 
> This leaves a few gaps, as we don't author directly in XML.  We'll need to work through the non-textual changes and work out how to manage those.  So far, I've only identified a few things that might be challenging:
> 
> 1. The addition of <bcp14> elements around "MUST" and friends.  I've implemented a tool that can add those automatically (this tool is XML-aware, unlike that provided by Joe Touch, so I trust it more). [*]
> 
> 2. The RPC propose removing <t> elements that are singular children of <dd> elements.  This is awkward and will likely need a process to resolve.
> 
> 3. References.  The way that the RPC manage these is completely different from our existing process.  Right now I'm thinking that we just take the proposed changes for that section of the XML and manually drop that in as needed.  There are only a few changes in references that we might be able to integrate into the source, so we might be able to avoid any manual processing.  That would mean that the XML we produce is different, but it should produce identical results after the preptool runs.
> 
> No doubt we'll find other issues, but this is what I've observed thus far.
> 
> There is one change across the cluster that I wanted to note.  The RPC proposes to cite the various QUIC drafts using "[RFC9000]" throughout.  Our preference would be to retain the existing labels like "[QUIC-TRANSPORT]" and so forth.  That's more text, but we have found that the labels are easier to manage than numbers.
> 
> [*] I wanted to re-raise the following issue with xml2rfc here: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/548 The invalid XML that is produced by xml2rfc is blocking me from using this tool, largely because of the non-breaking whitespace in the boilerplate inserted by kramdown-rfc2629.  Right now, I'm planning on inserting the boilerplate without the non-breaking whitespace, but I wanted to note that the "&nbsp;" in the XML files we're reviewing is broken as a result and will need to be fixed.
> -- 
> C430 mailing list
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/c430
>