RFC Series WG - IETF 116, 28 March 2023 Note well Agenda Bashing - none Paul Hoffman/John Levine - draft-rswg-xml2rfcv3-implemented * Document is close to what the code is currently doing (e.g as-built documentation) * Now a WG document, almost ready for publication * Paul reviews * EKR - Please file issues against the document, github; discuss on mailing list; * Paul - document will evolve from as-implemented to will-be-implemented back to as-implemented??? * Robert Sparks - Where will grammar of existing documents be documented? * Pete Resnick - conversation about meta issues will continue on the list? * John - possible flag day between old XML and new XML if not backwards compatible * Martin Thompson - fix build system * Robert - will help fix it - byzantine - so contributors can see what result is * Jay Daley - may tiake some time to get consensus for changes, which has follow on delays * Carsten Bohrman - Publishing format or authoring format - Paul - publishing format * Paul - missing the conversation with the authors,need more information for the author, not “Authors MUST” * Martin - How to manage the point in time diffs between documentation and implementation; Paul - RPC picks when tools change; M - will have to discuss when changes result in backwards compatibility issues and timing - document - what we want, what it was, and when different?; Timestamp/version stamp XML2RFC * Robert - also version run by RPC for final document creation * Lars Eggert - Tool may not completely implment a draft, so tool should be able to capture that in the timestamp? Other alternative would be tool implementation drives draft creation/publication * Pete - draft driving tool is better * Carsten - authoring format -> auth48 -> publication format; some surprises at this crossover - avoid. * Paul - just because input passes XML test, does not mean that publication will use that XML (e.g. style guide?) * Paul/John - Proposed XML Changes - see the slides * Back out postal element; Jay - way that an address is structured differs per country. Let the authors format; John - Leave country element though * Jean Mahoney - Bug with how lib renders country when “The Netherlands” - will keep country, but not lib. * John - run lib over the current RFCs, take the rendered Postal element and use it as postal lines replacement. * EKR - country field contents could be a problem for political reasons?; Paul - just go ahead and do it, use what’s provided * Jean - will use it if deliverable by post. (MSJ: so postal union) * Paul - style guide for country names rather than politics. * Martin - pull the address out of the published RFC.; Maybe we shouldn’t change the canonical XML even for this.; more general discussion about when its legitimate to change XML on published documents * Paul - another document about when we change XML in existing documents * Jay - Maybe drop postal entirely. Including country; Pete - propose that on the list * Sandy G - Postal elements are optional so no impact on the style guide if ommited. * Now about the “u” element. * Robert - the “u” does exist in published RFCs. * Paul - do we want to strip it out? * John - “u” element used for non-ascii text, but now allowed elsewhere * Carsten - “u” element is handy when calling out codepoints - specific visual character choice * Paul - may need re-rendering (library issue??) relative to “u” * “SeriesInfo” will be addressed on the list * Martin - preptool. Tool adds back in defaults; list discussion about this; table of contents is a problem; identifiers get attached - stable means of identification; * Robert - ability to re-render document as-is; old RFC - but new tool; bits are there so later versions of preptool can recover lost info??? * EKR - Probably not a useful function here. * Martin - ok to have breaking changes so no need to keep all of the original rendering info? Anchors good and permanent? Perhaps specify anchor formats? XINCLUDE * Jay - Look at defaults on individual basis. Some are meaningful? But meaningful defaults are bad (from list); relaxng does not permit defaults;should be possible to reduce default bloat * Robert - (Missed this? RPC vs Authoring?) * Pete - preptools - implementation of policy vs other things * Martin - Push publication format closer to authoring format? (pre-preptool?) tedious to find the differences in the authoring format post-preptool? * Jay/Martin - argument again about how what you approve is not what’s published. * Jay/EKR - section numbers follow document format * Paul - Preptool is not final tool * Martin - lets chew on section number stuff; document a process for generating the identifiers; could document current system; unambiguous; Alice - is there something particular that happens you don’t like; Martin - all of the section marking and TOC stuff. * Carsten - tool produces bugs; need to be able to translate AUTH48 back to the submission language so can understand what AUTH48 did; * Robert - when we make changes to our structures or tools input formats, breaks other communities past ours; changing identifiers might have a downstream effect; keep this data in the xml so that latter authors have the data available so they can maintain some stability in later documents. * Martin - no good solution to moving section numbers.; standardize how refs are generated; * Paul - we’re talking about changing the preptool * EKR - perhaps move this topic to a design tool * Robert - modify/deprecate preptool * Jay - correction our relaxNG schema has defaults, we’re using an extension * Mike SJ - maybe you could program people to use section headers instead of numbers * Pete - Need a discussion about deprecating preptool * Paul - draft-hoffman-frc7997bis - non-ascii characters * Still individual draft, discussion driver for the topic. 7997 to address policies by RPC to include non-ascii chars in RFCs. more on the slides * (on slide 2) Carsten - why are we talking about this? Maybe not BIS, but a complete rethink? 7997 caters to exactly one disaster scenario; what damage are we trying to prevent. (msj: I’m unclear whether he’s referring simply to author names or to the non-ascii as a whole) * Martin - Typography questions - deferred to later * John Preus(sp?) - yes, work on non-ascii; make thing clear to reader; * Paul - propose to adopt as a WG document; happy to drop this drat and start afresh; up to WG; * Martin Durst (md) - Supports adoption; Suprised about RSAB - RFC7997 if not prohibited there is permitted; Add math typeography explicitly; RPC owns most items of style (smart quotes?) but document to delineate? * John L - Supports adoption, (with work), PDF might not include fonts? Rendering vs permissive typography vs RPC * Jay - Clarify - document will clarify typograpy and rest; Paul - yes * Carsten - (Missed this - which policy?) Typography is a policy issue for RSWG to decide, but maybe not this document * MD - Maybe defer typography to separate document than 7997bis * Jean - Style guide currently says Ascii equivalents for punctuation - changes will require tooling changes. (re smart quotes) * Carsten - not talking about good typography? * Pete - hand raising exercising. “Choice 1 adopt this doc; 2 - another doc on this topic instead, 3 -I don’t care” 2/3s choice 1, 2 - choice 2, 1 choice 3 * AOB - NONE!!! * Lars - on behalf of the RSAB. Will only meet when RSWG has passed on documents; didn’t meet this time * Paul - RSAB may want to discuss RFC7997bis because its per-stream * Lars - maybe bring to list or ask for a referral.