On Fri, May 25, 2012 at 8:46 AM, Phillip Hallam-Baker <span dir="ltr">&lt;<a href="mailto:hallam@gmail.com" target="_blank">hallam@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote><div><br>-1 The convenience and productivity of authors canít be ignored.† Itís a balancing act.<br>†</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<b>Proposition 1:</b> It is reasonable for a participant to request the ability to read IDs and RFCs in a particular format.<br><div><i><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>
</div></blockquote><div><br>meh - I donít think these propositions are useful in informing the discussion. <br>†</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<i><b>Proposition 3:</b> How to support included files (images, source code) should be considered separately from whether to support them</i><br></div></blockquote><div><br>-1. This is a cost/benefit analysis, nothing more.† In my case, since I think the benefit of adding images is very low, I would be opposed to any proposal where image provision imposed any significant costs on writer or reader.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><i><b>Proposition 4: </b>XML2RFC MUST continue to be supported as an input format<br>
</i></div></div></blockquote><div><br>+1<br>†</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><i><b>Proposition 5: </b>HTML MUST be supported as an output format</i></div>
</div></blockquote><div><br>+1<br>†</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><i><b>Proposition 6:†</b>HTML output SHOULD use a restricted set of HTML features.</i><i><br>
</i></div></div></blockquote><div><br>-1 - Iíd say MUST.† The thought of dealing with the full cruftiness of ďHTML as she are spokeĒ makes my blood run cold.<br>†</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div><i>
<b>Proposition 7:</b> HTML is capable of serving as both an input format and an output format</i></div></div></blockquote><div><br>Not qualified to comment. Iím perfectly comfy with authoring raw HTML, or xml2rfc input, in an Emacs buffer, but I worry that there are still a lot of people out there who blench at the thought of having to look at pointy brackets.<br>
†<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div><br></div><br><br><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></blockquote><div><br>Agreed on the subset, but Iím unconvinced that the round-tripping is practical.† Not saying I flatly disbelieve; just that it might be harder than you think.<br>†</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><b>2) Stylesheets</b> for IETF, ISOC, etc documents.</div></blockquote><div><br>+1 <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div><br></div><div><b>3) Modify the existing XML2RFC</b> toolchain to generate the new HTML format</div></div></blockquote><div><br>I suspect it will be about as easier to reimplement; and far easier to find someone to reimplement than to modify.<br>
†</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></blockquote><div><br>Unknown degree-of-difficulty<br>†</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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></blockquote><div><br>+1<br>†</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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></blockquote><div><br>+1<br>†</div>
<br></div>