Expected:Alice, Adam, Joe, Tony, Ted, Robert, Nevil, Paul
Apologies:Julian, Dave
0. Agenda bash
1. Administrivia
a. BoF agenda b. Continuation of the Design Team after Vancouver?
2. Tooling and Requirements
a. see https://www.rfc-editor.org/rse/wiki/doku.php?id=design:producing-output&#proposed_future_production b. status of 2629-bis c. status of HTML requirements d. short summary-to-date of i18n program discussion on non-ASCII characters
BoF agenda: (see Format Education evernote)
Continuation of Design Team?
Tooling and Requirements * have updated the production process notes to try and clear up what tools are actually being discussed and who would use them - questions? There is a step between 2 and 3 where the RFC Ed produces a proposed canonical version of the doc; or, perhaps, we need to say that step 2 must precede step 1. The community probably doesn't realize that the RFC Ed converts things to XML, and that will help us on our discussion on future production (if they are not holding XML at the beginning of the process, they create it (which will in turn result in a bit more time to the process)) The tool could, after validation, change the document to be more editable (a pretty-printer) - not a requirement, but that could be helpful We haven't noted what the authors will be reviewing during AUTH48. They have to review at least a publication format, noting that in approving that they are also approving the canonical XML. We need to be explicit about what we're reviewing. One suggestion is review the HTML output. Another suggestion is reviewing both HTML and text outputs. That might be too burdensome. Paul notes that during AUTH48 authors review diffs, which are HTML, as well as the text. There is a long term goal of authors only signing off on HTML, and any errors become problem of RFC Editor, but we're not going to have that out of the box. Short-term, we will have to ask for more to generate confidence in the approach. There is some push to move towards using rfcdiff. The one we send the link to is the HTML whiff file with the red and green. If any docs has spacing issues or whitespace issue, then the RFC Ed creates the rfcdiff file What will the new question become to authors? “Make sure these following output formats are correct” with a long term goal of “Make sure the HTML is correct” If this comes up as part of the conversation during the BoF, need to emphasize that the canonical format is XML. Note that ideally we are NOT changing the non-canonical formats. Things might look different for people in the future, but we can deal with that on a case-by-case basis. This is a discussion will need to happen in the future. For people who can and want to have the most control, they would be reviewing the XML, most people won't want to do that, so they will be reviewing the next closest hop to that, then it will be up to the RPC to take their comments back to change the XML (actually, it can be authors or editors, per situation) - may want to call this out explicitly There needs to be a step that explicitly lays out what the accepted inputs are at each step; remember that there is a step that will modify the XML and pull in various PIs and other pieces. The upload of I-D can be text or XML
* status of 2629-bis - don't know, haven't seen progress - any suggestions? we need more than documenting v2 format - we need v3 format either we need to fork 2629-bis OR Julian needs a tool to create two different document; forking isn't really possible until we create 2629-bis There is already a successor to 2629-bis, so using that name is confusing; Julian's current doc is based on the coe and will have an appendix on things that might get added, but we need a doc that captures what's changing or getting added Having some clarity to say “documenting vocabulary for v2 and talking about a potentially different or expanded vocabulary for v3”
* status of HTML requirements - talked to both Joe and Julian re using the draft-hildebrand-html-rfc as a base, and I think I have agreement and acceptance on that. Next steps? several other things will need to be revised to do this, including removing roundtripping - will they be reflected in the working copy by then? Yes. It will be important to have that doc to point to “gross morphology of HTML”; Joe has enough to get started, but there will be an aggressive feedback round between friends
* summary on i18n program discussion - seeing a stronger desire to expand where and how we use non-ASCII characters in an RFC, but while there seems to be agreement on the fact that needs to be done, the discussion is ongoing on how best to do it and where to allow it. List will continue to work on this and there will be a meeting in vancouver of the i18n program to discuss further.
