Re: A modest proposal - allow the ID repository to hold xml
Hi ! I think we should eventually keep the txt version of IDs and RFCs as the reference format for `consumers` (reviewers, readers...). The availability of sources (no matter if it is xml or nroff, etc.) has different consequences for RFCs and I-Ds. . For RFCs, I think sources should be available, if possible in a format chosen by consensus; xml would be my choice here. Availability of RFCs sources would be provided only for third parties to generate other formats (like zvon or others). RFC repository would NOT host any of html, ps, pdf etc formats except the ASCII .txt and the sources. IETF website might provide such formats through cgi, servlets, etc. with an appropriate cache if IETF decides such a functionality is relevant. . For I-Ds, sources are important in order to relieve the editorial process. Though I'm advocating xml, I can cope with any STANDARD format for the representation of structured documents. Last point is I mentioned earlier that either source or txt version should be provided to the editor, but not both. In effect, providing two versions of what should be `semantically` the same content may lead to incoherences within the two versions. My trust goes more to the I-D editor than to the actual authors here (sorry :). The last pb is: what source formats are acceptable in the repository ? Certainly we cannot have a huge choice here. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/
Re: A modest proposal - allow the ID repository to hold xml
IANAXE*, so I may be saying something stupid here, but... Wouldn't it be possible to come up with a DTD that makes it possible to tag all the different parts of a draft or an RFC to enable all the automated processing we love so much, but in such a way that when all the .* sequences are removed, the document in current RFC format emerges? This wouldn't lead to authoritativeness problems, and it should allow taking a draft or RFC and covert it back to an editable document without making the draft/RFC itself irresistibly editable. And it doesn't make any assumptions about the format of RFCs, so it shouldn't be a problem to bring older RFCs under this regime. * I am not an XML expert
Re: A modest proposal - allow the ID repository to hold xml
On woensdag, sep 3, 2003, at 23:34 Europe/Amsterdam, Vernon Schryver wrote: It is just plain ***WRONG!*** to even start to consider anything but ASCII for the official documents. As hard as it is for the unscared to believe, even XML will fade away completely and be replaced by something else even more wonderful, user friendly, easier for convicted monopolies to embrace and extend, and so forth. When that happens, there will be a new calls for reform. It's all very simple. The ASCII format in which RFCs are published is a huge pain, because it puts whitespace, linebreaks, headers, footers and page breaks in fixed places. So anyone who doesn't use the same printer as the RFC editor is inconvenienced. For just reading the RFC this isn't a huge deal as after the first hundred or so you get used to it. But for editing an existing document, it is much more painful. Personally, I'd like to see all the extra stuff that isn't pure ASCII with a line break after a paragraph go, but I guess this is different for everyone. But there is one thing I'm pretty sure of: nobody edits IDs or RFC in their native format. So why not simply make the format used by the author available in a structured way? This isn't guaranteed to help (the original format may only be decipherable by no longer existing tools) but at least there is potential for more efficiency, if the original format can stilll be read and converted.
Fw: A modest proposal - allow the ID repository to hold xml
I agree. ASCII is a big pain. For example, graphics/pictures can clarify a lot the text and with ASCII is painful and not so clear. We should support format that are easy to edit, formats that support control of changes and so on. I will agree to support for example a PDF as the final document, instead of TXT. Regards, Jordi - Original Message - From: Iljitsch van Beijnum [EMAIL PROTECTED] To: Vernon Schryver [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 04, 2003 12:36 PM Subject: Re: A modest proposal - allow the ID repository to hold xml On woensdag, sep 3, 2003, at 23:34 Europe/Amsterdam, Vernon Schryver wrote: It is just plain ***WRONG!*** to even start to consider anything but ASCII for the official documents. As hard as it is for the unscared to believe, even XML will fade away completely and be replaced by something else even more wonderful, user friendly, easier for convicted monopolies to embrace and extend, and so forth. When that happens, there will be a new calls for reform. It's all very simple. The ASCII format in which RFCs are published is a huge pain, because it puts whitespace, linebreaks, headers, footers and page breaks in fixed places. So anyone who doesn't use the same printer as the RFC editor is inconvenienced. For just reading the RFC this isn't a huge deal as after the first hundred or so you get used to it. But for editing an existing document, it is much more painful. Personally, I'd like to see all the extra stuff that isn't pure ASCII with a line break after a paragraph go, but I guess this is different for everyone. But there is one thing I'm pretty sure of: nobody edits IDs or RFC in their native format. So why not simply make the format used by the author available in a structured way? This isn't guaranteed to help (the original format may only be decipherable by no longer existing tools) but at least there is potential for more efficiency, if the original format can stilll be read and converted. ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: A modest proposal - allow the ID repository to hold xml
On Thursday, September 4, 2003, at 12:59 PM, Michael Thomas wrote: Er, if you're going to do that, why don't you just accept any source format It depends what problem you're trying to solve. I really dislike the use of XML for representing protocol elements and I still use nroff and troff for producing most of my documents (not just internet drafts), but I can see where including XML marked-up documents in the repository would be a win *for archival purposes*. How working groups want to handle making document source available is a related but substantially different matter. Melinda
Re: A modest proposal - allow the ID repository to hold xml
Melinda Shore writes: On Thursday, September 4, 2003, at 12:59 PM, Michael Thomas wrote: Er, if you're going to do that, why don't you just accept any source format It depends what problem you're trying to solve. I really dislike the use of XML for representing protocol elements and I still use nroff and troff for producing most of my documents (not just internet drafts), but I can see where including XML marked-up documents in the repository would be a win *for archival purposes*. How working groups want to handle making document source available is a related but substantially different matter. I haven't been paying to much attention to this thread, but my underinformed take was that there were two largish things: 1) Source availability 2) Better cross referencing For (1), just being agnostic and telling people to just deal with whatever source format the author (or wg) decided they felt most comfortable editing in gets you most of the way toward the XML goal without having to deal the religion problem. I don't think it's unreasonable to put the onus on the people who want source to deal with what the author wanted to use. The original editor's life (or lack thereof) seems more important, IMO. For (2), somebody has graciously pointed out that draft/rfc-html mungers already exist. So as a more modest proposal: On the drafts and RFC's repository have two new options: 1) Source in whatever format it came in 2) The .txt sent through the .html grinder Mike
Re: A modest proposal - allow the ID repository to hold xml
On Thursday, September 4, 2003, at 01:42 PM, Michael Thomas wrote: 1) Source availability 2) Better cross referencing 3) Structured text allows for better retrieval capabilities (which is related to 2, actually). What we've got right now is pretty crude. As I mentioned earlier, I don't see any reason why working groups shouldn't continue to do as they will for their own purposes, but how working groups manage document source is not the same question as providing better search and retrieval (or document management, for that matter) capabilities within document archives. I wouldn't want to see nroff or Word source archived for the long term. Melinda
Re: A modest proposal - allow the ID repository to hold xml
From: Michael Thomas [EMAIL PROTECTED] ... For (2), somebody has graciously pointed out that draft/rfc-html mungers already exist. So as a more modest proposal: On the drafts and RFC's repository have two new options: 1) Source in whatever format it came in 2) The .txt sent through the .html grinder As stated that would be a disaster of inviting not just the camel's nose but the whole herd into the tent. For I-Ds, redistributing whatever the authors submitted is mostly harmless and potentially valuable to working groups. It's also potentially dangerous if a working group tolerates attempts to steal documents, but let's put that worry asside. The catastrophy would be keeping anything except .txt for RFCs anywhere remotely official. The obvious issue of in any sense publishing more than .txt is how you handle unavoidable conflicts between .txt and the format of the same document. Just repeating The .txt is normative is not enough. Unless you are merely a legalistic stadnrads lawyer, you care about more fostering interoperability than avoiding liabilities. That requires preventing misunderstandings instead of telling the mislead you should have read the .txt document. There will be differences between the two formats. A major point of non-.txt is to have diferences in presentation. Presentation matters and affects the perceived semantics. We have experimental proof of this in the PostScript RFCs, and that despite the fact that the presentation of PostScript is fixed compared to XML. This week we've heard complaints that pagination and line-breaking in the .txt RFCs is rigid, as if that were a bug instead of a vital feature. Consider the problem of answering the question Is the RFC on my screen or printer the same as your document? Was either version edited by someone or something? Then there is the IETF political problem. As is standard in these recurring discussions, there have already been plenty of claims that .txt is not powerful enough for searching, linking, pictures, editing, and reformating. As soon as there are XML RFCs there will be irresistable pressures to make them normative. I think PostScript RFCs are not normative only because Jon Postel autocratically said No to the similar pressures then. The pressures would be stronger now, and we don't have Jon Postel to order the tide to retreat. Then no matter what DTD verifiers the RFC Editor runs, we will have people saying RFC 98765432 says blah de blah right here on this sheet of paper because they printed it with a User Friendly XML printer that fixes spelling errors and deletes bits that infringe on Microsoft's business plans and the RIAA's intellectual property. Vernon Schryver[EMAIL PROTECTED]
Re: A modest proposal - allow the ID repository to hold xml
Consider the problem of answering the question Is the RFC on my screen or printer the same as your document? Was either version edited by someone or something? Then no matter what DTD verifiers the RFC Editor runs, we will have people saying RFC 98765432 says blah de blah right here on this sheet of paper because they printed it with a User Friendly XML printer that fixes spelling errors and deletes bits that infringe on Microsoft's business plans and the RIAA's intellectual property. Vernon, if you honestly believe this to be true, then the only format you could possibly advocate is printed hardcopy locked up in a vault. Even ASCII documents are subject to bit rot, be it on media, during transmission, while in memory, etc. --lyndon
Re: A modest proposal - allow the ID repository to hold xml
From: Lyndon Nerenberg [EMAIL PROTECTED] Consider the problem of answering the question Is the RFC on my screen or printer the same as your document? Was either version edited by someone or something? Then no matter what DTD verifiers the RFC Editor runs, we will have people saying RFC 98765432 says blah de blah right here on this sheet of paper because they printed it with a User Friendly XML printer that fixes spelling errors and deletes bits that infringe on Microsoft's business plans and the RIAA's intellectual property. Vernon, if you honestly believe this to be true, then the only format you could possibly advocate is printed hardcopy locked up in a vault. Yes I honestly belive this to be true. The only format I'm really happy with for normative RFCs is paper. (Well, I'd prefer etchings on stainless steel.) However, .txt is close enough because .txt's do get converted to write-once paper that anyone can compare with any other purported copy. Even ASCII documents are subject to bit rot, be it on media, during transmission, while in memory, etc. Yes, everything including paper rots. However, XML is not only designed to be malleable, but most if not all of its proponents in this cycle of this old argument have touted that characteristic as if it were desirable feature instead of terrible bug. With XML (as with HTML), you must assume that someone or something has edited your copy differently than anyone else's copy. As I said, the presentation or form of a document matters. Changing pagination often changes what people understand of a document. The purposes of RFCs do not include being easy to edit. Everything including the convenience of people with ambitions to produce RFC 987654321.ter must be subservient to the real purposes of RFCs. Vernon Schryver[EMAIL PROTECTED]
Re: A modest proposal - allow the ID repository to hold xml
-BEGIN PGP SIGNED MESSAGE- John, your reduced proposal would mean that the XML might not hang around during the editing/publication processs. One key thing is that the XML be available for later use in tracking references. It also makes it easier to do RFCbis. ] Out and about in Ottawa.hmmm... beer.| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian/notebook using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1fIG4qHRg3pndX9AQGNngP8DkeYqZv8znBp9wA2euz1fesQgd/YFvx4 d5Da/ZS1DyMa+zPtjpYNMnLRshSKFahc9ttOCeHIvi1vRMXBPHHnsQ/c0Ljhn9ub akdDogdR+umSk8m7f3gLClZbzcVzF9LDtASTK5IodHFJYCaT1gXh4yVIVoZuBqSs e/K8XX1tpN0= =WiAL -END PGP SIGNATURE-
Re: A modest proposal - allow the ID repository to hold xml
I think there should be a work group to discuss the new possible format of ID.PDF or other format can be more efficient than just text version, Why should we just stick to the ASCII text.
Re: A modest proposal - allow the ID repository to hold xml
On Wed, 3 Sep 2003, Jari Arkko wrote: I'd very much like to allow the submission of XML to the I-D directories. However, in addition I'd like to actually allow the submission of HTML, generated by xml2rfc. Why? Because I'd really like to browse most drafts through my browser, jump to sections, find the references easily etc. And without performing any extra steps by myself. One of the primary reasons for proposing XML as the canonical RFC format is that these other formats (ASCII text, HTML, PDF/Postscript, refer/indxbib, SQL, Tektronix 4013) can be derived from the XML source. Presumably the RFC editor would publish the XML document as the authoritative version, and would also generate and publish (from the XML) alternative copies in the ASCII text, PDF, and HTML formats. This satisfies the plain ASCII text rules bigots (in which camp I am still firmly entrenched) while taking advantage of the markup and linking facilities provided by PDF and HTML. (I've completely given up hope that Microsoft will ever acknowledge that non-flowed text/plain must be rendered with a mono-spaced font, fifty years of prior art be damned, eh?) (It may be that this is possible via XML as well -- I'm not expert in XML so I can't tell if its readily supported by everyone's browser without loading lots of DTDs. Does someone know?) The point of XML is that you don't have to be able to read it. Given an XML DTD for RFCs, tools can be written that express the XML in pretty much any format you like. HTML would certainly be one of those formats. (And for guys like me who live and die by grep, even *I* would buy into an xmlrfcgrep program that provided grep functionality against XML-RFC-DTD files.) And all of these submission formats should be allowed if and only there's a text version to go with it. Let me go out on a limb and say No they shouldn't; only XML submissions should be allowed. Now that the shrapnel has stopped whizzing past my head, let me explain why. The traditional way of writing RFCs is with nroff, typically using a minimal subset of the -ms macros. In recent years Microsoft Word (along with other WYSIAWYG software) has invaded the traditional UNIX typesetting tools workspace to a certain degree (in the context of writing IETF-related documents). Regardless, other than the occasional Loonie who formats this stuff purely by hand, we are all already using markup languages to create these documents. That being the case, XML isn't a new way of writing these documents, it's just a different one. The current RFC DTD isn't complicated, and -- as long as it's kept simple[*] -- I don't see any excuse for people not to use it. Then again, I've been using troff exclusively for 20 years now, to the point where I can _almost_ see the consistency of its syntax ... While there isn't a whole lot I *can't* accomplish in troff, my experience with using it to write I-Ds suggests that those documents are so structured that I really just want to write a simple set of macros tailored for that task. I shudder to think what the Word crowd goes through in this regard. WYS might be WYG, but the path between the two (in my very limited experience) is one whose mana will suck the very sanity from your living soul. There is no argument to be made against the suitability of XML as the canonical format for authoring RFCs and drafts. Writing the raw XML might not be pleasant, but neither is writing raw 'roff (or MS Word) for many people. Let's embrace this as an opportunity. If we can get the marketing twits to concentrate on selling GUI XML RFC authoring tools, we just might be able to distract them from contaminating the actual working groups. --lyndon [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for.
Re: A modest proposal - allow the ID repository to hold xml
Lyndon Nerenberg wrote: Presumably the RFC editor would publish the XML document as the authoritative version, and would also generate and publish (from the XML) alternative copies in the ASCII text, PDF, and HTML formats. Ok. This would be fine. My point was that I as a user (and particularly the large groups of other users out there) are unwilling to do anything extra to read their RFCs. But if the secretariat already publishes the important formats, its fine! And all of these submission formats should be allowed if and only there's a text version to go with it. Let me go out on a limb and say No they shouldn't; only XML submissions should be allowed. Well, this would be quite good too. In fact, it would help the RFC editor automatization process as well -- and they could concentrate more on the real issues, such as talking to IANA or figure out cross references. Thinking some more... I'd *love* to have this. Anyone who opposes? [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. Extension? --Jari
Re: A modest proposal - allow the ID repository to hold xml
I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. Extension? existential ebulliently excellent engineering experienced eccentric --lyndon (egregious evening emoter)
Re: A modest proposal - allow the ID repository to hold xml
Lyndon Nerenberg wrote: This satisfies the plain ASCII text rules bigots (in which camp I am still firmly entrenched) while taking advantage of the markup and linking facilities provided by PDF and HTML. (I've completely given up hope that Microsoft will ever acknowledge that non-flowed text/plain must be rendered with a mono-spaced font, fifty years of prior art be damned, eh?) I'd like to include handy ERD, UML, etc... diagrams in PNG format to make the document more readable. -andy
Re: A modest proposal - allow the ID repository to hold xml
On Tue, Sep 02, 2003 at 01:52:38PM -0600, Lyndon Nerenberg wrote: You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability. While I normally run in horror from all things XML, this is one of the few exceptions. XML would immediately solve a number of problems I face almost daily: - give me a list of all the documents belonging to a particular WG - for any given RFC, show me the chain of document dependencies (obsoletes, updated by, obsoleted by) that pass through this document - for any given RFC, generate a dependency graph based on the normative references in this document You have to have a structured document format to programmatically solve these sorts of problems, and XML provides that. (While I've become quite adept at searching rfc-index.txt with less, I really want something better.) May I add in the same direction ? The structure of the document allows for invoking relations between nodes, which helps for expressing elaborate search both on meta informations (WG, Author, etc.) and on content (the actual titles and text sections). You can surely look within all 'xmlly' available drafts for draft belonging to a specific WG AND referencing a list of specific docs in sections whose title contains a specific word. This would be hard to express against the txt version. And I second Ned's comments about generating *useful* diffs between document revisions. This is especially useful if we generate drafts in XML format. I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) I wonder whether this has not already been done by zvon (http://www.zvon.org/). Concerning referencing rfcs, citation libraries from http://xml.resource.org look rather complete. Several additions to the xml cause: Edition in xml allows for good modularity, e.g. with the definition of xml entities. This is an easy way to divide work between several editors. Availability of the xml source helps for editors to welcome new contributors. What I would suggest is the following: - Authors provide draft in xml XOR txt . This allows for a test period of xml as an alternate default format; authors do not provide both, this in order to avoid incoherences. - rfc editor generates txt, ps, etc. versions. html version may only require reference to a stylesheet, though this is currently tricky because few browsers actually support xml+xsl. Newcomers to xml should be informed of the following: - xml is easy. - Grammar/spelling tools compatible with html generally work (I use ispell and aspell indifferently). - Document structure and well-formedness can be validated. - Maintaining an xml source is easy, compared to maintaining a ASCII formatted txt: this is a point authors may care about. - xml rendering generates classic formats and newers: this is what reviewers, readers care about. - xml users are not hackers, extremists or ninjas. Common sense and good pratice is the main source of xml advocacy. Also, xml is not perfect; it is only better. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/
Re: A modest proposal - allow the ID repository to hold xml
From: Lyndon Nerenberg [EMAIL PROTECTED] ... [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. I don't know about shutting down the IETF, but I do know that in this century you've stated the compelling reason to run screaming from this set of proposals. Have you looked at the 250 lines of XML cruft that Microsoft thinks are required to accompany a 1 word mail message today? Have you ever glanced at the incredibly bloated and broken HTML that most HTML mark-up tools produce? Now recall the galloping freeping creaturism of the last 3 I-Ds you've read. A Turing machine with Perl-like syntax would be incomparably simpler and cleaner than the result of the 5 years work of the new working group in the new area. (What--you don't realize that a new working group would be required?) Vernon Schryver[EMAIL PROTECTED]
RE: A modest proposal - allow the ID repository to hold xml
From: Rosen, Brian [EMAIL PROTECTED] Are you suggesting that we would need a new working group to allow 2629 conformant xml to be optionally submitted with text to the I-D archive? Need?--I don't know. Would inevitably have?--certainly. Why? It's in the modern Tao of the IETF. I'm not proposing any new RFC. Guidelines to authors is not an RFC. 2629 is an RFC. Actually, the last time I looked RFC 3 is an RFC. There is also an I-D in the pipeline to update the classic Instructions to RFC Authors series. The xml2rfc tool, which is not the only tool around, but it's a good one, puts a 70 line style header in front of the text, but then has almost no other bloat that I can see. Is that too much? I don't think there is any cruft at all in the xml described in RFC2629. Now, to the charge that this is feeping creaturism, we must admit guilt. I think there is some value in this proposal. Many seem to agree. I don't like the idea of XML, postscript, or any other standard de jure mark-up language for standards documents, but that's not my point. The nature of modern IETF is such that those who are most enthused about XML will inevitably include many who see no other opportunity for personally Contributing To The Standards Process and perhaps getting their names into the RFC Index. They will not tolerate letting Marshall Rose alone decide what XLM features can be allowed via RFC 2629. They will point out that RFC 2629 is more than four years old and demand that it be updated to address the latest microstupid standard. They'll also point out that Informational is a weak category for something so important to the IETF. Once the camel's nose of updating RFC 2629 is in the tent, we'll have a 3 year (if we're lucky) process that will produce something that will make Microsoft's XML mail cruft look tiny, simple, and elegant. To put my point another way, if you allow XML, you will end up requiring the RFC Editor to accept the output of every mark-up tool that exists or will ever exist, regardless of the restrictinos imposed by RFC 2629. Please think what that really means. You might as well forget ASCII and declare that all future I-Ds and RFCs must be written the then current MS Word format. Vernon Schryver[EMAIL PROTECTED]
Re: A modest proposal - allow the ID repository to hold xml
On Wed, Sep 03, 2003 at 09:46:09AM -0400, Rosen, Brian wrote: What if the version of the tool the author used is different from the I-D editor? The tool itself has -in theory :)- no incidence. Only the DTD has, and it is not expected to change very often. What if the xml is not well formed and the tool does something unexpected? Well-formedness and validation against dtd MUST be checked by I-D editor, and SHOULD by authors. Note that this pb is the same with current scheme: authors can provide messy, bad formatted documents with ansi escape sequences, etc. What do we do when we upgrade the xml schema (that is, do we have to go back and edit older documents)? This is a general pb. Let's assume we change formatting rules for txt IDs. Then, how do we upgrade to new format ? As for many document formats, ascendant compatibility is a legitimate expectation, and is easily granted. When a design flaw from previous models has to be corrected, then most of the time, it should be easy to move old doc to the latest model with a batch xsl tranformation; this sometimes happens. All of these questions would have to be answered, and answered well enough to satisfy some pretty demanding people, some of whom are pretty content with the status quo. Sure. BTW, note that the xml source actually contains in the clear the content of the draft. Information can not be lost. My proposal avoids such discussions. It makes no requirements other than if xml is submitted, then it SHOULD be in conformance to 2629. In my opinion, it MUST be in conformance to 2629 DTD (or later version). If everyone designs one's own DTD, then the advantages from sharing the xml source are greatly reduced. I also think it is MUCH better to start with the I-D archive and not change the RFC process. I certainly agree. Among other things, I-Ds expire. If this change doesn't work, in 6 months, we can be rid of any vestiges. RFCs don't expire (although they get obsoleted), and the time frame is much longer. Let's stick to I-Ds only, please. Brian -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/
RE: A modest proposal - allow the ID repository to hold xml
I think there are quite a few reasons. Mine are: 1) Ability to render in alternate ways to improve readability and accessibility 2) Ability to cross reference documents 3) More uniformity in, e.g. references Brian -Original Message- From: Paul Hoffman / IMC [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 1:06 PM To: Rosen, Brian; '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml At 6:15 PM -0400 8/27/03, Rosen, Brian wrote: I therefore have a modest proposal: Allow the submission of an xml file meeting the requirements of RFC2629 along with the text file (and optional ps file) for an Internet Draft. You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability. --Paul Hoffman, Director --Internet Mail Consortium
Re: A modest proposal - allow the ID repository to hold xml
I don't know about about you, Paul, but I'm writing my drafts using EMACS and Marshall's tool. That allows for generation of HTML, NROFF, and text. The HTML allows for hyperlinks, which is REALLY nice. and for folks who are of the xslt persusasion, julian's html output is very sweet... /mtr ps: the point being, that there's not just one tool that works with this stuff... pps: oh, and did i mention the every expanding bibliographic libraries already in 2629... the 3gpp reference set is coming up later this week (thanks miguel!)
RE: A modest proposal - allow the ID repository to hold xml
The problem with nroff is that there is no RFC to reference that specifies how a document is formatted with nroff. There is wide variation in the macro packages people use to create a document with nroff. Even the RFC editor doesn't try hard to get the nroff source when editing; they make their own. I'm also trying pretty hard to keep the word modest I used in the title of this thread in mind. I'd like to try one simple thing to make I-Ds easier to read and use. Brian -Original Message- From: Zefram [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 1:56 PM To: Rosen, Brian Cc: '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml Rosen, Brian wrote: Allow the submission of an xml file meeting the requirements of RFC2629 along with the text file (and optional ps file) for an Internet Draft. The value in this would be that it provides everyone with the document source, suitable for generating patches for the author. This is useful, but if it's going to be allowed with XML then we should also allow it with nroff, which historically we haven't. I don't have particularly strong feelings either way, but I do think these two cases should be treated equivalently. -zefram
Re: A modest proposal - allow the ID repository to hold xml
I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) actually, carl malamud and brad burdick wrote a script back in 99 that had a 20% success rate on the legacy rfcs. the (unofficial) xml versions of those rfcs is available online. steven connor did some work for me after that to produce xml versions of the remaining rfcs which excluded the middle (i.e., just the front matter and references sections got translated). so, it's not as much work as you'd think, but still far more work than i'd like... /mtr
RE: A modest proposal - allow the ID repository to hold xml
Jari If we have xml in the archive, then there are several tools that can serve you up your choice of formats from that archive. I don't think the value of storing the html bits in the archive is all that much additional value. One could have a website that delivered such a thing without storing the html bits. Such a site would permit the hyperlinking that you are talking about. We also avoid heated discussions about what was allowable in the html, what version of which tools, etc. This is a contentious enough issue (rough consensus and running code applies, right?), and making it bigger makes it harder to reach rough consensus. Let's just do one simple thing -- allow xml, and see how it goes. Brian -Original Message- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 1:28 AM To: Michael Thomas Cc: Paul Hoffman / IMC; Rosen, Brian; '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml Michael Thomas wrote: Paul Hoffman / IMC writes: At 1:22 PM -0400 9/2/03, Rosen, Brian wrote: 2) Ability to cross reference documents That benefit only appears if all, or a significant proportion, of the Internet Drafts are in XML or a similar format. That's not what you proposed. It seems to me that a fairly simple hack could be consed up to generate HTML or whatever for current I'd very much like to allow the submission of XML to the I-D directories. However, in addition I'd like to actually allow the submission of HTML, generated by xml2rfc. Why? Because I'd really like to browse most drafts through my browser, jump to sections, find the references easily etc. And without performing any extra steps by myself. (It may be that this is possible via XML as well -- I'm not expert in XML so I can't tell if its readily supported by everyone's browser without loading lots of DTDs. Does someone know?) And all of these submission formats should be allowed if and only there's a text version to go with it. --Jari
RE: A modest proposal - allow the ID repository to hold xml
Lyndon You make some good points. However, I have not proposed that we change the RFC process, and I've been very carefull to propose that we only accept xml optionally, retaining the requirement to 'send text'. I did so quite deliberately, and I'd really appreciate it if we could take this one small step, rather than changing the entire process, which has served us well for so long. We get a very large bang for such a small, incremental addition. Can we just try this step and see what happens? Brian -Original Message- From: Lyndon Nerenberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 5:24 AM To: Jari Arkko Cc: [EMAIL PROTECTED] Subject: Re: A modest proposal - allow the ID repository to hold xml On Wed, 3 Sep 2003, Jari Arkko wrote: I'd very much like to allow the submission of XML to the I-D directories. However, in addition I'd like to actually allow the submission of HTML, generated by xml2rfc. Why? Because I'd really like to browse most drafts through my browser, jump to sections, find the references easily etc. And without performing any extra steps by myself. One of the primary reasons for proposing XML as the canonical RFC format is that these other formats (ASCII text, HTML, PDF/Postscript, refer/indxbib, SQL, Tektronix 4013) can be derived from the XML source. Presumably the RFC editor would publish the XML document as the authoritative version, and would also generate and publish (from the XML) alternative copies in the ASCII text, PDF, and HTML formats. This satisfies the plain ASCII text rules bigots (in which camp I am still firmly entrenched) while taking advantage of the markup and linking facilities provided by PDF and HTML. (I've completely given up hope that Microsoft will ever acknowledge that non-flowed text/plain must be rendered with a mono-spaced font, fifty years of prior art be damned, eh?) (It may be that this is possible via XML as well -- I'm not expert in XML so I can't tell if its readily supported by everyone's browser without loading lots of DTDs. Does someone know?) The point of XML is that you don't have to be able to read it. Given an XML DTD for RFCs, tools can be written that express the XML in pretty much any format you like. HTML would certainly be one of those formats. (And for guys like me who live and die by grep, even *I* would buy into an xmlrfcgrep program that provided grep functionality against XML-RFC-DTD files.) And all of these submission formats should be allowed if and only there's a text version to go with it. Let me go out on a limb and say No they shouldn't; only XML submissions should be allowed. Now that the shrapnel has stopped whizzing past my head, let me explain why. The traditional way of writing RFCs is with nroff, typically using a minimal subset of the -ms macros. In recent years Microsoft Word (along with other WYSIAWYG software) has invaded the traditional UNIX typesetting tools workspace to a certain degree (in the context of writing IETF-related documents). Regardless, other than the occasional Loonie who formats this stuff purely by hand, we are all already using markup languages to create these documents. That being the case, XML isn't a new way of writing these documents, it's just a different one. The current RFC DTD isn't complicated, and -- as long as it's kept simple[*] -- I don't see any excuse for people not to use it. Then again, I've been using troff exclusively for 20 years now, to the point where I can _almost_ see the consistency of its syntax ... While there isn't a whole lot I *can't* accomplish in troff, my experience with using it to write I-Ds suggests that those documents are so structured that I really just want to write a simple set of macros tailored for that task. I shudder to think what the Word crowd goes through in this regard. WYS might be WYG, but the path between the two (in my very limited experience) is one whose mana will suck the very sanity from your living soul. There is no argument to be made against the suitability of XML as the canonical format for authoring RFCs and drafts. Writing the raw XML might not be pleasant, but neither is writing raw 'roff (or MS Word) for many people. Let's embrace this as an opportunity. If we can get the marketing twits to concentrate on selling GUI XML RFC authoring tools, we just might be able to distract them from contaminating the actual working groups. --lyndon [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. ___ This message was passed
RE: A modest proposal - allow the ID repository to hold xml
Jean-Jacques Is it not better to add xml incremental to text, rather than exclusive OR? If we demand that the I=D editor have a tool and use it to generate text, we open a large box of problems. What if the version of the tool the author used is different from the I-D editor? What if the xml is not well formed and the tool does something unexpected? What do we do when we upgrade the xml schema (that is, do we have to go back and edit older documents)? All of these questions would have to be answered, and answered well enough to satisfy some pretty demanding people, some of whom are pretty content with the status quo. My proposal avoids such discussions. It makes no requirements other than if xml is submitted, then it SHOULD be in conformance to 2629. I also think it is MUCH better to start with the I-D archive and not change the RFC process. Among other things, I-Ds expire. If this change doesn't work, in 6 months, we can be rid of any vestiges. RFCs don't expire (although they get obsoleted), and the time frame is much longer. Let's stick to I-Ds only, please. Brian -Original Message- From: Jean-Jacques Puig [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 7:47 AM To: '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml On Tue, Sep 02, 2003 at 01:52:38PM -0600, Lyndon Nerenberg wrote: You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability. While I normally run in horror from all things XML, this is one of the few exceptions. XML would immediately solve a number of problems I face almost daily: - give me a list of all the documents belonging to a particular WG - for any given RFC, show me the chain of document dependencies (obsoletes, updated by, obsoleted by) that pass through this document - for any given RFC, generate a dependency graph based on the normative references in this document You have to have a structured document format to programmatically solve these sorts of problems, and XML provides that. (While I've become quite adept at searching rfc-index.txt with less, I really want something better.) May I add in the same direction ? The structure of the document allows for invoking relations between nodes, which helps for expressing elaborate search both on meta informations (WG, Author, etc.) and on content (the actual titles and text sections). You can surely look within all 'xmlly' available drafts for draft belonging to a specific WG AND referencing a list of specific docs in sections whose title contains a specific word. This would be hard to express against the txt version. And I second Ned's comments about generating *useful* diffs between document revisions. This is especially useful if we generate drafts in XML format. I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) I wonder whether this has not already been done by zvon (http://www.zvon.org/). Concerning referencing rfcs, citation libraries from http://xml.resource.org look rather complete. Several additions to the xml cause: Edition in xml allows for good modularity, e.g. with the definition of xml entities. This is an easy way to divide work between several editors. Availability of the xml source helps for editors to welcome new contributors. What I would suggest is the following: - Authors provide draft in xml XOR txt . This allows for a test period of xml as an alternate default format; authors do not provide both, this in order to avoid incoherences. - rfc editor generates txt, ps, etc. versions. html version may only require reference to a stylesheet, though this is currently tricky because few browsers actually support xml+xsl. Newcomers to xml should be informed of the following: - xml is easy. - Grammar/spelling tools compatible with html generally work (I use ispell and aspell indifferently). - Document structure and well-formedness can be validated. - Maintaining an xml source is easy, compared to maintaining a ASCII formatted txt: this is a point authors may care about. - xml rendering generates classic formats and newers: this is what reviewers, readers care about. - xml users are not hackers, extremists or ninjas. Common sense and good pratice is the main source of xml advocacy. Also, xml is not perfect; it is only better. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig
RE: A modest proposal - allow the ID repository to hold xml
Vernon Are you suggesting that we would need a new working group to allow 2629 conformant xml to be optionally submitted with text to the I-D archive? Why? I'm not proposing any new RFC. Guidelines to authors is not an RFC. 2629 is an RFC. The xml2rfc tool, which is not the only tool around, but it's a good one, puts a 70 line style header in front of the text, but then has almost no other bloat that I can see. Is that too much? I don't think there is any cruft at all in the xml described in RFC2629. Now, to the charge that this is feeping creaturism, we must admit guilt. I think there is some value in this proposal. Many seem to agree. Brian -Original Message- From: Vernon Schryver [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: Re: A modest proposal - allow the ID repository to hold xml From: Lyndon Nerenberg [EMAIL PROTECTED] ... [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. I don't know about shutting down the IETF, but I do know that in this century you've stated the compelling reason to run screaming from this set of proposals. Have you looked at the 250 lines of XML cruft that Microsoft thinks are required to accompany a 1 word mail message today? Have you ever glanced at the incredibly bloated and broken HTML that most HTML mark-up tools produce? Now recall the galloping freeping creaturism of the last 3 I-Ds you've read. A Turing machine with Perl-like syntax would be incomparably simpler and cleaner than the result of the 5 years work of the new working group in the new area. (What--you don't realize that a new working group would be required?) Vernon Schryver[EMAIL PROTECTED] ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
Re: A modest proposal - allow the ID repository to hold xml
Rosen, Brian wrote: The problem with nroff is that there is no RFC to reference that specifies how a document is formatted with nroff. RFC 2223 has an nroff example, see Appendix - RFC nroff macros and section 3. Format Rules says ms macro package. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
RE: A modest proposal - allow the ID repository to hold xml
The problem with nroff is that there is no RFC to reference that specifies how a document is formatted with nroff. There is wide variation in the macro packages people use to create a document with nroff. Even the RFC editor doesn't try hard to get the nroff source when editing; they make their own. I'm also trying pretty hard to keep the word modest I used in the title of this thread in mind. I'd like to try one simple thing to make I-Ds easier to read and use. I agree 100%. While it is nice to dream about charters being available through rsync, making official HTML versions of all RFCs available, allow submission of HTML versions of drafts, submission of drafts to the RFC Editor in XML format, requiring XML for drafts, inclusion of bitmapped graphics in documents, or any of the other things that have been proposed as additions to the original modest proposal, these sorts of broader changes are far more difficult to implement and will be far more difficult to reach consensus on. Baby steps are in order here. Let's start small and see how it goes. Ned
RE: A modest proposal - allow the ID repository to hold xml
From: Rosen, Brian [EMAIL PROTECTED] ... about. We also avoid heated discussions about what was allowable in the html, what version of which tools, etc. This is a contentious enough issue (rough consensus and running code applies, right?), ... If that is a problem with HTML (I agree that it is), why wouldn't it be a bigger problem with XML? Replacing HT with X doesn't magically change the politics. In fact it makes them worse, because HTML is by now more stable and has better consensus reality than XML. Vernon Schryver[EMAIL PROTECTED]
Re: A modest proposal - allow the ID repository to hold xml
-BEGIN PGP SIGNED MESSAGE- Jari == Jari Arkko [EMAIL PROTECTED] writes: Jari I'd really like to browse most drafts through my browser, Jari jump to sections, find the references easily etc. And without Jari performing any extra steps by myself. Jari (It may be that this is possible via XML as well -- I'm Jari not expert in XML so I can't tell if its readily supported Jari by everyone's browser without loading lots of DTDs. Does Jari someone know?) Directly, maybe in some browsers. However, once the XML is there, you can be assured that someone will run xml2rfc - HTML on everything and make it available. No reason for the secretariat to burn disk space there :-) ] Out and about in Ottawa.hmmm... beer.| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian/notebook using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1ZDlYqHRg3pndX9AQH+uAQA4AFVhCR/B2aZZHdzmBDIASBbPM1Zz1+W XLQHhH2ouzR6eIIfdzSOltjurwq+RljI3tUAuKpseI1p5HTMYhDdvUocGmO5OIZm U0BjF7elmWklB9b6B0VM5ldbXnGdU6Y96T7okStn40jxQCkOqDms6F1HpmfCEKwq YZttpSSIXKw= =O4Xe -END PGP SIGNATURE-
Re: A modest proposal - allow the ID repository to hold xml
On Wednesday, September 3, 2003, at 05:23 AM, Lyndon Nerenberg wrote: [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. Write the schema in Relax NG (RNG). It's joyful, easy-to-use, XML-based schema language. :-) simon -- simonwoodside.com -- openict.net -- 99% Devil, 1% Angel
RE: A modest proposal - allow the ID repository to hold xml
From: Rosen, Brian [EMAIL PROTECTED] I think this was and html not or html, so I think that it is easier to have one additional format and see how it goes, rather than two (or three, or four) On of the advantages of xml is that it marks up things like references and authors with the function, rather than the appearance. You can much more easily generate html from xml than the other way around. Improved formatting is good, but improved cross references/author tracking/ is also good. With xml, we can get both, albeit somewhat indirectly. I think that for a small, simple step, xml is a better choice. The same things were said the last half dozen times this issue came up. After about the second or third round in about 1989, PostScript was officially sanctioned. In some ways that went worse than opponents predicted, but in other ways better. The positive view is that PostScript for RFCs died. Since then we've had at least 2 or 3 rounds of HTML is better followed by at least two rounds not counting this one for XML. It's one thing to advocate PostScript, MS Word, XML, HTML, nroff, or whatever you like for the I-D submission format. This morning some people seemed to be saying that XML should only replace nroff. I don't see the point, but then I use vi and emacs to generate nroff. If the Editor will tolerate XML, or any of a zillion other markup or fancy document formats (I designed and implemented one 20 years ago that saw significant commercial exposure), no one has standing to complain. However, by this afternoon, the consensus among reformers seems to be replacing ASCII with XML for the normative documents. Also as I predicted this morning, there is no consensus on the DTD except that it will be small, simple, wonderful for generating HTML, links, etc., and different from Marshall's. The parade of wonderful, simple, easy to use, powerful, user friendly markup tools has already begun. The talk of submitting I-Ds through a validator sounds nice, but unimpressive to anyone with real world experience with HTML validators. I write very simple HTML with vi and emacs and use the X3C validator enough to worry that they might cut me off. Still, the fact that the X3C validator is no subsitute for testing your HTML against browsers demonstrates that correctness provers are as far from the perfection claimed in advertising for markup languages as for programming languages and protocols. It is just plain ***WRONG!*** to even start to consider anything but ASCII for the official documents. As hard as it is for the unscared to believe, even XML will fade away completely and be replaced by something else even more wonderful, user friendly, easier for convicted monopolies to embrace and extend, and so forth. When that happens, there will be a new calls for reform. To put it another way, no one who is the least uncomfortable with the existing PostScript RFCs has any standing to advocate XML for official documents. That Communism or replacing ASCII RFCs didn't work before does not support the position that this time we'll get it right. Vernon Schryver[EMAIL PROTECTED]
RE: A modest proposal - allow the ID repository to hold xml
From: John C Klensin [EMAIL PROTECTED] ... (1) As an/the authoritative format, plain ASCII text, plus whatever additional format(s) the RFC Editor decides to permit to support drawings, etc., should almost certainly remain the target for the reasons you identify. ... (2) If a group of people, such as a WG, are collaborating on the development of a document, having the working format (whatever it is) readily available would seem to be an advantage. This should not make that format authoritative, or attach any special importance or validation to it relative to other formats. That sounds fine or at least tolerable. Now I think that all that Brian proposed originally was that the XML format of Internet Drafts be made available when it happened to exist. Even though that might be letting the proverbial camel's nose into the tent, it strikes me as basically harmless and probably useful. yes. Did I misunderstand him? Do we disagree about part of the above and, if so, which part? My possibly mistaken impression of Brian's most recent position is that he would support XML for the official documents. Regardless of his position, other people have clearly come out in favor XML for the official format. The frequently mentioned hyperlinks among documents such as for authors would be rather boring if the links are only among documents that expire after 6 months. More powerful searching among I-Ds would be useful, but the real power would be searching among RFCs. Several people have written about converting old RFCs to XML. Vernon Schryver[EMAIL PROTECTED]
Re: A modest proposal - allow the ID repository to hold xml
XML may not be the solution to the entire RFC generation process but it could certainly help those of use who programmatically scrape the text based documents to extract the basic info (references, obsoletes, updates, std, bcp, fyi, yada yada yada...) A subset of the DTD containing the summary info submitted along with the RFC text could be very useful. Cheers - Original Message - From: Marshall Rose [EMAIL PROTECTED] To: Lyndon Nerenberg [EMAIL PROTECTED] Cc: Paul Hoffman / IMC [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 1:17 PM Subject: Re: A modest proposal - allow the ID repository to hold xml I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) actually, carl malamud and brad burdick wrote a script back in 99 that had a 20% success rate on the legacy rfcs. the (unofficial) xml versions of those rfcs is available online. steven connor did some work for me after that to produce xml versions of the remaining rfcs which excluded the middle (i.e., just the front matter and references sections got translated). so, it's not as much work as you'd think, but still far more work than i'd like... /mtr
Re: A modest proposal - allow the ID repository to hold xml
-BEGIN PGP SIGNED MESSAGE-
Rosen == Rosen, Brian [EMAIL PROTECTED] writes:
Rosen I therefore have a modest proposal:
Rosen Allow the submission of an xml file meeting the requirements of
Rosen RFC2629
Rosen along with the text file (and optional ps file) for an Internet
Rosen Draft.
This is a great idea.
Rosen This would change the Guidelines to Authors of Internet-Drafts
Rosen document to add: XML marked-up text is acceptable, but only when
Rosen submitted
Rosen with a matching ASCII version. The xml file should be in
Rosen conformance
Rosen with RFC2629.
I think that the DTD that xml2rfc uses has evolved a bit since 2629.
The other tools have evolved too, I think. Point being that we may have
to do 2629bis first.
It would be so nice to be able to refer to the draft itself in order to
cite it :-)
I'd like it if the charters were also available by rsync.
Even better if we started using a directory per WG...
I do the following with my drafts:
1) sort them by WG name.
2) copy the charter.
3) link in any RFCs that the charter references.
===
#!/usr/bin/perl
chdir('/corp/ietf');
system(rsync -avz ftp.rfc-editor.org::rfcs-text-only ftp.ietf.org/rfc);
system(rsync -avz optimus.ietf.org::internet-drafts ftp.ietf.org/internet-drafts);
system(cd html.charters; wget -r -l 1 -nv -np -nd -nc
http://www.ietf.org/html.charters/;);
opendir(DRAFTS,ftp.ietf.org/internet-drafts);
@drafts=readdir(DRAFTS);
closedir(DRAFTS);
foreach $draft (@drafts) {
next if ($draft =~ /^\./);
$draft =~ m,draft-([^-]*)-([^-]*)-(.*),;
if($1 eq ietf) {
$dir = id/$1/$2;
$base= $3;
} else {
$dir = id/$1;
$base =$2-$3;
}
next if (-f $dir/$base);
print $draft - $dir/$base\n;
system(mkdir -p $dir) unless (-d $dir);
link(ftp.ietf.org/internet-drafts/$draft,$dir/$base);
}
opendir(CHARTERS,html-charters);
@charters=readdir(CHARTERS);
closedir(CHARTERS);
foreach $charter (@charters) {
next if ($charter =~ /^\./);
if($charter =~ m,(.*)-charter.html,) {
# got one, copy it, sanitizing the links.
$wgname=$1;
$infile=html.charters/$charter;
$dir=id/ietf/$wgname;
system(mkdir -p $dir) unless (-d $dir);
$outfile=$dir/$charter;
if(-f $outfile ) {
# if date of infile is older than outfile
print STDERR $infile: .(-M $infile). $outfile: .(-M $outfile).\n;
if(-M $infile -M $outfile) {
print STDERR $infile not newer than $outfile\n;
}
}
# okay, process it.
open(CHARTER, $infile) || die Can not open $infile: $!\n;
open(OUTFILE, $outfile)|| die Can not open $outfile: $!\n;
while(CHARTER) {
# localize references
s,href=/internet-drafts/draft-ietf-(.*\.txt),href=\1,g;
if(m,href=/rfc/rfc(.*).txt,) {
$rfcnum=$1;
s,href=/rfc/rfc(.*).txt,href=rfc\1.txt,g;
#print STDERR looking for rfc$rfcnum.txt\n;
if(! -f $dir/rfc$rfcnum.txt
! -f $dir/rfc$rfcnum.txt.Z) {
$rfc4 = sprintf(%d, $rfcnum);
print STDERR linking: ftp.ietf.org/rfc/$rfc4.txt\n;
link(ftp.ietf.org/rfc/rfc$rfc4.txt,$dir/rfc$rfcnum.txt) || die Can not
link ftp.ietf.org/rfc/rfc$rfc4.txt: $!\n;
}
}
print OUTFILE;
}
close(CHARTER);
close(OUTFILE);
}
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat
iQCVAwUBP1TAz4qHRg3pndX9AQGhZAP/bql06JCfPjf+CoWjRE4Q4jtzzqmjs1bY
YwgdZwfbPJML8z1nVlXKdyb/3l2pM70g0uTHIb52QBSrmIOu48DaohdAWeo4xKOy
JO0jwxX3VilBmXv6V805tHuHesVxzc6OITKm5MeZ+13gSvIKHjB5L0zDoEgyZlE7
rj653vyo5rU=
=M4fN
-END PGP SIGNATURE-
Re: A modest proposal - allow the ID repository to hold xml
I don't know about about you, Paul, but I'm writing my drafts using EMACS and Marshall's tool. That allows for generation of HTML, NROFF, and text. The HTML allows for hyperlinks, which is REALLY nice. Eliot
Re: A modest proposal - allow the ID repository to hold xml
Rosen, Brian wrote: Allow the submission of an xml file meeting the requirements of RFC2629 along with the text file (and optional ps file) for an Internet Draft. The value in this would be that it provides everyone with the document source, suitable for generating patches for the author. This is useful, but if it's going to be allowed with XML then we should also allow it with nroff, which historically we haven't. I don't have particularly strong feelings either way, but I do think these two cases should be treated equivalently. -zefram
RE: A modest proposal - allow the ID repository to hold xml
Eliot Lear wrote: I'm writing my drafts using EMACS and Marshall's tool. That allows for generation of HTML, NROFF, and text. The HTML allows for hyperlinks, which is REALLY nice. XML is the way to go, no doubt about it. Michel.
Re: A modest proposal - allow the ID repository to hold xml
At 10:47 AM -0700 9/2/03, Eliot Lear wrote: I don't know about about you, Paul, but I'm writing my drafts using EMACS and Marshall's tool. That allows for generation of HTML, NROFF, and text. The HTML allows for hyperlinks, which is REALLY nice. Great! Why does that mean that the XML input should be published in the Internet Drafts directory along with the text output? --Paul Hoffman, Director --Internet Mail Consortium
Re: A modest proposal - allow the ID repository to hold xml
At 6:15 PM -0400 8/27/03, Rosen, Brian wrote: I therefore have a modest proposal: Allow the submission of an xml file meeting the requirements of RFC2629 along with the text file (and optional ps file) for an Internet Draft. You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability. On the contrary, having the base XML is a huge benefit for some searches I, and I suspect many others, often do: I want to find what's changed from one version to the next. All too often minor changes lead to large differences in formatted output, and even the various tricky diff utilities don't always overcome this. And if diffs of the base XML aren't to your taste, it would be easy to build a tool that would perform the comparison and produce a modified XML document with the changes highlighted. (Indeed, I'm sure utilities to do this already exist, although how flexible they are in regards to different XML formats I couldn't say.) I'm sure there are also any number of other useful tricks that can be performed if you have a number of Internet Drafts in a structured form. This is just the one that interests me most initially. As far as readability goes, having the base document gives me the ability to generate whatever format I find most convenient to view documents. That's a big readability boost in my book. In particular, generated HTML versions can include useful hyperlinks. Ned
RE: A modest proposal - allow the ID repository to hold xml
Paul Hoffman / IMC writes: At 1:22 PM -0400 9/2/03, Rosen, Brian wrote: 2) Ability to cross reference documents That benefit only appears if all, or a significant proportion, of the Internet Drafts are in XML or a similar format. That's not what you proposed. It seems to me that a fairly simple hack could be consed up to generate HTML or whatever for current RFC's and drafts given .txt input which automatically goes the through the references section to make hyperlinks. In fact that would be a pretty nifty feature regardless of this debate... Mike
Re: A modest proposal - allow the ID repository to hold xml
-BEGIN PGP SIGNED MESSAGE- IMC == IMC Paul writes: I think there are quite a few reasons. Mine are: 1) Ability to render in alternate ways to improve readability and accessibility IMC Please be more specific on accessibility. Which groups of people IMC are currently excluded, or would be much more included with XML IMC documents? Not clear to me, but it certainly makes it easier to steal good formatting from other drafts :-) 2) Ability to cross reference documents IMC That benefit only appears if all, or a significant proportion, of the IMC Internet Drafts are in XML or a similar format. That's not what you IMC proposed. We presently have all of the RFCs in referenceable form. Many IDs are available in XML, but we can't find them, so we have to make new XML biblio files. 3) More uniformity in, e.g. references IMC In what way is that helpful? Are there kinds of references commonly IMC used now that don't work well? It makes referencing documents very easy. ] Out and about in Ottawa.hmmm... beer.| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian/notebook using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1TmioqHRg3pndX9AQGlkAP+MZdnFeIpvuONPRxu1djpySbp5csAsKBN so7z7yvAAC2oHAwru0zFJp9ytUHs+dd08owRDIYlZZKi14PH/dZPoGg2TKg8loN2 vhbNeckl/vPiTnaRjl1E+pSL+q34TpEFkV+aOnp7+dxjWXNGVoUCsdq6N+nhJybS YaipIwEbtmE= =SIoW -END PGP SIGNATURE-
Re: A modest proposal - allow the ID repository to hold xml
I'll give you one good reason. And that is updating the drafts once the initial RFC is published. If the origional XML/.doc/input language of the day is available, then I don't have to spend my time converting the text into a usable form to get the formating done easily. For this reason only, having origional input would be useful. (Yes I know, I can always go ask the origional editor for the input source, but that may take time locating that person and getting access to the input doc) Bill On Tue, Sep 02, 2003 at 11:19:29AM -0700, Paul Hoffman / IMC wrote: At 10:47 AM -0700 9/2/03, Eliot Lear wrote: I don't know about about you, Paul, but I'm writing my drafts using EMACS and Marshall's tool. That allows for generation of HTML, NROFF, and text. The HTML allows for hyperlinks, which is REALLY nice. Great! Why does that mean that the XML input should be published in the Internet Drafts directory along with the text output? --Paul Hoffman, Director --Internet Mail Consortium
Re: A modest proposal - allow the ID repository to hold xml
You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability. While I normally run in horror from all things XML, this is one of the few exceptions. XML would immediately solve a number of problems I face almost daily: - give me a list of all the documents belonging to a particular WG - for any given RFC, show me the chain of document dependencies (obsoletes, updated by, obsoleted by) that pass through this document - for any given RFC, generate a dependency graph based on the normative references in this document You have to have a structured document format to programmatically solve these sorts of problems, and XML provides that. (While I've become quite adept at searching rfc-index.txt with less, I really want something better.) And I second Ned's comments about generating *useful* diffs between document revisions. This is especially useful if we generate drafts in XML format. I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) And just to eliminate any lingering doubt, I'll note that I'm now using xml2rfc for all my current and future drafts. (There, *that* just gave several people heart attacks ;-) --lyndon
RE: A modest proposal - allow the ID repository to hold xml
Paul Hoffman / IMC writes: At 1:22 PM -0400 9/2/03, Rosen, Brian wrote: 2) Ability to cross reference documents That benefit only appears if all, or a significant proportion, of the Internet Drafts are in XML or a similar format. That's not what you proposed. It seems to me that a fairly simple hack could be consed up to generate HTML or whatever for current RFC's and drafts given .txt input which automatically goes the through the references section to make hyperlinks. In fact that would be a pretty nifty feature regardless of this debate... Such hacks already exist http://www.apps.ietf.org/rfc/ and work fairly well for the more recent RFCs, which follow a fairly regular set of formatting rules. But internet-drafts are sufficiently irregular in format that this approach doesn't seem to work all that well. And why should you have to guess when you don't have to? Ned
Re: A modest proposal - allow the ID repository to hold xml
-BEGIN PGP SIGNED MESSAGE- Lyndon == Lyndon Nerenberg [EMAIL PROTECTED] writes: Lyndon - give me a list of all the documents belonging to a particular Lyndon WG Ironically, it is easier with IDs than RFCs :-) Lyndon - for any given RFC, show me the chain of document dependencies Lyndon (obsoletes, updated by, obsoleted by) that pass through this Lyndon document Lyndon - for any given RFC, generate a dependency graph based on the Lyndon normative references in this document ... Lyndon I'm not sure how to address the problem with legacy RFCs. I'll Lyndon bet we could find volunteers to generate XML equivalents from the For this kind of thing, you don't need the entire document in XML, just the references I believe that all of the RFCs have been converted such that they can be referenced. Adding what they reference wouldn't be that hard at this point. Lyndon And just to eliminate any lingering doubt, I'll note that I'm now Lyndon using xml2rfc for all my current and future drafts. (There, Lyndon *that* just gave several people heart attacks ;-) ] Out and about in Ottawa.hmmm... beer.| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian/notebook using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1UNCIqHRg3pndX9AQHEOwP8CcwObPWYdXkzHkQk0EoQ3qtkUEOq+1PW G483bW66OqLShldAeZEwJHFMgu1RDz1fMY/i4ylNq/62IP6Jxr30/QleAVQ7DsVL 64MyzR4XOK/OQjlgtiyE88hzou9vPwuwOUkw2awjtDRQVn09PjcMFPHxWXKTzGYD R1IUCKC5KRg= =IhDN -END PGP SIGNATURE-
A modest proposal - allow the ID repository to hold xml
Rosen, Brian wrote:Allow the submission of an xml file meeting the requirements of RFC2629along with the text file (and optional ps file) for an Internet Draft. I totally agree with it.RFC2629 may be something need improvement.Now some protocols arecompletely written in XML schema,like UDDI.Even now I have to find how to use the nroff.I can't find its window version.It just give us some inconvenience. you will find search in XML is easier than in any other formats,if you have ever made some programs about it.XML may be the mostefficientmethod to describea protocol,how can we refuse it. Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: A modest proposal - allow the ID repository to hold xml
Michael Thomas wrote: Paul Hoffman / IMC writes: At 1:22 PM -0400 9/2/03, Rosen, Brian wrote: 2) Ability to cross reference documents That benefit only appears if all, or a significant proportion, of the Internet Drafts are in XML or a similar format. That's not what you proposed. It seems to me that a fairly simple hack could be consed up to generate HTML or whatever for current I'd very much like to allow the submission of XML to the I-D directories. However, in addition I'd like to actually allow the submission of HTML, generated by xml2rfc. Why? Because I'd really like to browse most drafts through my browser, jump to sections, find the references easily etc. And without performing any extra steps by myself. (It may be that this is possible via XML as well -- I'm not expert in XML so I can't tell if its readily supported by everyone's browser without loading lots of DTDs. Does someone know?) And all of these submission formats should be allowed if and only there's a text version to go with it. --Jari
