Attendees: Alice, Joe, Julian, Nevil, Paul, Robert, Tony
Not available: Adam, Ted, Dave
0. Administrivia
- Document stream for RFC Format docs = IAB
1. SVG draft -03
- “we'll need a way for authors to pull an svg file into their xml draft.” -- is the src attribute sufficient?
XML will do that with no problem (as Joe said)
(Nevil) re: the example documents, they are just examples, not requirements on ways to do things like Packet Diagrams. We do need to make it comparatively easy to make diagrams and get them into documents, so not sure it’s a good idea to runt them through filters to flag issues. Creating a filter with reasonable error messages is going to take some work, since people using drawing tools have little control over the actual SVG.
(Joe) the other question is, it looks like that packet formats should be SVG? (Nevil) that was the last one done and was the easiest of the three. (Joe) but should it be in the draft, as a way to say this is how people should do packet formats? (Nevil) will add text to just show these are examples and not how we recommend/require people do things like packet diagrams. (Joe) using an HTML table may be better than SVG for these diagrams. (Nevil) will people create tables in HTML and then try to pull them into HTML? (Paul) we don’t currently have a way to say “here is HTML for the canonical XML”
(Nevil) writing a draft on how to use the new system will be useful down the line
(Paul) how would you, Joe, have said, here is an HTML table I want it as is in the XML? (Joe) would add table elements into the XML that could render into proper HTML tables, not text tables. (Paul) Julian, could we leave text table as an appendage and redo tables in v3? (Julian) how complex do we want to make them? We need to discuss both structure like spanning rules (Paul) if the purpose is packet diagrams, then spanning rules will be needed (Joe) take the relevant bits from HTML and import them into the v3 syntax. (Julian) Paul’s question was whether we our tables should be expressive enough to generate packet diagrams? Not sure about that. What we should have is something like a description format for packets that the processor can turn into whatever it wants for packets, and not be limited to our vocabulary. (Joe) we will likely want tables for other reasons. (Julian) a subset of HTML might work well, but not sure yet what we might take out. Much styling is in CSS these days.
(Paul) the meta-language for doing this one kind of table, that would be part of the v3 vocal or something external that could be called in as a type of artwork? (Julian) the latter. We don’t want to limit the number of micro languages that can be used to generate useful stuff. (Paul) then the RFC Editor defies what micro languages get used in canonical RFCs. So we are not putting HTML tables in v3. (Julian) the answer is both - we either want to extend text tables to allow more of what HTML allows, and we want to use micro language for packet and sequence diagrams (the top 3-4 art types we see in practice). (Paul) you are ok if we extend text tables and come up with a new one? (Julian) extending the existing model will be problematic because of the different approach it takes, so a new data model makes sense. Would keep the text table and deprecate it and then use something similar to what HTML does. (Joe) would want to see an actual proposal before full agreement, but this makes sense.
Who defines the micro languages?
(Tony) SVG could be a first example of a micro-language. (Julian) if SVG is a micro language, this confuses things. Not sure that will work in practice. (Joe) let’s design it first and see if SVG fits in.
(Nevil) the remaining thing Nevil needs to do is make sure he has all the attributes correct; will do that over the next week or two.
2. v3
- handling unnumbered sections
- <tindent> is or is not like <section> ?
- Xinclude - anything else needed?
- references
Handling unnumbered section
(Paul) we have issues because we call things “sections” that are not “sections” in the XML model. Acks and Contributors are no longer allowed in the body of an RFC, nor are they Appendices, they are special things at the end. One question was how do we write them up in XML? The Abstract is a discrete thing that has a title that looks like a section title, but is unnumbered, but it does not appear in the ToC. Those can be considered sections, or they can be considered special-items that are section like. They do appear in the ToC, and they can have free-flowing text (t tags, paragraphs) so they are more like a regular section than Authors Addresses, which does not contain free-flowing texts.
(Paul) the Style Guide has therefore conflated two things, (Alice) think of these as unnumbered Appendices.
(Julian) looking at current specs in or close to AUTH48, there are references to the Acks section
(Paul) Authors addresses at the end, after the appendices, after the Acks and Contributors section (Paul) does not need to be dealt with in v3, but better wording in style guide will be suggested
(Robert) you were talking about top level things; do we have the concept of unnumbered section now? (Paul) yes, but if it is not the tail of the container, it will throw an error. (Robert) a section that contains subsections is ok? Yes. (Alice) yes, we refer to subsections as a section element.
<Tident> The way it is currently described is that it just like <t>, but what Julian is asking for is that it be treated just like <section>.
(Tony) thought <Tident> was originally a container to <t> (Paul) it was originally modeled to be parallel to <t> not a container for <t> (Tony) my preference is for not as a container
(Nevil) I like the <t> inside <tindent> better
(Julian) here you want to indent a sequence of paragraphs, but where you have a multiple of <Tindents> that doesn’t match the structure of the documents, so it would be better to be a container with a structure of paragraphs. If you want to indent a paragraph as artwork as monospace, how would you do that?
(Paul) we wouldn’t. Text + example and text+list are not currently model-able. Had considered those edge cases. We don’t have a way for people to indent now; what else would we want for people to be able to indent? Would it be for emphasis, or for de-emphasis? <Tindent> is very much formatting and not semantic. If you are trying to emphasize text, you are not also trying to emphasize the list or text within the text.
(Julian) can only speak to indents in my own docs; always use them for notes, where the note is text that doesn’t belong in the flow of the text but is more like a side-note. It is not part of the text flow of the paragraph. (Paul) in that case, having a container model would be reasonable, because those kind of thoughts might have an example involved. So, one possibility would be to replace <Tindent> with <aside> and say this will render as indented and be a container. (Julian) the question that would come up is every use where we indent a case where <aside> would be the wrong term for it? Not entirely sure.
(Paul) let’s try to go with aside for now, and if people scream, we have a second thing for emphasis. This is going to be rare, and the fact that people have to do things inside the container is inconvenient but possible. (Julian) if we need up with two different use cases, maybe they deserve two different elements for different output.
Xinclude
Can we use this everywhere? there may be some security issues with the draft processor accepting XML that has random Xincludes and src=. Will take this to the list, but we will likely need some serious restrictions on it. Xinclude is probably the right way to go, and we don’t want Xinclude and PI, and we can replace src with Xinclude, but there is a question about how this impacts references. If we say “use Xinclude” then the attributes for references are not needed. If people want to hang anchor names, run through the processor and have the processor expand them out and then change the anchor yourself, which would work for RFCs and I-Ds. This means the production center will have to check these again, but that should be fairly easy tooling.
(Tony) disagree in several areas on this.
(Julian) expect a lot of push back and will have to come up a different solution on renaming references; will work on that. Not just having a different anchor, but different anchor text displayed in the document. (Paul) we allow that now. (Julian) people will push back on editing the references, and there are reference names that people want to use that are not legal anchors. (Paul) that is a separate issue, but if you are willing to work on that, that would be great.
(Tony) pushing back on the comments against xml.resource.org; it is not as flakey as it used to be before Tools took it over. (Paul) talk about this offline. (Julian) would be better for the rfc-editor.org site to include the reference library for RFCs
Julian - consider v2 ready, so the only thing planning to do at this point, is adding more examples. If people want to review that and do a sanity check, that would be great.
Ran out of time - moving the following topics to the list
3. Review - are these statements correct?
- symbols for lists = “The XML just has primitives like “bulleted
list item” and one should be strongly discouraged (if not actively prevented from) using concrete characters.” and “in HTML the actual bullets are a CSS style”
- non-ASCII characters do NOT need special markup because detecting
them programmatically is trivial
4. AOB
- What will multiple-RFC STDs look like in XML? Or will it be a folder with the files? How would this end up rendering in the publication formats.
- UTF-8 characters in included references
