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

+1 :-)

I've added it to the agenda:

https://codimd.ietf.org/cmt-20210503

On 4/30/21 4:34 PM, Sandy Ginoza wrote:
> 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 <c430@rfc-editor.org
>> <mailto:c430@rfc-editor.org>>
>> *Subject: **[C430] Process we're following for AUTH48*
>> *Date: *April 27, 2021 at 10:11:43 PM PDT
>> *To: *c430@rfc-editor.org <mailto:c430@rfc-editor.org>
>>
>> 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
>> <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
>> C430@rfc-editor.org <mailto:C430@rfc-editor.org>
>> https://www.rfc-editor.org/mailman/listinfo/c430
>>
> 
> 