Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Jul 13, 2009, at 7:58 PM, Doug Ewell wrote: Why on Earth would someone use Visual Basic within Word to write a utility to convert Microsoft Word ***XML*** documents to an IETF- acceptable format, when there are much better tools for processing XML? For a third-party application to interpret the changing Word document format, even in XML form, would require extensive and ongoing support. This support would go well beyond what is currently needed to interpret the simpler xml2rfc structures. Using Word input files alone is likely to represent an effort few could afford to support. Why would someone not specifically write such a utility to ignore or reject any Word document containing executable code? Use of the bundled program language that operates at an object level can hide underlying format changes and avoid the related support effort. Using the bundled programming language likely represents the _only_ practical method for directly utilizing Word input files, as was suggested. IMHO, this was a logical conclusion. This, on the other hand, from Iljitsch van Beijnum iljitsch at muada dot com: This solves the problem that converting anything else into XML2RFC a reverse lossy process: XML2RFC needs more than what other formats can supply so automatic conversion (from, for instance, Word) is impossible. is a genuinely useful and productive counterargument against the whole word2rfc concept. Disagree. The goal would be to generate RFC and ID documents. Requiring XML2RFC intermediaries negates the benefit of using Word. Beyond security concerns related to relying upon the bundled program language, not having this feature supported in OSX or Unix represents yet another concern. Iljitsch view of XML2RFC intermediaries is not practical, but Word2rfc is not impossible when the bundled program language is used. It can be done, but it would not be wise. On Jul 13, 2009, at 1:10 PM, Julian Reschke wrote: The experimental version (http://xml.resource.org/ experimental.html) is as stable as predecessor versions; the main reason it hasn't been released is that the authors (IMHO) expected more boilerplate changes to occur. And what exactly do you mean by cryptic entries? There was little documentation for what would satisfy the nit checker a few months ago. It was a challenge to know what was needed for the rfc structure. The needed ipr parameter appeared rather cryptic. I think the right approach is to either help maintaining the TCL code, or to rewrite xml2rfc in a different language. To support the generation of MHTML, as some have suggested, the logical intermediary format seems to be XSLT (for defining xml2rfc constructs). http://tools.ietf.org/html/rfc2557 http://people.dsv.su.se/~jpalme/ietf/mhtml.html IMHO, pre-processors with roff might offer simpler and cleaner inputs, especially for the vision impaired. A post process could then generate simpler MHTML formats. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Doug Otis wrote: ... On Jul 13, 2009, at 1:10 PM, Julian Reschke wrote: The experimental version (http://xml.resource.org/experimental.html) is as stable as predecessor versions; the main reason it hasn't been released is that the authors (IMHO) expected more boilerplate changes to occur. And what exactly do you mean by cryptic entries? There was little documentation for what would satisfy the nit checker a few months ago. It was a challenge to know what was needed for the rfc structure. The needed ipr parameter appeared rather cryptic. ... Well, the @ipr value needs to capture several dimensions, such as type of IPR *and* time scale (because the IETF rules keep changing). Of course the values could be made less cryptic, but this seems to be something of a bike shed discussion, as long as the values a well documented. I think the right approach is to either help maintaining the TCL code, or to rewrite xml2rfc in a different language. To support the generation of MHTML, as some have suggested, the logical intermediary format seems to be XSLT (for defining xml2rfc constructs). We have that already (xml2rfc-XSLT-(X)HTML), in case you didn't notice. http://tools.ietf.org/html/rfc2557 http://people.dsv.su.se/~jpalme/ietf/mhtml.html IMHO, pre-processors with roff might offer simpler and cleaner inputs, especially for the vision impaired. A post process could then generate simpler MHTML formats. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 14 jul 2009, at 11:20, Doug Otis wrote: For a third-party application to interpret the changing Word document format, even in XML form, would require extensive and ongoing support. In principle, yes. In practice this would probably not be a huge deal compared to what needs to happen to conform to new ideas from the lawyers. Obviously Microsoft didn't come up with an XML file format and then push it through standardization to do all of that again a few years from now. We can expect the format to be extended, but the basic stuff will probably remain the same for a long time. (And we only need the REALLY basic stuff here!) This solves the problem that converting anything else into XML2RFC a reverse lossy process: XML2RFC needs more than what other formats can supply so automatic conversion (from, for instance, Word) is impossible. is a genuinely useful and productive counterargument against the whole word2rfc concept. Disagree. The goal would be to generate RFC and ID documents. Directly from .docx files? Requiring XML2RFC intermediaries negates the benefit of using Word. I disagree. If it were possible to generate XML2RFC format from Word format that would be extremely useful, because that way people who can work with Word can generate XML2RFC that can then be used by people who work in that format, including the RFC editor. But as I've said before, the semantic markup in XML2RFC makes it impossible to create a working XML2RFC file from an input that doesn't have the same semantic markup. Although tagging semantics can probably be a bit more pleasant in a WYSIWYG tool than in XML source, it still has all the documentation and version breaking issues that XML2RFC has, so that doesn't really buy us much. Iljitsch view of XML2RFC intermediaries is not practical, but Word2rfc is not impossible when the bundled program language is used. I was talking about a new intermediate format. What I'm thinking of is a constrained HTML. HTML can be used both as input and output in word processors and text editors with only minimal extra steps, if any. A lot of those generate atrocious HTML, but this can easily be fixed by removing everything that doesn't conform to the constraints. Converting from XML2RFC format to HTML would be lossy, so converting in the other direction would entail some manual work. But for the basic text in the middle a 1-to-1 mapping would be possible, which would help a lot. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Jul 12, 2009, at 4:42 PM, Doug Ewell wrote: This thread has been headed down the wrong path from the outset, as soon as Tony Hain wrote on July 1: An alternative would be for some xml expert to fix xml2rfc to parse through the xml output of Word. If that happened, then the configuration options described in RFC 3285 would allow for wysiwyg editing, and I would update 3285 to reflect the xml output process. I realize that is a vendor specific option, but it happens to be a widely available one. I modified that, along the course of the thread, to suggest that a separate word2rfc tool might be a more sensible option. To the extent the .doc format is highly flexible -- which isn't really true anyway; it's been rather stable since 1997, and the new XML-based format is called .docx -- I can see that as an obstacle for someone writing such a conversion tool. But I challenge anyone to find the slightest suggestion in this thread that we should publish IETF documents directly in Word format. Let's at least argue the same point, folks. These concerns took your concept to a logical conclusion. Notice the definition for sttbListNames in: http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx Logically, rather than modifying TCL xml2rfc code to interpret xml2rfc structures embedded within Word structures, Visual Basic would represent a more likely tool, since it is already supported by the Word application. To view this support, double click a control in Design Mode, and see Word open a Visual Basic editor. Visual Basic provides access to ActiveX routines, where in 2007, additional content based routines along with custom XML storage for its binary format had been added. Although placing controls directly into a Word document is not the norm (prints as a graphic), these controls can generate RFC compliant outputs, and even bibliographic XML fragments to assist in the generation of the bibliographic sections. No TCL code would be needed.A less risky alternative to that of Word might be to use Java with Open Office. From the IETF perspective, in addition to the ASCII text files being used as the archived form, xml2rfc files are retained to generate alternative presentations and as input for generation process. The concern related to the use of the Word input format, which has changed in 97, 00, 02, 03, 07, and is likely again in 10, remains that of security. Changes are not always apparent, and even format documentation can not be relied upon when details related to active components are ill defined. The security concern is in regard to the embedded program language, especially when the program is to be relied upon as the means to generate IETF compliant outputs. The Internet is not a safe place, where a practice of embedding programs that can cause harm into what could have been innocuous text should be considered a bad practice. Currently, collaboration between individuals might be accomplished by sharing xml2rfc input files, which are also retained with the plain text RFC output. Reliance upon Word input files as a replacement for xml2rfc files will invariably lead to a bad practice of depending upon potentially harmful embedded programs. Use of xml2rfc conversions has uncovered some odd quirks. The tool does not cache bibliographic database selections. Either this works on-line, or the entire database needs to be local. Not to diminish the service offered by Carl Malamud, occasional sporadic connections to the xml.resource.org servers can be a cause of angst for authors who have not obtained the entire tarred xml bibliographic database. Lately, the dependability of the xml2rfc approach has become less reliable when dealing with cryptic entries and beta TCL needed to generate I-D boilerplate language as required by nit checker. This makes one wonder whether there could be a better way. A hybrid approach might offer the similar features found in xml2rfc with the simpler the inputs supported by 'roff. This would not exclude the use of Word, but would not depend upon any of Word's content automations. Perhaps a bit of Perl could provide the pre and post processors to handle something that resembles the xml2rfc front section. While roff is not perfect, it has been more stable than other WISIWYG word processors and, when used in conjunction with separate pre/post processors, can generate the desired alternative outputs. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 13 jul 2009, at 21:56, Douglas Otis wrote: Visual Basic would represent a more likely tool, since it is already supported by the Word application. Only in some versions. In the latest MacOS version it's not supported. This makes one wonder whether there could be a better way. I think a better way would be to create a new intermediate format that can both be an input to generate XML2RFC code _to_ as XML2RFC code _from_, as well as HTML and the current RFC archival format. This solves the problem that converting anything else into XML2RFC a reverse lossy process: XML2RFC needs more than what other formats can supply so automatic conversion (from, for instance, Word) is impossible. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Douglas Otis wrote: ... Use of xml2rfc conversions has uncovered some odd quirks. The tool does not cache bibliographic database selections. Either this works on-line, or the entire database needs to be local. Not to diminish the service offered by Carl Malamud, occasional sporadic connections to the xml.resource.org servers can be a cause of angst for authors who have ... If it hurts, don't do it. Translation: if you don't want to rely on network resources, keep a local copy. I recommend that anyway, so that the xml2rfc input file is self-contained. Relying on external references for internet drafts is fragile anyway: that the reference automatically updates to the latest version may look handy, but may cause authors to miss important changes. ... not obtained the entire tarred xml bibliographic database. Lately, the dependability of the xml2rfc approach has become less reliable when dealing with cryptic entries and beta TCL needed to generate I-D boilerplate language as required by nit checker. ... The experimental version (http://xml.resource.org/experimental.html) is as stable as predecessor versions; the main reason it hasn't been released is that the authors (IMHO) expected more boilerplate changes to occur. And what exactly do you mean by cryptic entries? This makes one wonder whether there could be a better way. A hybrid approach might offer the similar features found in xml2rfc with the simpler the inputs supported by 'roff. This would not exclude the use of Word, but would not depend upon any of Word's content automations. Perhaps a bit of Perl could provide the pre and post processors to handle something that resembles the xml2rfc front section. While roff is not perfect, it has been more stable than other WISIWYG word processors and, when used in conjunction with separate pre/post processors, can generate the desired alternative outputs. I think the right approach is to either help maintaining the TCL code, or to rewrite xml2rfc in a different language. BR; Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Well one approach would be to simply write a spec for using MIME as an archive format for HTML and associated documents as has been supported in Internet Explorer for a decade. MHT is a very simple format that uses IETF standards in a very obvious way. We could probably get Firefox to add support just by asking. Another approach would be to use vector graphics markup which is XML for the diagrams. Another would be to simply stick with the ASCII art. On Thu, Jul 2, 2009 at 11:05 AM, Stewart Bryantstbry...@cisco.com wrote: Tim Bray wrote: On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnumiljit...@muada.com wrote: A much better solution would be HTML, if it's sufficiently constrained. HTML allows for the reflowing of text, solving issues with text and screen sizes. It's also extremely widely implemented, so it's easy to display reasonably well without special tools. It also allows for semantic tagging, allowing for easy scraping. This seems obviously true everywhere outside the IETF mailing list. The showstopper has always been with figures which need to do in separate files. How do you manipulate the collection of files as a single object? At least with pdf you know you have the whole thing. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Douglas Otis dotis at mail dash abuse dot org wrote: ... The concern related to the use of the Word input format, which has changed in 97, 00, 02, 03, 07, and is likely again in 10, remains that of security. Changes are not always apparent, and even format documentation can not be relied upon when details related to active components are ill defined. The security concern is in regard to the embedded program language, especially when the program is to be relied upon as the means to generate IETF compliant outputs. The Internet is not a safe place, where a practice of embedding programs that can cause harm into what could have been innocuous text should be considered a bad practice. Currently, collaboration between individuals might be accomplished by sharing xml2rfc input files, which are also retained with the plain text RFC output. Reliance upon Word input files as a replacement for xml2rfc files will invariably lead to a bad practice of depending upon potentially harmful embedded programs. OK, I've had just about enough of this fearmongering. Why on Earth would someone use Visual Basic within Word to write a utility to convert Microsoft Word ***XML*** documents to an IETF-acceptable format, when there are much better tools for processing XML? Why would someone not specifically write such a utility to ignore or reject any Word document containing executable code? Are we that stupid? Based on the logic I am reading here, I should stop writing code in Visual Studio because it could be used to create a worm or virus, should stop turning on my computer because the box could be used to beat someone over the head, should stop driving my car to work in the morning because someone could crash it into a preschool. We shouldn't try to stop people from using every tool that could potentially, theoretically, be misused or used intentionally for evil. I use Word almost every day and I haven't encountered a macro virus for years, probably because I don't open e-mail attachments from unknown senders and don't visit MySpaceCoolAddOns.com, and have also learned to walk upright. I don't plan to respond further to this thread because it is obviously going nowhere. This, on the other hand, from Iljitsch van Beijnum iljitsch at muada dot com: This solves the problem that converting anything else into XML2RFC a reverse lossy process: XML2RFC needs more than what other formats can supply so automatic conversion (from, for instance, Word) is impossible. is a genuinely useful and productive counterargument against the whole word2rfc concept. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
I just *knew* it was a mistake to Leave this thread for later ... On 3 Jul 2009, at 18:04, Pete Resnick wrote: On 7/3/09 at 10:16 AM +0200, Iljitsch van Beijnum wrote: On 3 jul 2009, at 0:35, Pete Resnick wrote: A much better solution would be HTML, if it's sufficiently constrained. Or, gee, we could generalize to a very constrained XML format XML isn't a display format. And how is this responsive to what I said? Applications of XML (e.g., XHTML, xml2rfc with associated XSL files) provide perfectly good display info that are currently in use by all sorts of display platforms. The choice of a particular markup language is irrelevant to the overall issue: We need to have text and semantic markup, instead of text with spaces and control characters to do page formatting as our canonical format. Hmm. Generalisation is good. Semantic markup is also good. But ASCII has a good standing and a thoroughly good reason for being, and probably continuing to be, a canonical format. We are at nobody's mercy. Now, I'm not for disputing the usefulness of XML or whatever other format becomes popular. For HTML, for example, my screen reader has keystrokes to jump to the next heading, or to list them for me to select. I would want whatever we choose as the alternative markup stored in the same repository, and to have the same chances of being used as the ASCII by those who need preprocessed output, for whatever purpose, on whatever device. I think this is somewhat optimistic, though; either it creates more work for people who have quite enough to do already just writing this stuff, else it precludes many existing and perfectly good historical documents whose chance of conversion to other formats now are somewhat limited by, for example, wishwash in the current format variations. On the other hand, as a writer I am not exactly enamoured by the choices available. I just want to write. I'm blind; without my £5000 (sorry, l5000 :-) ) braille display on hand, and without brltty on Linux, I cannot feel my way around the document; get the indentations right, the line count right, the line width right. And even if I could, it's very tiresome. xml2rfc does peculiar things all of its own; even as a Tcl lover I'm not happy with its weird tendency to add extra whitespace where it shouldn't be, or to make bold assumptions about the author's ecstatic desire to write perfect XML, or the somewhat less semantic HTML it generates, or ... I just want to write, straight long lines, one a paragraph, with YAML-style section delimiters, no boilerplate. All that pretty-printing is someone else's problem, I just want to put an idea into a starting-point draft. So I'd be much gratified if somebody could, or could give me the encouragement to, write such a scheme up and then code it, probably in Tcl. As Dave put it, the current RFC format is unfriendly, unnecessary, possibly unethical and just plain wrong. I'd remove the possibly. Please elaborate; this statement goes far beyond the inconvenience of having fixed line and page breaks and the lack of non-7-bit- ASCII characters. You bet it goes further: The current format is a horror to anyone who has to read the document on anything that does not visually display 80 columns of fixed-width text. Try reading the text on a small handheld device. Try doing so with a text-to-speech application. Try magnifying it using apps meant for folks with limited vision. We have the ability to create text in a format that is easily interpreted by all of these devices and presented to the user with no loss of information. Using a page-layout format for our standards when page layout is completely unnecessary is at a minimum unfriendly to folks who want to use such devices, and (given that it is unnecessary to use page-layout) it is downright unethical and wrong to make it harder for folks who must use such devices. Wo! Brave assumptions! For me, ASCII is *why* I read IETF standards, almost in preference to other organisations. Clean, one-spec-a-file, consistent naming, can be further preprocessed if desired (as above: to an extent), 7-bit for display using all known braille codes on all braille displays. Truly, as I've said, ASCII is a splendid lowest-common-denominator choice of format. About the only hindrance for text-to-speech and braille alike is the headers and footers; they make no sense even on common textmode terminals, interrupt the perfect flow of speech for no reason, and are just annoyingly redundant. Remove those, and I think we have a perfect ASCII representation. Not being able to use characters in documents outside of the US- ASCII set is inconvenient (when they are part of the data stream of a protocol you wish to describe) and unfriendly (when the personal information about contributors cannot be properly provided). I'll leave off
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Doug Ewell d...@ewellic.org writes: Douglas Otis dotis at mail dash abuse dot org wrote: Reliance upon open source tools ensures the original RFCs and ID can be maintained by others, without confronting unresolvable compatibility issues. Whether a tool is open source or not has nothing to do with how many people know how to use it. Are you talking about maintainability of the documents or of the tools? It would also be a bad practice to rely upon unstable proprietary formats having limited OS support and significant security issues. Oh, stop. Word 2007 can read and save Word 97 documents. Applications for Windows, which has a 90% to 93% desktop market share, can hardly be said to suffer from limited OS support. And turning off macros is becoming more and more common among Word users; it's even a separate non-default document format under Word 2007. I know The Penguin doesn't like the fact that Word is closed-source, but -- like the multiple discussions being lumped under RFC archival format -- we need to separate that issue from questions of whether the app is any good. And if we're talking about an author using Word (or TextPad or roff or whatever) to pre-process a file into an RFC Editor-friendly format, which can then be converted to traditional RFC text or HTML or PDF or something, then isn't the horror of using Word limited to that author? Doug, Already, above, Douglas pointed out for your comments correctly. RFC format is different from a market share format by the purpose. Do you have been think about the word compatibility and standard? Here is IETF, not a market.. ;; Sincerely, -- Byung-Hee HWANG, KNU ∑ WWW: http://izb.knu.ac.kr/~bh/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Byung-Hee HWANG bh at izb dot knu dot ac dot kr wrote: Already, above, Douglas pointed out for your comments correctly. RFC format is different from a market share format by the purpose. Do you have been think about the word compatibility and standard? Here is IETF, not a market.. ;; This thread has been headed down the wrong path from the outset, as soon as Tony Hain wrote on July 1: An alternative would be for some xml expert to fix xml2rfc to parse through the xml output of Word. If that happened, then the configuration options described in RFC 3285 would allow for wysiwyg editing, and I would update 3285 to reflect the xml output process. I realize that is a vendor specific option, but it happens to be a widely available one. and Douglas replied by going off on Word: Word's closed code is continuously changing. Availability of this closed application depends upon OS compatibility and version regressions. Both are moving targets. In addition, Word formats permit inclusion of potentially destructive scripts within highly flexible and obfuscating structures. Nobody in this thread has suggested publishing RFCs or distributing I-Ds in any native Microsoft Word format. The only thing Tony suggested was to fix xml2rfc to convert XML documents generated by Word into the standard format for RFCs and I-Ds, just as xml2rfc already converts XML documents written in the RFC 2629(bis) format into the standard format for RFCs and I-Ds. I modified that, along the course of the thread, to suggest that a separate word2rfc tool might be a more sensible option. To the extent the .doc format is highly flexible -- which isn't really true anyway; it's been rather stable since 1997, and the new XML-based format is called .docx -- I can see that as an obstacle for someone writing such a conversion tool. But I challenge anyone to find the slightest suggestion in this thread that we should publish IETF documents directly in Word format. Let's at least argue the same point, folks. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Jul 3, 2009, at 08:07, Doug Ewell wrote: As always when this discussion occurs, there are at least three different issues swirling around: 1. ASCII-only vs. UTF-8 2. Plain text vs. higher-level formatting, for text flow and readability 3. Whether it is a good idea to include high-quality pictures in RFCs There are not the same issue, and it would help combatants on both sides not to mix them up. I admire the attempt to separate these issues into orthogonal concerns, but I don't think it can succeed. The common aspect of all these issues is the question of whether our archival format should A) continue to be limited to a string of ASCII characters formatted for printing with a fixed-width font, or B) if it should be expanded to include a document archival format that can preserve font, style and figures. There is a related but separable topic of discussion once option B) is open for debate: what precisely should be the set of primary natural languages used in IETF documents? Should it continue to be English only? I'd very much prefer to see *that* discussion vigorously deferred while our archival format continues to be the largest practical obstacle to multilingualism. I believe there are no reasonable candidates for archival formats that can preserve font, style and figures without also providing for localization. I don't know where the argument don't help authors prepare I-Ds using the tools of their choice, unless they are open-source fits into this picture. Compared to the previous two issues, this one is just not so much important. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Hi, You're heading into new territory, here. Right now IETF documents are written in English and they're If you allow a bit of nitpicking here: they cannot be written in all the labels the English language has to offer, and thus they can only be written in a *subset* of English. So a devil's advocate (which I absolutely don't mind playing here) could say that the restriction to ASCII *prevents* expressing oneself in the full bouquet of English language; unfortunately, English language is mandatory for IETF documents. So, staying with ASCII would require a reformulation for IETF language from English to English words which can be expressed in ASCII encoding Example? Naïve is a perfectly valid English word. (If your mail reader doesn't display this correctly: that's an i with two dots on top instead of one) Likewise is coup d'état an English word (e with accent). All loan words from French, but nontheless English words. http://en.wikipedia.org/wiki/Naive http://en.wikipedia.org/wiki/Coup_d%27Etat At least the first one has been used in an I-D from the IAB very recently (http://www.ietf.org/internet-drafts/draft-iab-idn-encoding-00.txt). It used the alternative spelling with a normal i; the other spelling was obviously impossible for the reasons we are discussing in (parts of) this thread. Maybe the author wanted to use that alternative spelling anyway, but maybe he was forced to use it even though it hurt his eye and he is now drowning in grief over the butchering of language he was forced to execute in order to publish his work. We will never know for sure; unless of course the author tells us about his feelings on this list :-) Let's give ASCII its long-overdue coup de grâce ( http://en.wikipedia.org/wiki/Coup_de_grace ). Greetings, Stefan Winter displayable on a wider variety of hardware than HTML is. As I mentioned in the mail to which you're responding, I think the choice of formats tends to support more openness and accessibility. I think you're implicitly arguing that that's not the right tradeoff, and frankly I think it's exactly the right tradeoff, myself. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RFC archival format, was: Re: More liberal draft formatting standards required
Naïve is a perfectly valid English word. (If your mail reader doesn't display this correctly: that's an i with two dots on top instead of one) Likewise is coup d'état an English word (e with accent). All loan words from French, but nontheless English words. Yes, but in importing such words into English, we're perfectly happy to strip off the decorations that you mention. For example, when I look up naïve in Webster's New Universal Unabridged Dictionary (a large book, not an online service) it lists both the decorated and undecorated versions, with the undecorated version appearing first, indicating the more common usage. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
--On Tuesday, July 07, 2009 23:01 +0200 Iljitsch van Beijnum iljit...@muada.com wrote: ... (We have a saying in Dutch: the soup is never eaten quite as hot as it is served = people are generally more reasonable than their intial positions suggest.) Experience with the recurrence of this particular topic over the years suggests that this particular soup retains its temperature, and perhaps becomes hotter, the longer it circulates around the table. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
--On Sunday, July 05, 2009 12:05 -0400 Melinda Shore melinda.sh...@gmail.com wrote: ... You're heading into new territory, here. Right now IETF documents are written in English and they're displayable on a wider variety of hardware than HTML is. As I mentioned in the mail to which you're responding, I think the choice of formats tends to support more openness and accessibility. I think you're implicitly arguing that that's not the right tradeoff, and frankly I think it's exactly the right tradeoff, myself. Agreed. I also find it fairly disturbing that we cannot seem to have any discussion at all about RFC content, format, or methods of production without also opening up and rehashing all of the questions of: * Why RFC's should not be published in Lower Slobbovian? * Why the native RFC character set cannot be EBCDIC-32? * Whether pictures are, or are not, better than text? * Whether it is more important to optimize for passive readability on, e.g., objects with small screens or for searching, extraction, and editing? * Whether someone's favorite tool for aiding in the production of documents should be made mandatory or prohibited entirely as a source of evil? and so on. The questions, or at least a subset of them, are important. But we never manage to reach consensus, partially I think because we make different assumptions about what is important, and that wastes a lot of time. Worse, these floods of discussions tend to drive out small but useful improvements by overwhelming any meaningful discussion of the proposed changes themselves. Sad. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 7 jul 2009, at 12:25, John C Klensin wrote: The questions, or at least a subset of them, are important. But we never manage to reach consensus, partially I think because we make different assumptions about what is important, and that wastes a lot of time. If we really want to make progress here it's not going to happen by reaching rough consensus after a long discussion, but by a (very) small group of people getting together and coming up with something that improves upon the current situation for (pretty much) everyone, rather than optimize for one particular way to interpret the state of the universe. The good thing is that the current situation leaves so much to be desired that this should actually be doable. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Iljitsch van Beijnum iljitsch at muada dot com wrote: If we really want to make progress here it's not going to happen by reaching rough consensus after a long discussion, but by a (very) small group of people getting together and coming up with something that improves upon the current situation for (pretty much) everyone, rather than optimize for one particular way to interpret the state of the universe. But as John pointed out, this isn't going to happen unless that group can focus on what the current situation refers to, and try to solve one problem at a time, and stop pretending that ASCII vs. Unicode and fixed vs. floating line breaks and ASCII art vs. bitmapped/vector graphics and which tool is best are all the same issue. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
--On Tuesday, July 07, 2009 12:49 +0200 Iljitsch van Beijnum iljit...@muada.com wrote: If we really want to make progress here it's not going to happen by reaching rough consensus after a long discussion, but by a (very) small group of people getting together and coming up with something that improves upon the current situation for (pretty much) everyone, rather than optimize for one particular way to interpret the state of the universe. The good thing is that the current situation leaves so much to be desired that this should actually be doable. I do not believe that we can reach agreement on even the last statement. I think this discussion shows that our starting assumptions about what is important, about how to count (pretty much) everyone, etc., are divergent enough to make an effective process like the one you outline unlikely. You believe that xml2rfc needs to be eliminated, some believe that it should be made mandatory, others of us believe that it is an extremely useful tool for those who use it (although it could be improved) but that requiring it to the exclusion of other tools would be a mistake. Similarly, some of us believe that a plain ASCII format with directly-encoded hard line endings is extremely stable as well as extremely suitable for direct search and extraction of material (e.g., by copy-and-paste operations). We do not see those as being properties of more sophisticated alternatives unless tools that are specifically matched to those alternatives are available (and maybe not then). We draw some comfort from the facts that it does not have to be interpreted by programs for display, that it converts to UTF-32 by simple bit padding and to UTF-8 by doing nothing, and that there is exactly one way to represent all of the characters it can represent. Again, other systems, even native UTF-8, do not have that property (in the latter case because there is more than one way to represent the same character, at least prior to normalization). Others either accept those considerations or not, but believe that other considerations are more important. They may be right, but, again, I don't see any way in which we are going to reach agreement that those changes would improve things for almost everyone. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 7 jul 2009, at 22:42, John C Klensin wrote: The good thing is that the current situation leaves so much to be desired that this should actually be doable. I do not believe that we can reach agreement on even the last statement. I think this discussion shows that our starting assumptions about what is important, about how to count (pretty much) everyone, etc., are divergent enough to make an effective process like the one you outline unlikely. The points that you make in the rest of your message are mostly valid, but I think they can be addressed by showing people that if we take a few steps in the right direction, they at least get something that is better than today, so most people would be at least somewhat happy with that. I truly believe it can be done, and I'd be happy to take the time to make a start in Stockholm if anyone else is prepared to invest time. (We have a saying in Dutch: the soup is never eaten quite as hot as it is served = people are generally more reasonable than their intial positions suggest.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Tue, Jul 7, 2009 at 1:42 PM, John C Klensinjohn-i...@jck.com wrote: I do not believe that we can reach agreement on even the last statement. I am afraid that you may be correct. I am flabbergasted that consensus on the superior usability of HTML over IETF legacy plain-text (all other related issues aside) seems unlikely, but apparently there are a large number whose experience of online information differs dramatically from the people I hang out with. Similarly, some of us believe that a plain ASCII format with directly-encoded hard line endings is extremely stable as well as extremely suitable for direct search and extraction of material (e.g., by copy-and-paste operations). As to copy-and-paste, your statement is probably not a majority viewpoint. A high proportion of my copy-and-pastes are either into something that'll be delivered via browser (the line-ends silently vanish) or in an email (where they cause unpredictable breakage depending on the settings of my email authoring and the recipient's email reading software. We draw some comfort from the facts that it does not have to be interpreted by programs for display, I really hope you didn't mean what that sentence apparently says. No file may be displayed without the invention of one or more computer programs. I think that what you're saying is that IETF legacy plain-text displays correctly in a terminal emulator (and incorrectly in a browser). This is clearly correct but many of us feel that correct display in a browser is of higher utility to a greater number of potential spec users. -T ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RFC archival format, was: Re: More liberal draft formatting standards required
This is clearly correct but many of us feel that correct display in a browser is of higher utility to a greater number of potential spec users. This seems to follow the currently popular all the world is a browser philosophy. I actually prefer plain-text for lots of uses, including email. I haven't yet heard any *compelling* arguments against the use of plain-text (ASCII or UTF-8) as the default and normative representation format for RFCs. Arguments, yes; *compelling* arguments, no. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RFC archival format, was: Re: More liberal draft formatting standards required
OK, here is what happens on my netbook using your method. Original 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length |R|T| Transport flags | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What I see : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ | Type |L ength |R|T| Transpor t flags | Res | +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Sun, 2009-07-05, Yaakov Stein wrote: OK, here is what happens on my netbook using your method. Original 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length |R|T| Transport flags | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What I see : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ | Type |L ength |R|T| Transpor t flags | Res | +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ What sort of editable input, handled by what sort of presentation mechanism, would solve this case? And, if it involves horizontal scrolling and/or zooming in or out, why wouldn't that also handle plain text, too? -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 6 jul 2009, at 8:53, Yaakov Stein wrote: OK, here is what happens on my netbook using your method. What I see : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ Hm, it's not supposed to break lines between pre and /pre even if they don't fit on the screen... Obviously ASCII art is created with screen / paper size assumptions built in. I never claimed I was able to get around that. My claim was that it was possible to create an HTML-ized form of the RFC format that would both be valid HTML and could be turned back into the well- known plain ASCII format by simply removing the HTML tags. Due to the difficulties in making good graphics and the issue of having a single RFC span multiple files in the case of HTML format with graphics I think we should stick with ASCII art in the general case even if we move to HTML as the archival format. But packet layout diagrams can be made with HTML tables, which would make them a little more flexible than ASCII art but on a really tiny screen those still wouldn't display very well. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Tim Bray wrote: On Sun, Jul 5, 2009 at 9:05 AM, Melinda Shoremelinda.sh...@gmail.com wrote: You're heading into new territory, here. No, I disagreed with an unqualified assertion you made using the extremely well-defined termASCII. Sure, you are. You're implying that there are characters we want to display that can't be done within the current constraints. I don't think that the second part of your assertion is correct. I'm not trying to be difficult. I introduce by example the huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all. I've never run into a device that can't display ASCII at all (if it can display HTML it can display plain ASCII), but have used and owned a large number of devices that can't display HTML. Plus, there appears to be a certain amount of whimsy involved with rendering HTML and displays can be inconsistent, which 1) is one of the complaints about the current format, and 2) is undesirable for the display of technical specifications. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Melinda Shore wrote: ... I don't think that the second part of your assertion is correct. I'm not trying to be difficult. I introduce by example the huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all. I've never run into a device that can't display ASCII at all (if it can display HTML it can display plain ASCII), but Some EBook readers, as far as I recall, display XHTML fine, but do not display plain text. And even if they do, you will encounter the line wrap problem. have used and owned a large number of devices that can't display HTML. Plus, there appears to be a certain amount of whimsy involved with rendering HTML and displays can be inconsistent, which 1) is one of the complaints about the current format, and 2) is undesirable for the display of technical specifications. ... Of course that depends on the type of HTML we would use. For instance, if you get inconsistent results with the HTML my XSLT variant of xml2rfc produces, please let me know (example: http://greenbytes.de/tech/webdav/rfc2616.html). BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 6 jul 2009, at 12:08, Melinda Shore wrote: Plus, there appears to be a certain amount of whimsy involved with rendering HTML and displays can be inconsistent, which 1) is one of the complaints about the current format, and 2) is undesirable for the display of technical specifications. I disagree with 2. Today, drafts and RFCs have a fixed format, that should render the same on all displays and in print (barring font differences, but I guess Courier is assumed). Although this format isn't particularly pretty and current mainstream tools can no longer create it, this format has a lot going for it: - pretty much everything that can classified as a computing device can display it natively - should the need arise to write an implementation for display software from scratch, that would be extremely trivial - no issues with copy/paste - compatible with lots of tools However, it has one big issue: it doesn't adapt to the properties of the display gracefully. (Or at all, really.) This is the part that would be easy to fix by adopting a very basic flavor of HTML. This would give us line wrap and the ability to use tables, but we'd lose the headers/footers. ASCII art could still be used as preformatted text. This type of basic HTML will render slightly differently on different implementations, but that's the point. Unless technical meaning is encoded in spaces and line breaks, this shouldn't matter. And even in basic HTML, it's possible to add class specifications etc that allow tools to apply more intelligence than would be possible with plain text. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Iljitsch van Beijnum wrote: ... This is the part that would be easy to fix by adopting a very basic flavor of HTML. This would give us line wrap and the ability to use tables, but we'd lose the headers/footers. ASCII art could still be used ... Headers/footers will work just fine with a HTML client that supports the CSS3 paged media extensions; for now that's only PrinceXML (http://www.princexml.com/), but it's a start. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all HTML is a good presentation format, but as an archival format it seems to leave a lot to be desired, as the included links always seem to go stale. Also, I don't think that the notions of page numbers and table of contents have quite reached the status of quaint and archaic. large number of standard office printers that print HTML instantly and correctly My experiences printing HTML docs are a bit different, I guess. Is there no tool that will html-ize an RFC or i-d for presentation? Folks who want to read RFCs on their cell phones should be able to do it, but I really don't see what that has to do with archival formats. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Eric Rosen wrote: huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all HTML is a good presentation format, but as an archival format it seems to leave a lot to be desired, as the included links always seem to go stale. ... But that's a problem of the link targets, not the document format, right? large number of standard office printers that print HTML instantly and correctly My experiences printing HTML docs are a bit different, I guess. In generic, or HTML as produced by tools.ietf.org, xml2rfc, or rfc2629.xslt? ... BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Jul 3, 2009, at 3:16 PM, Doug Ewell wrote: Douglas Otis dotis at mail dash abuse dot org wrote: Reliance upon open source tools ensures the original RFCs and ID can be maintained by others, without confronting unresolvable compatibility issues. Whether a tool is open source or not has nothing to do with how many people know how to use it. Are you talking about maintainability of the documents or of the tools? The concern is about the application accepting document instructions and text and then generating document output. When this application is proprietary, it is prone to change where remedies might become expensive or impossible. The evolution in hardware tends to force the use of different operating systems which may no longer support older applications. IIRC, I did work back in the early 90's that contained Russian written using Word 5. Conversion proved difficult since proprietary fonts were needed. Document recovery then required a fair amount of work to rediscover the structure and character mapping. Trying to get any version of Word to generate plain text outputs consistently always seemed to be a PITA, that varied from version to version, and never seemed worth the effort. It would also be a bad practice to rely upon unstable proprietary formats having limited OS support and significant security issues. Oh, stop. Word 2007 can read and save Word 97 documents. Instead of 10 years, go back another 5 years. When people are required to input Word Document instructions into their Word application, they might become exposed to system security issues as well. The variability of the Word data structures makes identifying security threats fairly difficult, where many missing features seem to be an intended imposition as a means to necessitate use of the vendor's macro language. Inherent security issues alone should disqualify use of proprietary applications. Applications for Windows, which has a 90% to 93% desktop market share, can hardly be said to suffer from limited OS support. When support is almost exclusively Windows, this still represents limited support. It would be sending the wrong message to mandate the use of proprietary operating systems or applications in order to participate in IETF efforts. After all, lax security often found within proprietary operating systems and applications threatens the Internet. And turning off macros is becoming more and more common among Word users; it's even a separate non-default document format under Word 2007. The many automation features fulfilled by TCL and xml2rfc will likely be attempted with the native word processor scripts. The latest Word, if you can afford it, is almost ISO/IEC 29500:2008 Office Open XML compliant. Perhaps Word will be compliant in its 2010 version. :^( I know The Penguin doesn't like the fact that Word is closed-source, but -- like the multiple discussions being lumped under RFC archival format -- we need to separate that issue from questions of whether the app is any good. And if we're talking about an author using Word (or TextPad or roff or whatever) to pre-process a file into an RFC Editor-friendly format, which can then be converted to traditional RFC text or HTML or PDF or something, then isn't the horror of using Word limited to that author? Open source includes more than just Linux, and the exposure of requiring proprietary applications or operating systems would affect nearly all IETF participants that maintain existing documents or generating new ones. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RFC archival format, was: Re: More liberal draft formatting standards required
Last but not least, just filter out anything between and and replace a few xxx; sequences and you're back to plain text. We could probably even format RFCs such that if you remove the HTML, you're left with the current ASCII format. You seemed to have missed the point. Almost all RFCs have ASCII art in them, and although perhaps not absolutely needed for correct implementation they are necessary to comprehend the document. When you improperly break lines these figures are irreversibly corrupted, and in essence you lose a large part of the document. In fact, you lose exactly the same information that you would lose were we to standardize some other format that embeds characters without compression and merely pull the ASCII characters out. So if you object to using a non-ASCII format because it will not be 100% readable 30 years from now, you should object to using the present format today. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Yaakov Stein wrote: You seemed to have missed the point. Almost all RFCs have ASCII art in them, and although perhaps not absolutely needed for correct implementation they are necessary to comprehend the document. When you improperly break lines these figures are irreversibly corrupted, and in essence you lose a large part of the document. In fact, you lose exactly the same information that you would lose were we to standardize some other format that embeds characters without compression and merely pull the ASCII characters out. So if you object to using a non-ASCII format because it will not be 100% readable 30 years from now, you should object to using the present format today. I agree that ascii artwork has its limitations but I find this hyperbolic and consequently unhelpful. First, I don't think that diagrams are necessary to understand most documents, although they can be helpful and I think the documents should be written with comprehensibility in mind - reading them should not be a reminder that without suffering there is no growth. But I think the documents that are completely incomprehensible without the diagrams they contain are rare. Maybe someone could identify examples if they're that common. Second, I don't know what irreversibly corrupted means in this context. Even though there can be issues with trying to display them in a proportionate font or on a narrow screen, I'm not sure how you can claim that they're irreversibly corrupted since the documents aren't corrupted at all, just hard to read. It's a display issue, and I think you're overstating your case. Right now ascii text is probably the most widely-supported display format. It seems to me that the priority has been openness and universal accessibility, and that's what's behind the choices that have been made. It may be appropriate to trade away a little bit of that accessibility for documents that some people find easier to read, although I think that would be a tough choice to make. But I hope that as the discussion continues (and continues and continues and continues and continues) the broader, organizational goals are kept in mind. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 5 jul 2009, at 15:04, Yaakov Stein wrote: Last but not least, just filter out anything between and and replace a few xxx; sequences and you're back to plain text. We could probably even format RFCs such that if you remove the HTML, you're left with the current ASCII format. You seemed to have missed the point. Almost all RFCs have ASCII art in them, [...] When you improperly break lines these figures are irreversibly corrupted, and in essence you lose a large part of the document. No, you're missing my point. That point is that a file like this: pIn order to be able to use the largest packet sizes under the widest range of circumstances, nodes SHOULD include a new MTU option in both neighbor solicitation and neighbor advertisement messages RFC2461./p pThe format of the neighbor discovery MTU option is as follows:/p pre 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length |R|T| Transport flags | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /pre Will display as follows if you remove everything between and (inclusive): In order to be able to use the largest packet sizes under the widest range of circumstances, nodes SHOULD include a new MTU option in both neighbor solicitation and neighbor advertisement messages RFC2461 The format of the neighbor discovery MTU option is as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length |R|T| Transport flags | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here are links to the examples in case they get lost in the mail: http://www.bgpexpert.com/drafthtml.txt http://www.bgpexpert.com/drafthtml.html http://www.bgpexpert.com/drafthtmlfiltered.txt So if you object to using a non-ASCII format because it will not be 100% readable 30 years from now, you should object to using the present format today. Wasn't that what I was doing? On 5 jul 2009, at 15:12, Yaakov Stein wrote: I personally started writing up a description of a packet loss concealment technique, but had to give up due to the formulas not being transcribable (I had no problem submitting a patent application instead). In TICTOC we are not even considering attempting any work that needs math, but rather leave it to other SDOs. It is considered a limitation of the system. So once those standards are published somehwere else, what kind of language do you use to implement them that allows mathematical formulas to be part of the code? In other words: anything that can be expressed in math symbols can also expressed in ASCII, programmers have been doing that for half a century. Annyoing, but it does have the advantage that once you have it in that format you don't have to worry about strange incompatibilities that make the symbols come out wrong. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Sun, Jul 5, 2009 at 6:27 AM, Melinda Shoremelinda.sh...@gmail.com wrote: Right now ascii text is probably the most widely-supported display format. This statement is violently counter-intuitive and shouldn't be accepted unsupported by evidence. - ASCII is not usable for the languages of a large majority of the world's population. - For electronic consumption of texts longer than SMS messages, HTML is the most widely-used display format, probably followed by PDF. - For print consumption, the use of modern typographic techniques - real quotation marks, dashes, accented characters if only for usages like café and coöperate - is generally seen as required, so ASCII is very seldom used. ASCII-only is a primitive leftover from the typographically-impoverished dawn of computing. Can we get over it already? -T ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Tim Bray wrote: On Sun, Jul 5, 2009 at 6:27 AM, Melinda Shoremelinda.sh...@gmail.com wrote: Right now ascii text is probably the most widely-supported display format. This statement is violently counter-intuitive and shouldn't be accepted unsupported by evidence. - ASCII is not usable for the languages of a large majority of the world's population. - For electronic consumption of texts longer than SMS messages, HTML is the most widely-used display format, probably followed by PDF. - For print consumption, the use of modern typographic techniques - real quotation marks, dashes, accented characters if only for usages like café and coöperate - is generally seen as required, so ASCII is very seldom used. ASCII-only is a primitive leftover from the typographically-impoverished dawn of computing. Can we get over it already? You're heading into new territory, here. Right now IETF documents are written in English and they're displayable on a wider variety of hardware than HTML is. As I mentioned in the mail to which you're responding, I think the choice of formats tends to support more openness and accessibility. I think you're implicitly arguing that that's not the right tradeoff, and frankly I think it's exactly the right tradeoff, myself. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Tim Bray tbray at textuality dot com wrote: Right now ascii text is probably the most widely-supported display format. - ASCII is not usable for the languages of a large majority of the world's population. I suspect Melinda meant to say plain text, and wasn't intending to mix up the ASCII vs. Unicode debate with the plain vs. formatted text debate. I predict people will continue to combine the character-encoding issue, the formatted-text issue, the pretty-pictures issue, and the document-creation issue into one big amorphous blob, significantly extending the length of time it will take to agree upon and solve any of these problems. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Sun, Jul 5, 2009 at 9:05 AM, Melinda Shoremelinda.sh...@gmail.com wrote: You're heading into new territory, here. No, I disagreed with an unqualified assertion you made using the extremely well-defined termASCII. As others have pointed out, progress is being impeded by the conflation of a bunch of different issues, so let's try and be careful about our assertions. Right now IETF documents are written in English and they're displayable on a wider variety of hardware than HTML is. I don't think that the second part of your assertion is correct. I'm not trying to be difficult. I introduce by example the huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all. Also, the large number of standard office printers that print HTML instantly and correctly at the touch of control- or command-P, but can render IETF legacy ASCII on paper only with various gyrations and sidesteps. As I mentioned in the mail to which you're responding, I think the choice of formats tends to support more openness and accessibility. I think you're implicitly arguing that that's not the right tradeoff, and frankly I think it's exactly the right tradeoff, myself. I think that we're in agreement as to objectives: openness, accessibility, and usability. My claim is that a carefully considered and constrained flavor of HTML would meet those objectives better than IETF legacy ASCII. I claim that this is true exclusive of whatever consensus develops around the issues of i18n and the introduction of graphics. (There may be a disagreement in that I would tend to place more weight than some others on the needs of spec consumers compared to those of producers.) -Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Tim Bray tbray at textuality dot com wrote: I don't think that the second part of your assertion is correct. I'm not trying to be difficult. I introduce by example the huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all. Also, the large number of standard office printers that print HTML instantly and correctly at the touch of control- or command-P, but can render IETF legacy ASCII on paper only with various gyrations and sidesteps. I'd still be more confident that the differences between the issues were understood if the above text read IETF legacy plain-text instead of IETF legacy ASCII. If we moved from ASCII to UTF-8 tomorrow, but otherwise kept the current plain-text format with its lines separated by CRLF and its pages separated by FF, and all of the other rigid formatting constraints, the same complaints about plain-text versus HTML would exist. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Sun, Jul 5, 2009 at 9:02 PM, Doug Ewelld...@ewellic.org wrote: Tim Bray tbray at textuality dot com wrote: I introduce by example the huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all. Also, the large number of standard office printers that print HTML instantly and correctly at the touch of control- or command-P, but can render IETF legacy ASCII on paper only with various gyrations and sidesteps. I'd still be more confident that the differences between the issues were understood if the above text read IETF legacy plain-text instead of IETF legacy ASCII. You're entirely correct, and my poor phrasing is less forgiveable because I was just giving Melissa a hard time for her assertions about ASCII. Sorry. If we moved from ASCII to UTF-8 tomorrow, but otherwise kept the current plain-text format with its lines separated by CRLF and its pages separated by FF, and all of the other rigid formatting constraints, the same complaints about plain-text versus HTML would exist. Right. As many have pointed out here, there are three separate issues here: 1. Usability 1.a Reader usability 1.b Author usability 2. Internationalization 3. Graphics My argument is that 1.a. and 2. would be dramatically improved by the introduction of HTML, while 1.b. would not on average change much across the universe of I-D authors. And that 3 is a less urgent issue than 1 and 2. -Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 3 jul 2009, at 0:35, Pete Resnick wrote: A much better solution would be HTML, if it's sufficiently constrained. Or, gee, we could generalize to a very constrained XML format XML isn't a display format. As Dave put it, the current RFC format is unfriendly, unnecessary, possibly unethical and just plain wrong. I'd remove the possibly. Please elaborate; this statement goes far beyond the inconvenience of having fixed line and page breaks and the lack of non-7-bit-ASCII characters. I wonder what people think about the need (or lack of need) to have graphical images. Having written a book or two, I can tell you that getting text right is hard, but this pales in comparison to the difficulty of getting images right. Most people, including myself, don't have the skills to create decent artwork. The formats are infinitely less open (in a variety of senses), so modifying someone else's images is extremely difficult unless you happen to use the same tools or go to the lowest common denominator = bitmaps. And images are of course impossible to use on text-only terminals. On constrained devices they're hard to work with because the text doesn't scale. So I think a good argument could be made that in general, RFCs shouldn't have images. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Iljitsch van Beijnum wrote: On 3 jul 2009, at 0:35, Pete Resnick wrote: A much better solution would be HTML, if it's sufficiently constrained. Or, gee, we could generalize to a very constrained XML format XML isn't a display format. As Dave put it, the current RFC format is unfriendly, unnecessary, possibly unethical and just plain wrong. I'd remove the possibly. Please elaborate; this statement goes far beyond the inconvenience of having fixed line and page breaks and the lack of non-7-bit-ASCII characters. I wonder what people think about the need (or lack of need) to have graphical images. Having written a book or two, I can tell you that getting text right is hard, but this pales in comparison to the difficulty of getting images right. Most people, including myself, don't have the skills to create decent artwork. The formats are infinitely less open (in a variety of senses), so modifying someone else's images is extremely difficult unless you happen to use the same tools or go to the lowest common denominator = bitmaps. And images are of course impossible to use on text-only terminals. On constrained devices they're hard to work with because the text doesn't scale. So I think a good argument could be made that in general, RFCs shouldn't have images. That is an author centric view. It is far more important to take a reader centric view. Do we have any objective information on what format produced the clearest information transfer in the reader. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 3 jul 2009, at 13:13, Stewart Bryant wrote: That is an author centric view. It is far more important to take a reader centric view. Do we have any objective information on what format produced the clearest information transfer in the reader. Well, readers can't read what authors can't produce. Perhaps a good image trumps good text, but I don't think we can assume that this is the choice we'll be faced with in general, mediocre image vs good text or bad image vs mediocre text seems more likely. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Iljitsch van Beijnum wrote: On 3 jul 2009, at 13:13, Stewart Bryant wrote: That is an author centric view. It is far more important to take a reader centric view. Do we have any objective information on what format produced the clearest information transfer in the reader. Well, readers can't read what authors can't produce. Perhaps a good image trumps good text, but I don't think we can assume that this is the choice we'll be faced with in general, mediocre image vs good text or bad image vs mediocre text seems more likely. Images of any quality do not excuse poor text. Producing good text is not negotiable and we have mechanisms in place to ensure the quality of the text. However it is our job to produce the most lucid description of the specification and I go back to my question, what format is most effective for the readers? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
As always when this discussion occurs, there are at least three different issues swirling around: 1. ASCII-only vs. UTF-8 2. Plain text vs. higher-level formatting, for text flow and readability 3. Whether it is a good idea to include high-quality pictures in RFCs There are not the same issue, and it would help combatants on both sides not to mix them up. I don't know where the argument don't help authors prepare I-Ds using the tools of their choice, unless they are open-source fits into this picture. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Stewart Bryant stbry...@cisco.com wrote: That is an author centric view. It is far more important to take a reader centric view. I must dissent. Reader-centric views belong to publishing entities that generate income (whether by purchase, subscription, or advertising). There have always been book publishers that generate reader-centric interpretations of RFCs. It's expensive to do so; and such publishing entities are careful to evaluate the potential market before producing one. IETF publications produce _no_ income; so we need to minimize the expenses. That leaves us concentrating on the author-centric and editor-centric views. I in no way dispute that other presentations can be better for the reader; I only remind folks that we subsidize IETF publications through our meeting fees, and other avenues are always available to publish reader-centric versions. For one simple example, I know of nothing preventing citations of self-published guides as Informative References in RFCs. -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 7/3/09 at 10:16 AM +0200, Iljitsch van Beijnum wrote: On 3 jul 2009, at 0:35, Pete Resnick wrote: A much better solution would be HTML, if it's sufficiently constrained. Or, gee, we could generalize to a very constrained XML format XML isn't a display format. And how is this responsive to what I said? Applications of XML (e.g., XHTML, xml2rfc with associated XSL files) provide perfectly good display info that are currently in use by all sorts of display platforms. The choice of a particular markup language is irrelevant to the overall issue: We need to have text and semantic markup, instead of text with spaces and control characters to do page formatting as our canonical format. As Dave put it, the current RFC format is unfriendly, unnecessary, possibly unethical and just plain wrong. I'd remove the possibly. Please elaborate; this statement goes far beyond the inconvenience of having fixed line and page breaks and the lack of non-7-bit-ASCII characters. You bet it goes further: The current format is a horror to anyone who has to read the document on anything that does not visually display 80 columns of fixed-width text. Try reading the text on a small handheld device. Try doing so with a text-to-speech application. Try magnifying it using apps meant for folks with limited vision. We have the ability to create text in a format that is easily interpreted by all of these devices and presented to the user with no loss of information. Using a page-layout format for our standards when page layout is completely unnecessary is at a minimum unfriendly to folks who want to use such devices, and (given that it is unnecessary to use page-layout) it is downright unethical and wrong to make it harder for folks who must use such devices. Not being able to use characters in documents outside of the US-ASCII set is inconvenient (when they are part of the data stream of a protocol you wish to describe) and unfriendly (when the personal information about contributors cannot be properly provided). I'll leave off unethical there; it's still wrong. I wonder what people think about the need (or lack of need) to have graphical images. Images are *way* down the list of needs. Useful in some cases, but never necessary. Getting rid of a page-layout format as our authoritative form is primary. Using characters that do not occur in English is next down the list. Everything else is extra. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
John Leslie wrote: Stewart Bryant stbry...@cisco.com wrote: That is an author centric view. It is far more important to take a reader centric view. I must dissent. Reader-centric views belong to publishing entities that generate income (whether by purchase, subscription, or advertising). There have always been book publishers that generate reader-centric interpretations of RFCs. It's expensive to do so; and such publishing entities are careful to evaluate the potential market before producing one. IETF publications produce _no_ income; so we need to minimize the expenses. That leaves us concentrating on the author-centric and editor-centric views. I in no way dispute that other presentations can be better for the reader; I only remind folks that we subsidize IETF publications through our meeting fees, and other avenues are always available to publish reader-centric versions. For one simple example, I know of nothing preventing citations of self-published guides as Informative References in RFCs. Ah. I thought we wrote RFCs so that others could read them and translate the content into some locally meaningful combination of hardware and software. If that is not the case I wonder why we spend our time writing them? My overarching point of course is the style of an RFC should be so as to maximize the probability that the implementation is correct, and that the preference for style should be driven by that need. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Jul 3, 2009, at 8:07 AM, Doug Ewell wrote: As always when this discussion occurs, there are at least three different issues swirling around: 1. ASCII-only vs. UTF-8 2. Plain text vs. higher-level formatting, for text flow and readability 3. Whether it is a good idea to include high-quality pictures in RFCs There are not the same issue, and it would help combatants on both sides not to mix them up. I don't know where the argument don't help authors prepare I-Ds using the tools of their choice, unless they are open-source fits into this picture. Perhaps some of these difficulties can be remedied by allowing use of RFC 2223 with perhaps extensions by RFC 2346. What is missing are likely automation tools able to accept this original publication practice. This approach allowing postscript, html, and pdf output has not kept pace with the automation provided by the combination of TCL code and XML formats detailed in RFC 2629. If there is interest to revisit the use of roff and standardize preprocessors similar to that of xml2rfc, it should not take much effort to include these techniques as a means to extend what can be included within an ID and RFC. For this not to create too many problems, RFC 2223 should be updated. Reliance upon open source tools ensures the original RFCs and ID can be maintained by others, without confronting unresolvable compatibility issues. It would also be a bad practice to rely upon unstable proprietary formats having limited OS support and significant security issues. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Pete Getting rid of a page-layout format as our authoritative form is primary. Using characters that do not occur in English is next down the list. Everything else is extra. Surely maximizing the probability of correct understanding by the reader is primary. Everything else is just a mechanism. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Pete Resnick wrote: Getting rid of a page-layout format as our authoritative form is primary. Using characters that do not occur in English is next down the list. Everything else is extra. What is primary is to ensure that the revisable form can be easily read 30 years from now when the original display-creation software is lost. Making the revisable form be better than the simplistic ASCII we've used since 1969 is the second priority, not the first. I'm all in favor of satisfying that second priority, but remain concerned that enthusiasm for it loses sight of the importance of the first priority. This suggests that it is not quite enough to say xml or xml2rfc, but that we need to make sure the format of the submitted text is directly readable. This makes a distinction between readable and pretty. Pretty is quite helpful for easy reading. But only helpful. Any competent xml editing tool let's you create and save such a readable format, but we can't take that for granted. If we are going to change official requirements, we need them to mandate that the submitted version is as easily and directly readable as what we are giving up. That means, prior to running the file through an xml-savvy processor. So we need to specify formatting requirements for the revisable form. If we are going to move to something like xml2rfc as the official revision/submission format -- and I do hope we do -- we need to specify rules for the layout of the submitted files, so that those files can be comfortably read with a character-display program that is not knowledge of the revision structure. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Douglas Otis dotis at mail dash abuse dot org wrote: Reliance upon open source tools ensures the original RFCs and ID can be maintained by others, without confronting unresolvable compatibility issues. Whether a tool is open source or not has nothing to do with how many people know how to use it. Are you talking about maintainability of the documents or of the tools? It would also be a bad practice to rely upon unstable proprietary formats having limited OS support and significant security issues. Oh, stop. Word 2007 can read and save Word 97 documents. Applications for Windows, which has a 90% to 93% desktop market share, can hardly be said to suffer from limited OS support. And turning off macros is becoming more and more common among Word users; it's even a separate non-default document format under Word 2007. I know The Penguin doesn't like the fact that Word is closed-source, but -- like the multiple discussions being lumped under RFC archival format -- we need to separate that issue from questions of whether the app is any good. And if we're talking about an author using Word (or TextPad or roff or whatever) to pre-process a file into an RFC Editor-friendly format, which can then be converted to traditional RFC text or HTML or PDF or something, then isn't the horror of using Word limited to that author? -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnumiljit...@muada.com wrote: A much better solution would be HTML, if it's sufficiently constrained. HTML allows for the reflowing of text, solving issues with text and screen sizes. It's also extremely widely implemented, so it's easy to display reasonably well without special tools. It also allows for semantic tagging, allowing for easy scraping. This seems obviously true everywhere outside the IETF mailing list. Last but not least, just filter out anything between and and replace a few xxx; sequences and you're back to plain text. We could probably even format RFCs such that if you remove the HTML, you're left with the current ASCII format. Yes and no. Yes, removing markup leaves useful text, but no, it wouldn't be anything like the line-broken, paginated, headered-and-footered, legacy text format. -Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Tim Bray wrote: On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnumiljit...@muada.com wrote: A much better solution would be HTML, if it's sufficiently constrained. HTML allows for the reflowing of text, solving issues with text and screen sizes. It's also extremely widely implemented, so it's easy to display reasonably well without special tools. It also allows for semantic tagging, allowing for easy scraping. This seems obviously true everywhere outside the IETF mailing list. The showstopper has always been with figures which need to do in separate files. How do you manipulate the collection of files as a single object? At least with pdf you know you have the whole thing. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 2 jul 2009, at 17:05, Stewart Bryant wrote: A much better solution would be HTML This seems obviously true everywhere outside the IETF mailing list. The showstopper has always been with figures which need to do in separate files. How do you manipulate the collection of files as a single object? Multiple files seems problematic. However, we can stick with ASCII art even if we adopt HTML. ┏ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━━━┯━━━┓ ┃ An influx of a (hopefully limited) set │ of unicode symbols┃ ┃ could allow for more expressiveness in │ this area.┃ ┗ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━━━┷━━━┛___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Iljitsch, That box shows up as complete gibberish in a plain-text mail reader (pine in my case), which sort of proves the point about ASCII. What you sent was certainly not ASCII. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Thu, 2 Jul 2009, Iljitsch van Beijnum wrote: On 2 jul 2009, at 17:05, Stewart Bryant wrote: A much better solution would be HTML This seems obviously true everywhere outside the IETF mailing list. The showstopper has always been with figures which need to do in separate files. How do you manipulate the collection of files as a single object? Multiple files seems problematic. However, we can stick with ASCII art even if we adopt HTML. ??? ??? An influx of a (hopefully limited) set ??? of unicode symbols??? ??? could allow for more expressiveness in ??? this area.??? ??? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Iljitsch van Beijnum wrote: On 2 jul 2009, at 17:05, Stewart Bryant wrote: A much better solution would be HTML This seems obviously true everywhere outside the IETF mailing list. The showstopper has always been with figures which need to do in separate files. How do you manipulate the collection of files as a single object? Multiple files seems problematic. However, we can stick with ASCII art even if we adopt HTML. ... Indeed. Let's keep these discussions separate. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 7/2/09 at 4:05 PM +0100, Stewart Bryant wrote: Tim Bray wrote: On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnumiljit...@muada.com wrote: A much better solution would be HTML, if it's sufficiently constrained. Or, gee, we could generalize to a very constrained XML format.ohwait I certainly agree that some text-based markup with reasonable tools for folks like Dave Mills (and others) to easily convert to a readable (or listenable) format is absolutely essential. As Dave put it, the current RFC format is unfriendly, unnecessary, possibly unethical and just plain wrong. I'd remove the possibly. The showstopper has always been with figures which need to do in separate files. How do you manipulate the collection of files as a single object? At least with pdf you know you have the whole thing. We've actually got a standard for that: RFC 2387 and its brethren. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
