RFC Format BoF (IETF 84) 31 July 2012 Chairs: Heather Flanagan (RSE), Nevil Brownlee (ISE) Text from the slides is not necessarily repeated. 0) RFC Format: the short version (Heather Flanagan) ------------------------------------------------------------------------- slides: http://www.ietf.org/proceedings/84/slides/slides-84-rfcform-4.pdf - RFC 6635 and The Process - Requirements See http://www.rfc-editor.org/rse/wiki/doku.php?id=formatreq - Issues, concerns, and rebuttals Summary: http://www.rfc-editor.org/rse/wiki/doku.php?id=formatsummary - Focus on what's missing - The drafts - Agenda 1) RFC Image Appendices: A Very Conservative Approach (John Klensin) ------------------------------------------------------------------------- document: draft-rfc-image-files-03 slides: http://www.ietf.org/proceedings/84/slides/slides-84-rfcform-3.pdf - Fundamentals - Proposal (updated from 2008 version): Extend the ASCII Model - Getting from Here to There Requires Questions/Comments J. Levine: What about non-ASCII text? J. Klensin: Not allowed. Mentioned indexing problem. General problem is guaranteeing rendering. For non-ASCII txt, if you can't render it, you see rows of boxes and question marks. If you can render it, but can't read the script, then what's the value. The accessibilty norm is that we can all read Latin chars. J. Hildebrand: A few things from the list. It's nice to have ability to copy & paste (e.g., security alg). Boxes and question marks are different; the latter can be fixed. Boxes needs parameters. 2) HTML for RFCs (Joe Hildebrand) ------------------------------------------------------------------------- document: draft-hildebrand-html-rfc-2012-07-07.html slides: http://www.ietf.org/proceedings/84/slides/slides-84-rfcform-2.pdf - Background for draft-hildebrand-html-rfc - Applicability - HTML Meta-Data - CSS Queries - CSS Query Example - Tooling - Edit Experience - Open Topic: How much HTML5? - HTML vs. other formats Questions/Comments Y. Stein: Re: HTML as input format, syntax seems harder than XML. Re: HTML as output format, why do you think this is a good idea? J. Hildebrand: Nice to have the same doc that I'm using as a human be machine-queryable, so that 2 representations don't have to be kept in sync. Two consumers of output format: humans and scripts. J. Klensin: The query method has been grep. There are ways to continue using grep. If you're working w/ generic markup language (HTML or XML), then you can make anything into anything else. But need a canonical format, which we can sign and use for legal. J. Hildebrand: Do you want to grep the canonical format? J. Klensin: Yes. L. Masinter: Output format is also the input format. Look at other SDOs and see what they're doing (PDF/A, HTML). C. Jennings: W3C accepts simplified HTML as input, then runs tools to make more complicated HTML (inserting links, indexing, etc.). What is broken there: different versions are not diffable. Excellent diffs are needed. J. Hildebrand: I was careful about this. Check out the github diffs. R. Callon: Re: "Do we use HTML5 or HTML4.01?" Would that question have made sense 2 years ago? What about in 20 years? I'm nervous. 3) A proposal for RFC formats and process (Paul Hoffman) ------------------------------------------------------------------------- document: draft-hoffman-rfcformat-canon-others-03 slides: http://www.ietf.org/proceedings/84/slides/slides-84-rfcform-0.pdf - It's a short draft - Canonical format "Start with xml2rfc, but make a bunch of improvements" - Other formats that will be published - Making it better for RFC readers - Input to the RFC series - XML vs. HTML, my view Open mic L. Masinter: It's a struggle to use XML even for a simple document. T. Bray: You should read Paul's draft. Agree w/ Paul's draft, but prefer HTML. For XML, currently 2 tools: TCL and .xslt [Editor's note: xml2rfc v2 is written in Python.] Against improving xml2rfc b/c it's a waste of time. Questioning the longevity of HTML is not a real issue. P. Hallam-Baker: Agree w/ Paul except for a few things. Canonical XML is a good thing. XML over HTML is a big win. We don't want to rev this every time W3C decides to do something w/ HTML. We need to have 2 canonical formats: one that's structured data that represents the document, and one canonical presentation format for other applications (e.g., legal). Could be PDF/A. A. Sullivan: Paul, you said it's a feature that there are multiple input formats and the RFC Editor does magic. Why is that a feature? P. Hoffman: Enable different people (including valuable contributors to the series) to create I-Ds however they would like. H. Levkowetz: Major point is we need the canonical format to contain metadata. HTML vs. XML, either way it won't be lossy - can go back and forth. J. Hildebrand: There could be other sorts of authoring formats, and a limited set that the RFC Editor uses. The tools could provide that flexibility. The question is whether the submitted format can be used as input later. D. Crocker: Been talking about how we could do X or Y; should be talking about what are viable changes to make to the existing operation. We don't have a clean slate, so we shouldn't be having a 'clean slate' discussion. T. Hardie: Agree w/ Phill (Hallam-Baker). More than one canonical output format. How bout audio on an LP. P. Hoffman: Phill's idea should be discussed.