User Tools

Site Tools


Attending: Heather, Sandy, Nevil, Tony, Robert, Julian, Joe, Paul

0. Agenda bash

1. Report out from meeting with IAB & IETF chairs (Heather)

A variety of topics covered, from how the transition will work, how the tools development process should iterate, what should be published when XML is not provided by authors. There are some important open questions re: the PDF format, posted directly to Tony, that will impact exactly what we do with publishing the PDF, but the transition plan proposed changes have been drafted in the -02 of the framework draft (github link posted yesterday). For the I-D issues, the IESG will choose to review whatever format has the best diff tool available; right now, that’s plain text and that’s what they will continue with until something equally useful to them is available. Further discussion about the implications for the IESG process and I-Ds is slated for the Monday joint breakfast with the IESG/IAB, and some discussion is now happening on the IESG mailing list.

2. Draft status

  1. xml2rfc v2 (Heather/Julian)

Julian has two to-dos: remove a section (App D), and look at that offending sentence in i18n section, then submit.

Joe: we do still need better language around <iref> but don’t know it well enough to suggest alternative text

  1. xml2rfc v3 (Paul)

Paul: no updates since last call. Joe is looking at it carefully from the HTML standpoint. Until we get more feedback, there are no outstanding to-do's

  1. Examples (Paul)

Paul: no additional feedback yet. One person said they hoped that the example we had could be used as a template for people to write an RFC from v3, which should be fine. That’s not a final goal, but it is likely to just work that way.

Joe: a little grumpy that it doesn’t have one of everything, but understand why it isn’t, so started a more detailed document that includes examples of everything. Target is the developers. It is a separate document, and it can be added as an appendix later.

Paul: since this will be published as an RFC in the old format, we might point to examples elsewhere.

Julian: why can’t this be published in the new format? It will be tough for the tools team if they are using this as an input.

Paul: we could not have the examples with limited column lengths in a draft, but instead put them on a website with long-lived URLs.

Joe: could do what the codex team did, and encode in a way that’s easy to recover and put it in the draft encoded. Massive overkill,

Robert: It depends if we need that level of exactness, but we don’t.

Sandy: why not publish a -bis document when new format is available?

Tony: what examples should be covered in this document?

Joe’s draft will have one instance of every element in v3.

Robert: the primary distinction as to whether the examples draft includes it, is whether a reasonably informed document editor needs a hint. You have two different audiences. The audience for Tony/Paul’s draft is authors. The audience for Joe’s draft is coders. Because of that, trying to roll what Joe’s doing into an appendix is the right thing to do. Should stand as its own document.

Paul: we might go to rfc-i with that specific question, give we have flushed out the initial responses. If we get no further suggestions, we might be close to done on the Tony/Paul draft.

  1. HTML (Joe)

Joe: putting together a source v3 doc that has one of everything, writing a translation of that into HTML, then documenting what that translation is into HTML. The HTML draft will be parallel to the v3 draft, plus extras around how to render the overall stuff. That makes the draft much longer than it was, but it will be what the tools team needs.

Julian: if you are doing what you’re doing, then we will have a validator from v3 to HTML. Joe: yes, but would prefer to think of it as a prototype that the tools team may or may not want to use. It’s is a moderately esoteric tool change using node, not using XSLT.

Julian: one thing that makes me unhappy about detailing every bit of HTML; if we had smart developers using HTML, they might do this better than you.

Joe: should have an update by draft deadline (Oct 28)

  1. PDF (Tony)

Tony: having difficulty getting the co-authors to engage; trying to set up a meeting this week to force some answers on some of the open issues, and hopefully will have something more definitive later this week. Will remind them of the draft deadline no later than Oct 28

Julian: question regarding PDF; the reason we suddenly like PDF is because it embeds XML? Heather: no, that’s not the only reason

  1. framework (Heather)

Sandy: in section 10.2, where it talks about docs that will be submitted in text as only published as text - is that still correct? No, HF needs to fix. Need to be clear that the plain text published while we’re in testing is NOT published from the XML, but using the existing process

3. IETF 91

  1. Reminder: one more call before IETF 91, on Oct 28. Given the timeline posted at the last IETF meeting, we need to have the drafts stable enough for the SoWs to go out by then. Possible?
  1. Format session?

I’m leaning towards “no” since at this point we don’t really have questions for the community, and updates regarding progress and next steps can be posted to the rfc-i list and referred to during plenary. I haven’t discussed this with the RSOC.

  1. Design Team meeting?

Yes. Tony won’t be there

4. AOB Joe: sent something to the list re: considering changing the date format in v3

Julian: it is used in two different ways; sometimes for exact dates and to weight things in references; if you can account for both use cases, that’s fine. We could use ISO format and prose; that would be acceptable

Joe: quick demo of tooling

Tony: put a note on rfc-i re: the version tool, and one of the first comment was “can I convert the output of this into text?” i.e., is there a v3 converter they could use now. Obviously, no, but there are people chomping at the bit.

design/20141014-notes.txt · Last modified: 2014/12/17 07:54 by rsewikiadmin