This shows you the differences between two versions of the page.
— |
design:20131023-notes [2013/12/19 16:40] (current) rsewikiadmin created |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | Expected: | ||
+ | |||
+ | Apologies: | ||
+ | |||
+ | 0. Agenda bash | ||
+ | |||
+ | 1. Administrivia | ||
+ | a. BoF agenda | ||
+ | b. Continuation of the Design Team after Vancouver? | ||
+ | |||
+ | 2. Tooling and Requirements | ||
+ | a. see https:// | ||
+ | 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: | ||
+ | |||
+ | 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' | ||
+ | The tool could, after validation, change the document to be more editable (a pretty-printer) - not a requirement, | ||
+ | We haven' | ||
+ | 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. | ||
+ | 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? | ||
+ | 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. | ||
+ | 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' | ||
+ | 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' | ||
+ | Having some clarity to say " | ||
+ | |||
+ | |||
+ | * 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. | ||
+ | |||