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.