RPC Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Attendees:
Heather, Paul, Robert, Joe, Tony

0. Agenda bash

2. CSS draft <https://datatracker.ietf.org/doc/draft-flanagan-rfc-css/>

Paul: concerned that we might be talking about two different CSS files; if there only drafts and RFCs, then there are things that may be formatted differently depending on what type you’re looking at. There should be one CSS to cover all of the above; it can handle the different cases properly. Don’t want to surprise people with potentially radically different formatting, and if people do create their own CSS, having to edit two CSS is burdensome.  This also future proof’s against potential changes between streams.

Joe: a benefit of having a single CSS file is that it will cache across multiple document. The CSS draft will just be a snapshot of what we’re thinking

Paul: the CSS will be embedded in RFCs, but it may or may not be in I-Ds.

Joe: if we find bugs that need to be fixed as we go along, we will have to fix in multiple pages. Suggest a CSS class in the HTML root identifying whether it’s an I-D or an RFC.  Joe to add that class info into the HTML draft

Robert: Can have the specialization that is I-D specific as a separate block of CSS. 

Heather: need to update the CSS draft to reflect the new class, and indicate that there will be just the one CSS.

1. Preptool and SoW

Robert: have come to convergence on the separation between the preptool and idnits; some minor things to do

Paul: the preptool document has no things in it that it is checking for that is otherwise covered by idnits. Still have the outstanding question of idnits having to do the first two steps in preptool do to it’s job; ordering of tools is going to be interesting. Will need to do maximal includes.

Robert: need to discuss on list some of the more gory details, but that discussion can move to the wider community.  

Joe: there is still a hand-build HTML with more v3 stuff; consider it useful for unit testing. http://hildjj.github.io/draft-hildebrand-html-rfc/

Tony: for the TBD parts of the PDF, now that the HTML doc is solid, that section can be filled in on the PDF document. There are not that many differences from the HTML. What will be different: how paragraphs will be done, headers/footers; things where we can’t count on interactive widgets.  Will work on this after the IETF meeting.

Robert: is there anything else that needs to be cleaned up? SoWs seem to be closed. 

Heather: now waiting for impact with reality.

Paul: a last call on v3 will cause some significant addition; things that will be technical, non-trivial changes to the preptool and the idnits. One important item: <relref> - what do those URLs look like and what do they point to? Right now a relative reference to an RFC is going to be off the info page for the RFC. 

Joe: Would prefer we hold off on this conversation until we have the RSOC conversation about tools.ietf.org versus rfc-editor.org.

Robert: tools needs to be configurable; policy will inform the configuration, but the tools shouldn’t have to wait.

Tony: this won’t be really a “last call” - it’s just the last call before it’s sent off before it’s implemented; it’s not the last call for being published. We expect things to come up that will require doc change. 

Robert: would like to push more in favor of publishing early and revising as we learn from experience.


3. Other updates



4. AOB

- Release of v2 doc = ship it.