>> With the move to XML and renderings of a new RFC in different >> formats, who is responsible for reviewing the different >> renderings for unintended changes in meaning? If it's the >> authors, I'd hope that a change in AUTH48 might offer some way >> to spread the burden. >> >> FWIW > > Larry, based on the last document with which I went through > AUTH48 (in the first half of 2020), it wasn't clear who, if > anyone, was responsible for checking the different formats and > renderings. “Responsible”: The authors of course (in theory). > Of course, the theory is that, if the XML is > correct, everything else should take care of itself. Well, that isn’t even a theory. Xml2rfc has its mysterious ways. More importantly, implementers will look at a rendering (TXT, HTML/PDF). If that is confusing, you will have interoperability problems (or low take-up). So authors will typically check one of the renderings in some detail. (Only with a lot of luck, they will seriously both TXT and HTML or PDF, which unfortunately is really needed in particular since 3.10.0.) Where aspects of the XML are not visible in the renderings, the RPC has started to ask specific questions. E.g., for the type= attributes of <sourcecode elements. I’m not sure there is a checklist of invisible aspects. It would help to have an debug-the-XML rendering where all these invisible aspects become visible. In summary, I think that a theory where authors are responsible for the XML will stay fiction. The RPC is much better off doing this, being used to operate in that noisy environment, and (I hope) more aware what went wrong in previous RFCs. Grüße, Carsten
