Watching this discussion I can see some points that I think that most reasonable people can agree on and I would like to suggest that these actually give us a pretty clear way forward as far as at least a first step goes.<div>
<br></div><div><i><b>Proposition 0:</b> The objective of having IDs and RFCs is to communicate information to readers. Format proposals should be judged on their effectiveness as a communication medium and the demands they impose on document producers</i></div>
<div><i><br></i></div><div>It is very easy to make a case for one particular format by choosing some bizarre corner case that begs the question. The purpose of RFCs is to communicate. A format that has a high overhead is going to be unacceptable as is a format that has a high probability of introducing unchecked errors.</div>
<div><br><br><i><b>Proposition 1:</b> It is reasonable for a participant to request the ability to read IDs and RFCs in a particular format.<br><b>Proposition 2:</b> It is utterly unreasonable for anyone to demand that others read IDs and RFCs in a particular format unless there are specific reasons why a particular format is necessary</i><br>
<br>Note that Proposition 1 does not mean that we necessarily have to support every format, just that it is reasonable to suggest support for traditional, HTML, PDF/A or whatnot.<br><br>The point I am making with Proposition 2 is that however much others may like traditional format, I am not going to read RFCs in it. I don&#39;t even review the plaintext format of the IDs I submit myself. I only ever look at the HTML output and that isn&#39;t up for negotiation as far as I am concerned.<br>
<br>The only good reason I can see for requiring a particular format is when the nature of a draft is such that a particular format is inadequate. I do not want people to be required to produce plaintext versions of drafts dealing with I18N. That is a total waste of time in my view. If support for I18N email addresses is important then so is support for I18N in the documents describing them. <br>
<br>We can debate whether the demands of people who insist on traditional format are more important than (say) an author who wants the document to actually present their name correctly but it is certainly a &#39;specific reason&#39;. <br>
<br>I find the arguments about &#39;Canonical&#39; format to be total nonsense. As far as IETF tradition goes, the standard has always been set by bits on the wire rather than the documents. In 20 years of being involved in IETF, I have never once come across a situation where the presentation format of a document introduced an ambiguity. And in the highly unlikely case that it ever did, a new document would be required in any case. The document that is most likely to be considered &#39;authoritative&#39; today would be the XML2RFC input.<br>
<br><br><i><b>Proposition 3:</b> How to support included files (images, source code) should be considered separately from whether to support them</i><br><br>The reason for this is that the option space for how to support included files is much larger and more complex than the option space for whether to do so. We can argue over different image file formats (PNG, JPEG, Vector) at considerable length but none of that has the slightest impact on the question of how to upload them to the editing system or how to view them. Any content we decide to support is going to have an associated MIME type (and quite likely a file extension).<div>
<br></div><div>Another reason to avoid having the discussion of what included formats to support is that everyone fights over images while what is actually most important is actually included code and examples. People can argue over whether ASCII art is useful or not. Arguing over whether it is useful to be able to extract an XML schema file from a Web Services standard is ridiculous. Of course it is useful to be able to pull the schema from a specification in a single mouseclick. Doing so reduces the likelihood of error.<br>
<br>The biggest challenge in developing a toolset for included files is going to be how to upload them to the site. But that problem stems from the fact that we don&#39;t actually have good tools for managing collections of documents as a single entity. I can see several possible approaches: mime archives (mhtml), zip archives, Paul&#39;s suggestion. This is going to be tricky but it probably does not need to concern us till we get to writing code.</div>
<div><br><br><i><b>Proposition 4: </b>XML2RFC MUST continue to be supported as an input format<br><b>Proposition 5: </b>HTML MUST be supported as an output format</i></div><div><i><b>Proposition 6: </b>HTML output SHOULD use a restricted set of HTML features.</i><i><br>
<b>Proposition 7:</b> HTML is capable of serving as both an input format and an output format</i><br><br>I think proposition 4 is self-evident. There is a considerable investment in the XML2RFC format. Even if additional input formats are supported it is going to be necessary to support XML2RFC for legacy.</div>
<div><br></div><div>Proposition 5 is just a statement of the obvious as far as I am concerned. HTML is the ONLY format supported on a wide range of devices. Try reading &#39;plaintext&#39; and you will find that the browser transforms it into HTML for display. People could argue for additional formats (like continued support for ASCII) but HTML is now at least as embedded as ASCII. There is more information in HTML today than any other format. Pretending that HTML cannot meet the needs of the IETF is just silly.</div>
<div><br></div><div>But even though HTML is inevitable, the full HTML feature set is not. And in particular we are going to want conventions that enable a common IETF style sheet to be applied.</div><div><br></div><div>Proposition 7 is a simple statement of fact. </div>
<div><br></div><div>If these propositions are accepted, I think we can arrive at a subset of the eventual system that is almost certainly inevitable:</div><div><br></div><div><b>1) A profile of HTML for use in RFCs and IDs</b>. This would specify permitted tags, required metadata and class identifiers to be applied so that the document displays correctly with the associated stylesheet. It MUST be possible to roundtrip information from the HTML profile to the XML2RFC format and back.</div>
<div><br></div><div>1a) Extend XML2RFC as necessary to avoid unnecessary loss of data.</div><div><br></div><div><b>2) Stylesheets</b> for IETF, ISOC, etc documents.</div><div><br></div><div><b>3) Modify the existing XML2RFC</b> toolchain to generate the new HTML format</div>
<div><br></div><div><b>4) HTML2RFC tool.</b> This would perform nits checking and be capable of generating the corresponding XML2RFC file.</div><div><br></div><div><b>5) Modify the publication Web</b> site so that the HTML versions of the drafts are visible alongside the traditional format, pdf etc.</div>
<div><br></div><div><b>6) Modify the submission tool</b> so that ALL that is required to submit a draft is to provide either the XML2RFC format or the HTML format (or the traditional format)</div><div><br></div><div>I don&#39;t think any of these are particularly complex for what I suggest. In fact I think that my proposal above is pretty much the minimum that we could do.</div>
<div><br></div><div>I may be able to help on 4. I already have a toolchain that I use to develop drafts which can probably be modified. It is in C# but this can be made to run on Mono without much difficulty. If someone could show me how to make plug-ins work in Visual Studio I could produce a tool whose results were quite literally &#39;awesome&#39;. Unfortunately I have a com issue that keeps tripping me up.</div>
<div><br></div><div><br></div><div>What this proposal does not address is:</div><div><br></div><div><b>1) How traditional format would continue to be supported. </b></div><div><br></div><div>For example, how to deal with documents that cannot be represented in that format. Should there be a new I18N version of the format? What if the only part that cannot be represented correctly is the author&#39;s name?</div>
<div><br></div><div>I think that this is something that can be left to the advocates of traditional format to decide. But what is not acceptable is for all possibility of progress to be determined by what is possible in traditional format. If we have a document that is giving security advice to developers of application user interfaces, that document is going to have examples of user interfaces or be worthless. In that particular case, the plaintext version of the document should probably just state that the HTML version needs to be consulted.</div>
<div><br></div><div><b><u>The scope of activities of the IETF should not be determined by the capabilities of the RFC format.</u></b></div><div><br></div><div><b>2) How to manage included files.</b></div><div><br></div><div>
This is actually the hardest part when it comes to dealing with images and source. I think that the easiest approach in practice is likely to be to use MHTML format. This is widely supported by browsers, at least on the desktop. so one way I could submit a document with included images as a draft would be to bring it up in my browser, then select, &#39;save as MHTML&#39; and submit the saved file. That is clunky but not much more so than usual.</div>
<div><br></div><div>I think that in practice it is going to be more useful to have a nits tool that can be run by the document author on their own machine that would have &#39;submit&#39; as one of the options. For such a tool to be useful to me it would have to be a self contained executable and not something that requires a separate framework to be compiled and installed first.</div>
<div><br></div><div><b>3) What included file formats to support and with what options.</b></div><div><br></div><div>I think that this is something that is going to require an ongoing process to manage. In particular we are going to need to decide on specific criteria for adopting a new format. What options are permitted, validation tools, etc.</div>
<div><br></div><div>Some formats that we would require are pretty obvious:</div><div><br></div><div>Image:  JPEG, PNG, HTML Vector</div><div>Code: ABNF, DNS, XML Schema, ASN.1</div><div><br></div><div>But the mere fact that a format is obvious does not mean how to implement it is. To get the full value from this exercise we should be defining nits for each of the included formats, deploying validation tools, etc. etc.</div>
<div><br></div><div><br></div><div><br></div><div><br><br><br>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br></div></div>