RFC Format BoF
Thursday, 7 November 2013, 1730 - 1830 PST

Agenda:  http://www.ietf.org/proceedings/88/agenda/agenda-88-rfcform
Slides:  http://www.ietf.org/proceedings/88/slides/slides-88-rfcform-0.pdf
Wiki: https://www.rfc-editor.org/rse/wiki/doku.php?id=design:start

Chair:  Heather Flanagan
Jabber Scribe:  Peter Saint-Andre and  Minute Taker:  Karen O'Donoghue

RFC Format Design Team has been working since IETF #87: 
Nevil Brownlee (ISE), Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler

1. Reminder: the announcement in May indicated several things
    a. the canonical format  we are exploring for RFCs is XML
    b. four publication formats will be created from that XML: HTML, EPUB, text and PDF
    c. non-ASCII characters would be allowed in a controlled fashion

2. A RFC format design team was put together during IETF 87 in Berlin to clear up the details implied by those statements.  

3. Current status of that work:
    a. In-progress: documenting the current vocabulary and description of the current xml2rfc DTD up to date and drafting the proposed changes going forward 
    b. In Progress: requirements for the HTML and text formats 
    c. Agreement in principle to include non-ASCII characters in RFCs
    d. A high level work flow for how the tool will be used in production by authors and the RFC Editor
    e. In progress: details around the use of images

4. Next steps:
    a. Finish the xml2rfc v2 and v3 descriptions and requirements
    b. Finish draft-hildebrand-html-rfc
    c. Create the RFP to start on the specs, followed by the development phase
    d. Discuss what, if any, changes should be phased in versus a formal cut-over
    e. Discuss how this affects the submission process and I-D format

Expected Questions: 
1. What about how things look and feel?
2. How will non-ASCII characters be handled? 

Open Mic: 

Keith Moore:  Why is the pdf based on the plain-text version? There are issues about type face size and line length. PDF could be based on a variable text format. 

Heather: It made sense at the time. Still looking for an example. 

Paul Hoffman: The thought was pdf is for people who tend to print, and those are the ascii people. 

Chris Newman: I assume the SVG profile will prevent all the security problems that are present in SVG. Raw SVG supports Java script. 

Paul Hoffman: Since it is no longer xml2rfc we should call it something else. 

Brian Weis: SVG graphics sounds exciting. Do I also need to provide ascii art?
Heather: No, there will be a link out, and authors will be encouraged to put in a text description. 
Brian Weis: If I wanted to include both is that possible?
Heather:  Yes
Brian Weiss: If there is mistake which one is the right one. 
Heather: We are still talking about errata and our processes for that. 

Wes George: Whether the input is text or xml, we don't have a user friendly document generation process for authors. We have no tools that make this simple. Authors should use XML unless they have a good reason not to. There needs to be a set of requirements around what the authoring toolset looks like.  
Heather: This is a consistent input that she has received many times. She doesn't control the tools. A draft to start the discussion might be useful. 
Wes George: I can help with that. 

Henrik: PDF question, I would find it incredibly sad that the potentially richest format would be hobbled to the text format. PDF should be publication quality. 

Tony Hansen:  We do need to have examples of all the formats being generated. 
Addressing Paul's comment on xml2rfc name change, it is difference between the canonical format and being a format. 

Larry Masinter: Regarding PDF, there are pdf profiles in particular one called PDF-A. 

Yoav Nir: Suppose there is ascii art, is that going into all the formats? 
HF: Yes

Mark Nottingham: Regarding tools, we should not have one mandated tool. Regarding line lengths and type formats, we don't know enough to be talking about typesetting in this forum. We should leave it to the experts. 

Yoshiro Yoneya: Will the format distinguish between different variants of Chinese and Japanese character sets. 

PHB:  Main sticking point is for the people who don't generate their text using XML. I have a tool on sourceforge called rfctool, and I'm looking for users to try it out. 

W3C is reconsidering their document format as well. When you are thinking about charter formats and profiles, you might want to have a conversation with them. 

Joe Hildebrand: Regarding PDF, we will have continuing discussions on that topic. Don't fear - yet! On the SVG, we are going with tinySVG minus a bunch of features that looked scary.  Our goal is to have as small a list as possible. There will be options for submission, but if you submit in ascii it may delay your submission for translation to XML. Internationalization issues will mostly be a negotiation between the author and the RFC editor with wide discretion given to the author. Regarding CSS, we are focusing on the tags that are going into the xml itself. 

Mark Nottingham:  Because we have an interchange format that provides additional options, we need to make sure the legal situation is clear. 

Keith Moore:  Where there are disputes between the versions, the XML is canonical. We picked a canonical format that isn't exactly readable or writable. It may be the best choice but I find it interesting. Is the text format meant to be ascii only?

Heather (and others):  UTF-8

Elwyn Davis: What about equations?  
Heather: That is still under consideration. There is some thought to do mathematical equations in SVG. This seems doable but not perfect. Please post ideas on how to handle equations to the list. 

Larry Masinter: When I edit rfcs in xml, I pretty print the xml. Maybe that might be part of the RFC editor process. It might be useful. 

Phillip Hallam-Baker:  Regarding Keith's point, any decision we make here will have no impact on the potential result of a lawsuit. It won't matter what we say is canonical. Reason won't enter into it. 

Julian Reschke:  This is not a new format. There are years of experience with it. The math equations question is a good question. Might want to consider png. 

Brian Weis: Have you checked with IETF counsel regarding previous appeals and the impact of canonical impact. 

Heather: I've checked with IETF counsel, and I've also talked to OASIS who publish their standards in multiple formats. 

John Levine: I have a question about the canonical format. If we discover bugs in the generated publication formations, would we rerun the tools? 
Heather: I'm hesitant to do that. This might fall under the errata process. 

Henrik: The proposed parts of the text format are strictly limited. 

Paul Hoffman:  Understand that the design team is not unanimous on these topics. People are still thinking about this, and things are still changing. 

Keith Moore: Just to be clear, I think this is mostly really good. 

Links from the jabber room:

http://asciitex.sourceforge.net/
http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf
http://cursive.net/draft-hildebrand-html-rfc.html
http://www.mathjax.org/demos/mathml-samples/