Attendees: Paul, Joe, Heather, Alice, Nevil, Julian, Tony, Robert

Absent: Adam, Ted, Dave

0. Administrivia

• Next call scheduled for 10 July 2014; that is the last call we have on the calendar

Heather to send out a poll after the next agenda update so that the design team can meet. Joe is tentative for July 10

1. Status of existing drafts

• xml2rfc v2
  • draft-reschke-xml2rfc-09 posted

So far, only small editorial improvements, and that is already in the -09 draft. Some of those applied to the v3 draft, and Paul added that to his draft as well. Now waiting for the second review to come in.

• xml2rfc v3

Paul has a stack of small to medium sized things to put in. Some will be impacted by conversations today or on the list. A significant rev is scheduled for next week. Some of the bigger ones (e.g., are we going to have a micro format for particular kinds of tables?) should be discussed in Toronto.

• PDF
  • draft-hansen-rfc-use-of-pdf

• HTML
  • discussion topic: retention of [none|some|most|all] semantic info from the XML?

Joe is willing to back to back off of the strong stance on Julian is a metadata junkie, and likes having as much in the HTML, so let’s back off on ALL. So, what additional information do we want in the HTML for which there are customers (e.g., search engines). Joe is ok with that for now, but if we decide some day that the HTML is more important than the XML, we need to revisit this decision. (ALL AGREED)

(Paul) the semantics we currently have for ‘id=‘ will help with this quite a bit. (Joe) we could also use classes; the less that we polite the name space in IDs with semantics will be helpful.

(Paul) Like using id’s for single sections that we know what they are - any objection? (Julian) copyright or TOC are examples should have id’s instead of classes because you want to be able to link to them. We need to know how to reserve the names we want to auto generate so there are no collisions. We can do that with a prefix, a white list, something. (Paul) Now, we’re going to call TOC and copyright, and those are going to be the same as author-generated id’s, so the processor will have to check that the author isn’t using them themselves. (Joe) we just need to make sure this is in the tools to check.

(Paul) this will make things easier in the XML draft, and make the the HTML auto generated id’s for: section, figure, paragraph (numbered within a section)

(Joe) prefer prefix to blacklist or whitelist; search engines will still find something like prefix-copyright.

(Paul) prefix shouldn’t be “rfc-” or “id-” or “x-“, but it could be “-“; (Julian) the anchor syntax in HTML is probably relaxed, but a fragment identifier probably needs to start with a letter

The advantage here is that people who haven’t seen this RFC can still index into it in relevant places. That’s why the auto-linking that the rfc markup script that generates the current markup script, because it knows what the target will be.

Paul will need to add auto generating paragraph to the xml2rfc v3 draft; (Julian) adding paragraph will be a bit of an exercise to figure out tables and figures; a complete list will still be a paragraph when it is not a top level. When a list is a child lament of a section…

Section 2 starts with a heading, then a whole paragraph, then a free standing list, then a paragraph. What should the list number be? 2? (Julian) yes. (Paul) anything that can be a top level item in a section needs to have auto-generated “foo” and they will all be the same that gets reset for every section. (Julian) it is a matter of taste. If a list is text, it could anchor as a paragraph, but if it is figures, it could anchor as a figure. Paul will start with everything in a section have the same numbering scheme. (Julian) since tables and figures may already have labels, they can have their own numbering. Paragraph (1), list(2), figure(1), paragraph(3). Figures will have a global counter.

(AOB) 2119 markup

• the concern of many people is that if we start doing things differently, what will that actually mean. We could say “that is completely optional”, or we could say “everyone needs to do that” and we will need to discuss what is normative and what’s not. The latter sounds painful, but it is probably useful since we have these conversations now. (Joe) maybe not markup in the HTML, but markup in the XML which could then markup the HTML. (Julian) if you markup in HTML and that has significance, and is identified by the tool, then the introduction would be marked up.
• (Paul) should the canonical RFC retain what the author did? (Julian) if it has no significance other than styled differently, then it should be retained in the canonical XML.
• (Paul) then propose we come up with something like <em> (which would turn into a span of the appropriate class) that says you can do <bcp14> however you want, and the default style sheet will make them bold, but that will not convey any normative semantics. It should be optional with rules.
• (Julian) has been doing that with his extensions for a while, and can come up with a concrete proposal right away. (Paul) that’s not the concern; needs to know the restrictions, such as if anything in that element is other than a keyword. (Julian) in his code, anything other than a bcp 14 keyword will come up as a warning.
• (Joe) capitalization can remain up to the author, and we might decide to provide entities for people that don’t want to type the closing tags every time. We are already going to have to expand the I-Ds anyway. We might retina entities in the author entities for references, and expand them out for the last step.

In HTML this will turn into <span class = bcp 14>

2. Remaining drafts to be created

• XML examples: “instead of waiting on examples, maybe we start another doc that is examples of both v2 and v3, which would serve two purposes: help people still using v2, and help focus on differences with v3”

Julian and Paul haven’t start on this, and probably won’t have it this week. May have a -00 when the window opens in Toronto. (Robert) would you be willing to set aside a time during IETF week to have at least a set of examples by the end of the meeting? (Julian) will be there until Saturday, so should have free time after Tuesday.

Remember Tony has a fairly complete conversion tool drafted. Perhaps we should run this against the existing pile of AUTH48 XML drafts? Julian has the large pile of drafts that we could test against. Julian will send a zip file to Tony and Joe with the drafts.

3. IETF 90

• IAB session on RFC Format expected
  • topics for that session: update on each draft from the authors; estimated timeline for project; CSS prototypes

4. AOB

• * (Julian) if we have time I'd like to demo by new XSLT/browser magic…
• * (Heather) plain text brouhaha
• * (Nevil?) anything more to say about the SVG draft?