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: More liberal draft formatting standards required
> To save time, I would suggest adopting the Patent Office rules on > Perpetual Motion. People advocating for a change to facilitate figures > (or to allow complicated math, such as tensor analysis) should have an > existence proof, i.e., a document that requires the change to be > published. (A document that left the IETF to be published elsewhere > for this reason would also do.) Marshall If I remember correctly, draft-ash-alt-formats gave such examples. G.805 diagrams were needed for some of the PWE and MPLS work, but could not be put in the desired format. 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. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Releasing xml2rfc 1.34pre3?
On Jul 3, 2009, at 19:49, Andrew Sullivan wrote: 1. The recent boilerplate/process-change events have resulted in a situation where the most-recommended tool for preparing IETF documents does not work at all in its stable version. To me, 1.34pre3 appears to be exactly as stable as 1.33 (modulo the instability inevitably introduced by the 5378 train wreck). Would it help to simply call it 1.34 now? (Then it would be picked up by distributions and packaging services such as macports, and people could stop installing by hand.) Release early, release often. Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
XML2RFC must die, was: Re: Two different threads - IETF Document Format
My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. On 4 jul 2009, at 13:27, John Levine wrote: I think it's reasonable to assume that going forward the vast majority of users who read online documents will be able to use software that can reformat them in various ways. This tells me that although the publication form has to be readable in a pinch as plain text, it's more important that it's amenable to mechanical processing. Tidily formatted xml2rfc would be a reasonable candidate No, it's not. The problem with XML2RFC formatted drafts and RFCs is that you can't display them reasonably without using XML2RFC, and although XML2RFC can run on many systems in theory, in practice it's very difficult to install and run successfully because it's written in TCL and many XML2RFC files depend on the local availability of references. When those aren't present the conversion fails. The philosophy behind XML2RFC is to encode meaning in the XML wherever possible, rather than simply display text. There are several problems with that: 1. It makes it hard to write source files, because now rather than type "Experimental" at the top of the file, I have to know what XML2RFC looks for to determine the draft's status. Same thing with boilerplate, references, etc. 2. It makes it hard to read source files for the same reason. You can't read an XML2RFC formatted XML file without prior knowledge and get all the information that would be displayed in the final draft/RFC format. 3. It gets it wrong. XML2RFC "knows" that you create a name from an initial, a period, a space and a last name. So initial "I" and last name "Van Beijnum" becomes "I. Van Beijnum". However, XML2RFC doesn't know that in Dutch, certain last name prefixes are capitalized if they appear at the beginning of the name (Van Beijnum) but not if they're in the middle because there are first names or initials: "I. van Beijnum". This means that the makers of XML2RFC spent a lot of time making the tool require the authors to spend a lot of time to create something that is sometimes incorrect, with no means to correct the problem. An all-around waste of time. Then there is the problem with XML in general. Now apparently there are XML editors that can make sure you create syntactically correct XML without having to take care of all the details manually. But as someone who has otherwise no need to write XML, I'm not familiar with those tools. So I write my XML2RFC source by hand. The result is that I invariably get error messages that the and tags don't match properly. This is a problem that is extremely hard to debug manually, especially as just grepping for "section" isn't enough: there could be a , etc somewhere between a and that breaks everything. First writing a source file and then compiling it into an output file is no longer something something that is familiar to most people. When I write anything other than a draft, I can simply select "header level 2" and I know that everything will be taken care of. I don't have to explicitly tell my word processor where the text following a header level 2 ends, because the presence of another header makes that clear both to me and to the software. What we need is the ability to write drafts with a standard issue word processor. I'm sure that sentence conjured up nightmares of Word documents with insane formatting being mailed around clueless beaurocracies, but that's not what I mean. Word processors use styles to tag headings, text, quotes, lists and so on: the exact same stuff that you can do in XML but rather than having to think about it (especially closing all tags correctly) it happens easily, automatically and without getting in the way. (I can even change the style for an entire paragraph with a single menu selection or function key without having to find the beginnings and ends of that paragraph.) Formatting is then based on the style tags, with all explicit formatting aplied by the word processor removed. This is standard operating procedure in 99% of publishing. (The other 1% being scientific/engineering books where the authors send in Latex.) All the stuff that can't be handled by styles should just be copied and pasted from the boilerplate, without the need for tools to know about the structure of these things. (At least not in the draft stage, perhaps this can be useful in the final stages of RFC editing.) ___ Ietf ma
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: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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: XML2RFC must die, was: Re: Two different threads - IETF Document Format
What we need is the ability to write drafts with a standard issue word processor. Why? I suppose if there were indeed a *standard* word processor, this might be feasible, but I think by "standard issue" you mean "commercially available". http://www.xmlmind.com/xmleditor/ Commercial, and the personal edition is available at no cost. I've gotten non-CS people up to speed on that tool in no time. Best with: http://code.google.com/p/xml2rfc-xxe/ (But then, I use Emacs, which is non-commercial and free.) Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Iljitsch van Beijnum writes... > I'm very disappointed that the silent majority of draft authors > isn't speaking up. I can't imagine that the vast majority of > draft authors has absolutely no problems with XML2RFC. My personal experience with XML2RFC, as an I-D and RFC author has been largely positive. There does seem to be a bug in the latest pre-release version around the use of ">" and "<" characters in ASCII art figures (as arrow heads). Other than that, I find it easy to use. It's true that the documentation is merely adequate, especially in the area of document meta-data. I find it to be generally consistent with other open source documentation. > The problem with XML2RFC formatted drafts and RFCs is that you > can't display them reasonably without using XML2RFC... All you're saying is that XLM2RFC isn't WYSIWYG. True enough. Neither is nroff. > ...and although XML2RFC can run on many systems in theory, in > practice it's very difficult to install and run successfully because > it's written in TCL and many XML2RFC files depend on the local > availability of references. I rely on the on-line, web-based conversion service. I'll admit that I've never gotten a local install of XML2RFC to work. > What we need is the ability to write drafts with a standard > issue word processor. Why? I suppose if there were indeed a *standard* word processor, this might be feasible, but I think by "standard issue" you mean "commercially available". ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. I have no significant problems using xml2rfc, and find it easier to write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or Microsoft Word. I also appreciate the added consistency in Internet-Draft formatting that has resulted since xml2rfc has been widely adopted. This makes it a lot easier to print drafts, since they have consistent page sizes and form-feed characters. -- Colin Perkins http://csperkins.org/ ___ 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 Shore 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: More liberal draft formatting standards required
At 4:12 PM +0300 7/5/09, Yaakov Stein wrote: >If I remember correctly, draft-ash-alt-formats gave such examples. > >G.805 diagrams were needed for some of the PWE and MPLS work, >but could not be put in the desired format. > >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. It appears that people have forgotten that, when needed for clear artwork, RFCs can be published in PDF format. This has been done in the past, and can be done again in the future. If WGs are not doing some work because of fear of not having it published as an RFC because of the artwork, they are working under a misconception. Talk about premature anti-optimization! --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Having written a moderate number of drafts, using a number of tools, I find that I strongly prefer using XML2RFC. One large draft I was working on was originally written using WORD. I found it extremely difficult to work with (although I have a current version of Word available at all times.) Instead, working with another author we converted the document to XML for XML2RFC. And we did this in spite of knowing up front that the large amount of XML in the I-D was going to make this harder. The current procedures allow for XML2RFC, Word, NROFF, and manual text (if you really want.) Yes, to use any one of those you have to figure out some idiosyncrasies of the particular approach. So I am very confused why you are asking us to kill a tool that was produced by volunteers, works very well, and that many people use by choice. I have seen some folks arguing that we should make XML2RFC normative and mandatory. If they can figure out how to automatically and accurate convert the other mechanisms people use, then that can be considered. Otherwise, mandating would be inappropriate, as some folks do indeed find it difficult. Yours, Joel M. Halpern Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. ... ___ 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 Shore 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: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. I'm a programmer, so none of this probably matters, but I didn't have any more trouble learning to use xml2rfc than I normally have with other programs that are fairly powerful but poorly documented. Reading XML is its own skill and not always easy, by any means, but that is true for any other text markup language. Deciphering the error messages isn't easy either, but not *extremely* hard. I did try to install xml2rfc locally on my system and failed miserably, partly because of all the additional junk I would have had to install, but the online version always works like a champ for me. The point about capitalizing Dutch names wrong is an important localization issue, since people's names are important, but treating it as a fatal flaw in the premise of "encode meaning, not presentation" seems to weaken the overall argument. It's a bug. What we need is the ability to write drafts with a standard issue word processor. I'm sure that sentence conjured up nightmares of Word documents with insane formatting being mailed around clueless beaurocracies, but that's not what I mean. Word processors use styles to tag headings, text, quotes, lists and so on: the exact same stuff that you can do in XML but rather than having to think about it (especially closing all tags correctly) it happens easily, automatically and without getting in the way. (I can even change the style for an entire paragraph with a single menu selection or function key without having to find the beginnings and ends of that paragraph.) I fear this will run into the ground instantly, if the anti-Microsoft faction insists on a single "standard issue" word processor that is unfamiliar to most users. The same problems with learning to use a new tool will apply. It sounds like what people really want is a more comprehensive system that would allow I-D authors to use xml2rfc, roff, Word, LaTeX, or basically any tool they like, not a great policy reversal that replaces one mandatory tool with another. Given the level of effort involved and user expectations, especially concerning support for the latest updates to the IP boilerplate, this would be beyond the scope of volunteer developers; it would require professional developers with a professional development budget. -- 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
Tim Bray 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: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Iljitsch van Beijnum wrote: > My apologies for the subject line. I'm very disappointed that the silent > majority of draft authors isn't speaking up. I can't imagine that the > vast majority of draft authors has absolutely no problems with XML2RFC. I use the RFC 2629 format for all my drafts and cannot imagine using something else. The xml2rfc tool is not perfect but does a good job to convert in html or text. I do not think that the RFC 2629 format should be the only mandatory format, but I think that the upload tool should at least give a warning when an RFC 2629 document will not permit to recreate the text version uploaded at the same time. I wrote an (yet unpublished) tool to convert RFC 2629 documents to mobi document, so they can be used on an Amazon Kindle. The plan was to take the list of all I-Ds published as RFC 2629 documents before the deadline, convert them and let people install them on their Kindle, e.g. to read on the trip to the IETF meeting. Unfortunately most of the I-D uploaded in RFC 2629 form cannot be used to generated a useful document (mobi or text), for two main reasons: 1) the date element is not fully filled, so the date in the final output changes and, 2) the references are not resolved (i.e. there is elements in the document), so the final output changes when the documents referenced change. The problem is that there is at the same time some high level components (include, unspecified dates) mixed with low level components in the RFC 2629 format. The low level components are part of the subset that makes possible to rebuild the various output formats at anytime and that, IMO, should be enforced at upload time. The high level components are what makes the editing process easier. I use a superset of RFC 2629 for my documents (e.g. I use xinclude instead of the include PI) and a script to convert it to the low-level subset described above. This script uses the docName in the high level document to generate the filename of the low level document, which is very useful when using source control management. The script also resolves all the xinclude references, removes the comments and adds the current date. The process is then something like this: turn-uri.xml --> draft-ietf-behave-turn-uri-02.xml --> upload --> draft-ietf-behave-turn-uri-02.txt --> upload --> draft-ietf-behave-turn-uri-02.mobi -- Marc Petit-Huguenin Home: m...@petit-huguenin.org Work: petit...@acm.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Carsten Bormann wrote: What we need is the ability to write drafts with a standard issue word processor. Why? I suppose if there were indeed a *standard* word processor, this might be feasible, but I think by "standard issue" you mean "commercially available". http://www.xmlmind.com/xmleditor/ Commercial, and the personal edition is available at no cost. I've gotten non-CS people up to speed on that tool in no time. Best with: http://code.google.com/p/xml2rfc-xxe/ +1 This is my preferred mechanism (thanks to Bill Fenner). It isn't totally perfect but it makes it very difficult to produce invaliud xml and does give you a good idea of what you will get. One colleague has had problems due to exploiting (or maybe just not getting caught by) some of the laxities in earlier versions getting tightened up later, but it is generally easy enough to fix things up. Bill's verifier is very helpful for this purpose. http://www.fenron.com/~fenner/ietf/xml2rfc-valid/ As regards documentation, there are two sets of tutorial slides (maybe could be described as 'basic' and 'intermediate' - I wrote the latter). The FAQ is very useful and there are several templates, including the one I did to accompany the tutorial I did. This has lots of explanatory text in it with many examples - there is a stripped down version for when you are experienced. These all fill in the holes left by the basic documentation IMHO, including the complete list of PIs and what they do. http://xml.resource.org/xml2rfcFAQ.html Regards, Elwyn (But then, I use Emacs, which is non-commercial and free.) Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote: > My apologies for the subject line. I'm very disappointed that the > silent majority of draft authors isn't speaking up. I can't imagine > that the vast majority of draft authors has absolutely no problems > with XML2RFC. So I'm assuming they've been ignoring the thread, > hopefully the new subject line will get some of them to chime in. If > that doesn't happen I'll shut up and try to figure out why I have so > much trouble with something that nobody else finds difficult. I have no significant problems using xml2rfc, and find it easier to write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or Microsoft Word. My experience has been the same. I will also add that I find the ability to apply XML tools, including but not limited to syntax checking editors, very convenient. I particularly like the fact that xml2rfc lets me focus on the content of my drafts and spend very little time on presentation issues. I don't even want to think about how much time I've wasted piddling around with formattting nits when using nroff, and don't get me started on LaTeX. Oh, and as for installing the software, I'm not a TCL fan, but even so I've done that on everything from Mac OS 9 to Solaris to OpenVMS. I sure can't say the same for groff. My only serious complaint about xml2rc has been the current need to use a pre-release version and the whole boilerplate thing, but I view that as a failing (or is that "flailing"?) of our process and not an xml2rfc issuue per se. I also appreciate the added consistency in Internet-Draft formatting that has resulted since xml2rfc has been widely adopted. This makes it a lot easier to print drafts, since they have consistent page sizes and form-feed characters. Agreed that the consistency is very welcome, but I honestly can't recall the last time I printed out a draft or RFC. It's been several years at least. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Tools-discuss] Java application for editing nroff formatted Internet Drafts
FYI, I have just released version 0.8 of NroffEdit (WYSIWYG nroff editor linked at http://tools.ietf.org/tools/) This version is now fully compatible with the IETF nroff template file (http://aaa-sec.com/pub/NroffEdit/2-nroff_template.nroff) and correctly implements all features that is supported by the RFC editor. /Stefan ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
On 5 jul 2009, at 16:22, Dave Nelson wrote: I suppose if there were indeed a *standard* word processor, this might be feasible, but I think by "standard issue" you mean "commercially available". Standard issue = standard, typical. I used it in the sense of "any decent". Any word processor can create styles the way I talked about, such as Word, Pages, OpenOffice, just to name the ones that I know are still around. The only problem converting a style-tagged document to draft/ RFC format or whatever archival format we end up using in the future. The obvious way to do this would be to interpret the XML that each of these produce, but the problem is that they each have their own format, with little interoperation. Word 97 .doc format is the de facto lingua franca in the word processing world, but this is an inconvenient format. Rich text (RTF) format would probably be best. This format is fairly limited, but we only need the text itself and the styles so it should be more than sufficient. It's also a text- based format. On 5 jul 2009, at 18:01, Joel M. Halpern wrote: So I am very confused why you are asking us to kill a tool that was produced by volunteers, works very well, and that many people use by choice. You're right, I shouldn't use the word "die". The blog post by ekr that I linked to in my first message talked about how XML2RFC has become a de facto requirement because of the outdated formatting requirements that can only be met with XML2RFC or even quainter tools. This is what I'm having problems with. Of course if people are happy with XML2RFC, that's fine. I have seen some folks arguing that we should make XML2RFC normative and mandatory. If they can figure out how to automatically and accurate convert the other mechanisms people use, then that can be considered. Ah, but that's impossible, unless you add an AI to the conversion tool that comes up with the semantic annontations that were never in the source. On 5 jul 2009, at 19:04, Doug Ewell wrote: The point about capitalizing Dutch names wrong is an important localization issue, since people's names are important, but treating it as a fatal flaw in the premise of "encode meaning, not presentation" seems to weaken the overall argument. It's a bug. It's not a bug, it shows that the basic premise behind XML2RFC is untenable. What we need is the ability to write drafts with a standard issue word processor. I'm sure that sentence conjured up nightmares of Word documents with insane formatting being mailed around clueless beaurocracies, but that's not what I mean. Word processors use styles to tag headings, text, quotes, lists and so on: the exact same stuff that you can do in XML but rather than having to think about it (especially closing all tags correctly) it happens easily, automatically and without getting in the way. (I can even change the style for an entire paragraph with a single menu selection or function key without having to find the beginnings and ends of that paragraph.) I fear this will run into the ground instantly, if the anti- Microsoft faction insists on a single "standard issue" word processor that is unfamiliar to most users. The same problems with learning to use a new tool will apply. It sounds like what people really want is a more comprehensive system that would allow I-D authors to use xml2rfc, roff, Word, LaTeX, or basically any tool they like, not a great policy reversal that replaces one mandatory tool with another. Given the level of effort involved and user expectations, especially concerning support for the latest updates to the IP boilerplate, this would be beyond the scope of volunteer developers; it would require professional developers with a professional development budget. -- 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
At 09:38 AM 7/5/2009, Colin Perkins wrote: On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. I have no significant problems using xml2rfc, and find it easier to write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or Microsoft Word. I also appreciate the added consistency in Internet-Draft formatting that has resulted since xml2rfc has been widely adopted. This makes it a lot easier to print drafts, since they have consistent page sizes and form-feed characters. huh? the current boilerplate has the first page being 54 lines long, and subsequent pages being 57 lines long, but with the "footer" on the 56th line, and not the 57th. The "footer" on the first page isn't on the last line of the page either. This isn't very uniform... perhaps unless you use some special viewer to recreate this non-uniform display consistently. IDs and RFCs are displayed in text, and they should be viewable in any text program consistently. Or am I missing some magic program that is implicitly mandatory to use in all this process? -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
+1 At 11:01 AM 7/5/2009, Joel M. Halpern wrote: I have seen some folks arguing that we should make XML2RFC normative and mandatory. If they can figure out how to automatically and accurate convert the other mechanisms people use, then that can be considered. Otherwise, mandating would be inappropriate, as some folks do indeed find it difficult. Yours, Joel M. Halpern Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Tools-discuss] Java application for editing nroff formatted Internet Drafts
Sorry for the double posting. The link to the tool fell off. Here it is: http://aaa-sec.com/nroffedit/index.html /Stefan On 09-07-05 9:08 PM, "Stefan Santesson" wrote: > FYI, > > I have just released version 0.8 of NroffEdit (WYSIWYG nroff editor linked > at http://tools.ietf.org/tools/) > > This version is now fully compatible with the IETF nroff template file > (http://aaa-sec.com/pub/NroffEdit/2-nroff_template.nroff) and correctly > implements all features that is supported by the RFC editor. > > /Stefan > > > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
I also support this view, and the reason why I think this is a good idea is that the likelyhood we will see MORE (professional) tools helping with the XML2RFC production if we do. So I think it will help "both" views expressed on this list. Patrik On 5 jul 2009, at 21.55, James M. Polk wrote: +1 At 11:01 AM 7/5/2009, Joel M. Halpern wrote: I have seen some folks arguing that we should make XML2RFC normative and mandatory. If they can figure out how to automatically and accurate convert the other mechanisms people use, then that can be considered. Otherwise, mandating would be inappropriate, as some folks do indeed find it difficult. Yours, Joel M. Halpern Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
On 5 Jul 2009, at 20:52, James M. Polk wrote: At 09:38 AM 7/5/2009, Colin Perkins wrote: On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. I have no significant problems using xml2rfc, and find it easier to write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or Microsoft Word. I also appreciate the added consistency in Internet-Draft formatting that has resulted since xml2rfc has been widely adopted. This makes it a lot easier to print drafts, since they have consistent page sizes and form-feed characters. huh? the current boilerplate has the first page being 54 lines long, and subsequent pages being 57 lines long, but with the "footer" on the 56th line, and not the 57th. The "footer" on the first page isn't on the last line of the page either. This isn't very uniform... perhaps unless you use some special viewer to recreate this non-uniform display consistently. It doesn't greatly offend me that the first page is three lines shorter than the other pages. Nor does it confuse enscript, on those occasions when I want to print an internet-draft or RFC. This is very much unlike the situation pre-xml2rfc, when the page length and width varied considerably for some drafts, and where form- feeds were often inconsistently applied. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format
> At 11:01 AM 7/5/2009, Joel M. Halpern wrote: > >I have seen some folks arguing that we should make XML2RFC normative > >and mandatory. If they can figure out how to automatically and > >accurate convert the other mechanisms people use, then that can be > >considered. Otherwise, mandating would be inappropriate, as some > >folks do indeed find it difficult. +1 For those who are used to MS-Word, XMLMind is frustrating and truly requires an XML mind. Even simple things like cut/paste are done in a very different (and frankly inconsistent) way, as are references and such. In theory a WYSIWYG word processor shouldn't require an author to know the internal representation and underlying language of the document format. I know a large number if not outright majority of IETF authors do not use MS-Word, so XML2RFC is a fine *option* - but please don't ever *mandate* it and force the rest of us have to write documents in a syntax only a tiny fraction of the planet uses and understands. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
I also would be against mandating xml2rfc. I do agree that certain aspects of xml2rfc are convenient, but when it comes to edit text, I really prefer .nroff On 09-07-05 8:16 PM, "ned+i...@mauve.mrochek.com" wrote: > I particularly like the fact that xml2rfc lets me focus on the content of my > drafts and spend very little time on presentation issues. I don't even want to > think about how much time I've wasted piddling around with formattting nits > when using nroff, and don't get me started on LaTeX. > > Oh, and as for installing the software, I'm not a TCL fan, but even so I've > done that on everything from Mac OS 9 to Solaris to OpenVMS. I sure can't say > the same for groff. I hope to have provided a simple way to get around these issues with nroff with the tool I wrote, as it makes it easy to do the formatting nits and does not require groff or any other external tools to be installed. /Stefan ___ 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 Shore wrote: > You're heading into new territory, here. No, I disagreed with an unqualified assertion you made using the extremely well-defined term"ASCII". 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 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 Ewell wrote: > Tim Bray 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
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
