Re: A plug for XXE (Re: Alternative formats for IDs)
Seconded. I *have* used it for a production run and whilst it is not perfect it makes document creation and editing significantly easier than typing 'raw' xml even into a syntax-aware text editor. It is also very helpful for proof reading and commenting (spell checker provided). And the standard version is free.. and supported on Windows, Linux and Mac. I used to use the Word template but the freedom from hassle of generating the final documents, the ease of generating references and support of complex numbered lists (almost impossible to achieve in Word) makes xxe/xml2rfc my current tool chain of choice and means I am never going back to Word. Regards, Elwyn (addict) Harald Tveit Alvestrand wrote: --On 13. januar 2006 11:44 -0800 Joe Touch [EMAIL PROTECTED] wrote: This is my impression, from trying to use it as well. I was troubled by 'yet another embedded text system' that necessitated editing source, which seemed like a stone-age throwback when I abandoned such systems in the mid 1980s (Scribe, nroff, etc. at the time). While I appreciate that, in theory: 1. there are WYSIWYG XML editors that *can* be loaded with DTDs 2. Word et al. are moving to XML Bill Fenner has made a plugin available for the XMLMind XML Editor that gives you a lot of assistance in writing XML2RFC documents. I haven't used it for production yet, but it looks wonderful - not WYSIWYG, but WYSIPU - What You See Is Pretty Useful. Details on http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Ted Faber wrote: On Fri, Jan 13, 2006 at 12:07:21PM -0800, Dave Crocker wrote: Equating the XML communities and the xml2rfc communities is not correct. Actually, it is. xml2rfc uses some tailored dtd/xslt files. They semantics in them is significant but what is far more important is the xml infrastructure that is available, in terms of expertise and tools. The xml2rfc tool that I am familiar with (available from here: http://xml.resource.org/ ) formats the text itself, without using standard xslt (or dsssl or any standard formatting language). Unless I'm really misreading it, it's a 13,000 line tcl script that does all its own text/html/nroff formatting. I don't think tcl code is an XML standard. I was operating under the assumption that rfc2xml from the above site is the program you were talking about. A system that produces RFC output from the xml2rfc markup using only (or even primarily) standard, well-supported XML parsing and formatting tools would make the communities much more congruent and reap the obvious benefits. That's not the tool I see in operation today. ... That's correct, in that the only xml2rfc processor that currently produces usable ASCII output is the TCL version maintained by MTR and Charles Levert. There are other xml2rfc processors that are useful during the editing stage, such as rfc2629.xslt that allows you to open a text editor and a browser and basically gives you a nearly instantaneous (depending on browser and CPU power) preview of an HTML version of the text. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A plug for XXE (Re: Alternative formats for IDs)
Seconded. I *have* used it for a production run and whilst it is not perfect it makes document creation and editing significantly easier than typing 'raw' xml even into a syntax-aware text editor. It is also very helpful for proof reading and commenting (spell checker provided). And the standard version is free.. and supported on Windows, Linux and Mac. I used to use the Word template but the freedom from hassle of generating the final documents, the ease of generating references makes xxe/xml2rfc and support of complex numbered lists (almost impossible to achieve in Word) means I am never going back. Regards, Elwyn (addict) Harald Tveit Alvestrand wrote: --On 13. januar 2006 11:44 -0800 Joe Touch [EMAIL PROTECTED] wrote: This is my impression, from trying to use it as well. I was troubled by 'yet another embedded text system' that necessitated editing source, which seemed like a stone-age throwback when I abandoned such systems in the mid 1980s (Scribe, nroff, etc. at the time). While I appreciate that, in theory: 1. there are WYSIWYG XML editors that *can* be loaded with DTDs 2. Word et al. are moving to XML Bill Fenner has made a plugin available for the XMLMind XML Editor that gives you a lot of assistance in writing XML2RFC documents. I haven't used it for production yet, but it looks wonderful - not WYSIWYG, but WYSIPU - What You See Is Pretty Useful. Details on http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A plug for XXE (Re: Alternative formats for IDs)
Harald Tveit Alvestrand wrote: --On 13. januar 2006 11:44 -0800 Joe Touch [EMAIL PROTECTED] wrote: This is my impression, from trying to use it as well. I was troubled by 'yet another embedded text system' that necessitated editing source, which seemed like a stone-age throwback when I abandoned such systems in the mid 1980s (Scribe, nroff, etc. at the time). While I appreciate that, in theory: 1. there are WYSIWYG XML editors that *can* be loaded with DTDs 2. Word et al. are moving to XML Bill Fenner has made a plugin available for the XMLMind XML Editor that gives you a lot of assistance in writing XML2RFC documents. I haven't used it for production yet, but it looks wonderful - not WYSIWYG, but WYSIPU - What You See Is Pretty Useful. Pretty useful compared to text-editing the source code, yes. Compared to WYSIWYG, still primitive, unfortunately. If the goal is to allow the output - i.e., the RFC - to be useful for data mining, why not allow the XML tags to be used *just* for the portions that we expect to extract (i.e., for the data to be mined), and let WYSIWYG editors format the rest of the document structure. I.e., let each tool be used where it works? That would allow us to generate the documents with whatever editor we wanted, in whatever format we wanted, so long as the mined data were extractable as ASCII text *with* XML tags. At that point, the choice of archive format is decoupled from the decision of the editor, which it should be IMO. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A plug for XXE (Re: Alternative formats for IDs)
--On 13. januar 2006 22:40 -0800 Joe Touch [EMAIL PROTECTED] wrote: I haven't used it for production yet, but it looks wonderful - not WYSIWYG, but WYSIPU - What You See Is Pretty Useful. Pretty useful compared to text-editing the source code, yes. Compared to WYSIWYG, still primitive, unfortunately. If the goal is to allow the output - i.e., the RFC - to be useful for data mining, why not allow the XML tags to be used *just* for the portions that we expect to extract (i.e., for the data to be mined), and let WYSIWYG editors format the rest of the document structure. I.e., let each tool be used where it works? FWIW - I hate WYSIWYG with a passion. I *never* want to consider pages, fonts, indentation, section numbers or justification when I'm typing. I want to get the text in there, mark clearly where the sections are, make my lists as lists, and *get the text written*. Then I want to get it readable with minimal effort - and be able to change it later *without* having to guess at the difference between a section heading and a line that just happens to start with a number. Semantic markup works for me - for the *whole* document. But YMMV. pgpLNuO3prA40.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A plug for XXE (Re: Alternative formats for IDs)
Harald Tveit Alvestrand wrote: --On 13. januar 2006 22:40 -0800 Joe Touch [EMAIL PROTECTED] wrote: I haven't used it for production yet, but it looks wonderful - not WYSIWYG, but WYSIPU - What You See Is Pretty Useful. Pretty useful compared to text-editing the source code, yes. Compared to WYSIWYG, still primitive, unfortunately. If the goal is to allow the output - i.e., the RFC - to be useful for data mining, why not allow the XML tags to be used *just* for the portions that we expect to extract (i.e., for the data to be mined), and let WYSIWYG editors format the rest of the document structure. I.e., let each tool be used where it works? FWIW - I hate WYSIWYG with a passion. I *never* want to consider pages, fonts, indentation, section numbers or justification when I'm typing. I want to get the text in there, mark clearly where the sections are, make my lists as lists, and *get the text written*. Then I want to get it readable with minimal effort - and be able to change it later *without* having to guess at the difference between a section heading and a line that just happens to start with a number. I agree completely. Everything you're describing is a function of WYSIWYG with named styles - which is what it has been for 20+ years, rather than just make this bold, make this 12pt. That's the WYSIWYG I was assuming (style-WYSIWYG?). Every system I've seen to date for XML tries very hard to approach what S-WYSIWYG was capable of 20+ years ago. While some XML editors are certainly better than editing source, it's nowhere near as capable as S-WYSIWYG. Semantic markup works for me - for the *whole* document. Agreed, but my point is that there's no reason to force each of us to use a particular semantic markup where the semantics of the result are not relevant. There's no utility to plowing through all the markup associated with lists and headings, when that's not what data needs to be mined. What I'm proposing is that RFCs use text/PDF/PS as the archived, authoritative file (sure - we can argue about which of those three, or maybe others), but that to extract MIBs/authors/references those tags need to be in the authoritative version, but the others do not. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A plug for XXE (Re: Alternative formats for IDs)
Elwyn Davies wrote: Seconded. I *have* used it for a production run and whilst it is not perfect it makes document creation and editing significantly easier than typing 'raw' xml even into a syntax-aware text editor. It is also very helpful for proof reading and commenting (spell checker provided). And the standard version is free.. and supported on Windows, Linux and Mac. I used to use the Word template but the freedom from hassle of generating the final documents I'm not sure what freedom this means; XML still needs to run through a script, just as Word does. the ease of generating references Commercial software allows BIBTEX references to be imported into citation databases, so this is moot as well. makes xxe/xml2rfc and support of complex numbered lists (almost impossible to achieve in Word) I checked your three current I-Ds and five RFCs, and the most complex numbering I saw was G1, G2, ..., P1, P2..., and paragraphs numbered G.1:, G.2: Word has been able to handle all of these since the late 1980's. Was there a more complex example I missed, or one in a pending document that hasn't been issued that you could give as an example? Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A plug for XXE (Re: Alternative formats for IDs)
Joe Touch wrote: Elwyn Davies wrote: I used to use the Word template but the freedom from hassle of generating the final documents I'm not sure what freedom this means; XML still needs to run through a script, just as Word does. you can't do it from inside Word and in my experience the Word process broke about 80% of the time (mostly due to the generic text printer being horribly buggy) but maybe it is better now since I gave up with Word some time ago. [Microsoft were never interested in fixing these bugs - reducing some lines to heights of a fraction of a point and rendering one character per line in an apparently random fashion - and they persisted across multiple releases of Word.] the ease of generating references Commercial software allows BIBTEX references to be imported into citation databases, so this is moot as well. I am sure I could buy some tools but how well integrated with Word would this be and how much would it cost me? makes xxe/xml2rfc and support of complex numbered lists (almost impossible to achieve in Word) I checked your three current I-Ds and five RFCs, and the most complex numbering I saw was G1, G2, ..., P1, P2..., and paragraphs numbered G.1:, G.2: Word has been able to handle all of these since the late 1980's. Was there a more complex example I missed, or one in a pending document that hasn't been issued that you could give as an example? In theory.. my experience was that multiple sets of numbered paragraphs spread across sections was painful and error prone. But ultimately it was just the level of repeated niggles and panics when conversion fails close to the I-D deadline that I don't get with xml2rfc and especially with xxe. Don't let me stop you using Word but I know which set of tools I prefer. Elwyn Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Offtopic: Alternative XML markup RE: Alternative formats for IDs
I think that a lot of the objections made against XML/HTML vs nroff are ultimately due the fact that adding end elements as well as start elements makes for twice the work. One way around this is to use better editing tools. I remain consistently disappointed by the XML editing tools I have tried. Another approach I have been experimenting with is to drop in an alternative lexical analyzer into an existing XML parser. Instead of the 'strict' format required by the specification the lexer has a bunch of intelligent rules to make the process of editing less tedious. For example the feature I like of Wikipedia markup is that paragraph breaks are automatically infered from a blank separating line (i.e. look for nl ws* nl). Other obvious changes are to get rid of namespace prexixes unless there is actual ambiguity, to automatically infer end tags at paragraph breaks and to allow / as a means of closing the current lexical context. In the rare case that block structure is actually needed beyond this explicit blocking can be used. The feature of wikipedia markup that I do not like is the fact that the markup soon becomes unweildy once you go beyond the most commonly used features. I don't know many people who can use the wiki table markup for example. I am currently experimenting with a markup where elements and attributes have the same consistent syntax p color=red becomes p color red In short we end up more or less back to S-expressions with angle brackets instead of round ones. The main difference is that in document structure it is really not necessary to throw in all the close tags, they only distract. If something can be infered then infer it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Friday, January 13, 2006 12:44 AM To: Bill Fenner Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: Alternative formats for IDs I don't think that converting to xml is the same class of work. There's a great deal of semantic information that should be encoded in the XML that isn't in the submitted text and doesn't have to be in the nroff. Strictly speaking, you are certainly right. But I lived with nroff for quite a few years and I have had to do quite a few txt-2-xml2rfc conversions recently. The difference in semantic encoding, that you cite, is offset by how easily nroff formatting errors can be made and not readily detected. Mostly, this sort of conversion work has a small, relatively standardized vocabulary of text to add or change and one gets into a rhythm. From that perspective, I suspect the work is about the same. The real difference is that debugging the xml2rfc conversion is probably MUCH easier. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Bob Braden wrote: Suppose that we edit the document in XML (we are already doing this part of the time), do a final nroffing pass to get the format just right, and then give the author(s) the edited xml, ... We have to make a new nroff version and PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME. Now, this may not actually be too bad; most of the changes at the nroff stage are very cosmetic Maybe we're attacking that part of it the wrong way. What is it that makes those cosmetic changes, to get the format just right, so important? Do we really care whether there's an extra blank line, or the indentation is one character too much? When I run xml2rfc and look at the results, the formatting looks just right to me, at least for any value of just right that I care about. Why does the IETF (or others) care for a greater value of just right? Or am I missing something basic in the formatting changes you're looking at, at that stage? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Jeffrey Hutzelman [EMAIL PROTECTED] writes: It sounds like an awful waste of time and effort to me. It seems like the more efficient approach would be to essentially have two stages, where the authors first sign off on the result of copy-editing, and then on whatever cosmetic changes are needed after the final conversion. It's worth mentioning that this is exactly how book publication works. Indeed, the copy-edit stage is often done on something with entirely different formatting from the final version (e.g., double-spaced). The proofreader is then responsible for ensuring that (1) Each proposed copy-edit change actually gets handled and (2) No superfluous changes are introduced in the typesetting/page layout stage. Then there's a final author approval of the galleys. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
It seems like the more efficient approach would be to essentially have two stages, where the authors first sign off on the result of copy-editing, and then on whatever cosmetic changes are needed after the final conversion. It's worth mentioning that this is exactly how book publication works. Exactly right. So, the question is whether the IETF needs to use an operational model that guarantees certain, high overhead, or whether we can enjoy a model that permits us to move much of the grunt work out to the authors. (Interestingly, we can have the second-stage copy-editing either way, but with far more of the grunt work done by authors, for one of the models.) The quality of the copy-editing that the rfc editor does is quite high. But it also imposes a very high aggregate cost on the IETF. Do we *really* need to spend that money, for that benefit? d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ted Faber wrote: On Thu, Jan 12, 2006 at 04:22:53PM -0800, Dave Crocker wrote: Maintaining xml2rfc is going to far less fragile than maintaining nroff. Nroff has no current industry penetration. XML has quite a lot. I'd be cautious here. Equating the XML communities and the xml2rfc communities is not correct. There's an important distinction between the XML meta-language and the xml2rfc language and its associated formatting tools. Lots of places express languages in XML DTDs and use one of the many XML parsers in their tools to parse those DTDs. That widespread adoption of the meta-language and the resultant support for XML parsing libraries in a large number of implementation languages and environments does simplify the specification of the xml2rfc language and the generation and maintenance of the xml2rfc program. However, the actual community of that uses the XML-based RFC authoring tools is a subset of the contributors to the IETF; the maintainers of the xml2rfc formatter(s) are a subset of that. That smaller community is the one that is needed to keep a working xml2rfc language and formatting program available to the IETF. It's by no means obvious to me that xml2rfc has reached a critical mass of developers and users, nor that it will necessarily do so organically. This is my impression, from trying to use it as well. I was troubled by 'yet another embedded text system' that necessitated editing source, which seemed like a stone-age throwback when I abandoned such systems in the mid 1980s (Scribe, nroff, etc. at the time). While I appreciate that, in theory: 1. there are WYSIWYG XML editors that *can* be loaded with DTDs 2. Word et al. are moving to XML it's worth noting that: (1) requires users to enter data into XML fields, which can be very tedious. it also assumes that the XML editor can be loaded with the current IETF RFC DTD, which is by no means guaranteed or easy (2) AFAICT, Word uses its own DTD, and isn't particularly cooperative with using your own (I've asked others on the tools list about this, and they have had similar experience) ... All that said, I do think that an XML-based encoding of RFC contents is a good idea I do not; there is very little in RFCs that needs to be tagged except: MIBs lists of authors lists of references I can't see why pushing the whole document into 'yet another tagged data format' does anything for the utility of the remainder. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDyAMoE5f5cImnZrsRAjRYAKCjPWwgFL5CvOksicDDWC3RRMrKPACg2+Sm +PyT8AAXATtZN3fps0K9ezI= =rR0F -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
In message [EMAIL PROTECTED], Eric Rescorla writes: Jeffrey Hutzelman [EMAIL PROTECTED] writes: It sounds like an awful waste of time and effort to me. It seems like the more efficient approach would be to essentially have two stages, where the authors first sign off on the result of copy-editing, and then on whatever cosmetic changes are needed after the final conversion. It's worth mentioning that this is exactly how book publication works. Indeed, the copy-edit stage is often done on something with entirely different formatting from the final version (e.g., double-spaced). The proofreader is then responsible for ensuring that (1) Each proposed copy-edit change actually gets handled and (2) No superfluous changes are introduced in the typesetting/page layout stage. Then there's a final author approval of the galleys. Right. And I've heard authors gripe that they wrote their books with state-of-the-art distributed systems and version control, but because the publisher's typesetting was done on a different, incompatible system, the copy-edit changes were not fed back into the authors' system, making any second edition much more difficult. AUTH48 is often quite prolonged and painful -- and I've experienced this as an author, WG chair, and AD. Let's not make it any worse. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Agree with Barry that we need to balance things wisely. If we are routinely taking up RFC-Editor resources for cosmetic reformatting of XML2RFC output, I'm thinking that this is not a good use of resources. If someone submitted one XML2RFC input that triggered some XML2RFC boundary condition bug and caused a blank page to be emitted in the middle of a document, maybe it's better to quickly fix the output than to fix XML2RFC, but I'd really like to get to the point where there is no reformatting of XML2RFC output for most/all XML2RFC input files that were submitted for publication as RFCs. Thanks, Spencer From: Barry Leiba [EMAIL PROTECTED] Bob Braden wrote: Suppose that we edit the document in XML (we are already doing this part of the time), do a final nroffing pass to get the format just right, and then give the author(s) the edited xml, ... We have to make a new nroff version and PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME. Now, this may not actually be too bad; most of the changes at the nroff stage are very cosmetic Maybe we're attacking that part of it the wrong way. What is it that makes those cosmetic changes, to get the format just right, so important? Do we really care whether there's an extra blank line, or the indentation is one character too much? When I run xml2rfc and look at the results, the formatting looks just right to me, at least for any value of just right that I care about. Why does the IETF (or others) care for a greater value of just right? Or am I missing something basic in the formatting changes you're looking at, at that stage? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Equating the XML communities and the xml2rfc communities is not correct. Actually, it is. xml2rfc uses some tailored dtd/xslt files. They semantics in them is significant but what is far more important is the xml infrastructure that is available, in terms of expertise and tools. I now produce drafts using an off-the-shelf xml tool that take the standard-form xml2rfc dtd and xslt files and produce excellent output. (To be entirely fair, yes, there is some special software that produces the txt version.) The xml tool and knowledge of xml are broadly applicable, and growing. Knowledge of nroff is now sufficiently obscure as to be beyond mere characterization as marginalized. A word like archaic is more appropriate. And by the way, please note that the use of nroff for rfcs also requires special conventions. What is important is not the files used to tailor the production service, but the prevalence of expertise and tools for that service. In reality, nroff expertise is isolated in a tiny community. In reality, xml expertise has become global. That's not an assessment of hypothetical, future adoption. It is an assessment of *existing* adoption. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Steven M. Bellovin [EMAIL PROTECTED] writes: Right. And I've heard authors gripe that they wrote their books with state-of-the-art distributed systems and version control, but because the publisher's typesetting was done on a different, incompatible system, the copy-edit changes were not fed back into the authors' system, making any second edition much more difficult. Fair enough, but consider that this problem already exists in the RFC-Ed system because the RFC-Ed's final version is in a set of tools that almost nobody uses. This includes many nroff users, btw, because the RFC-Ed's nroff is too primitive to really edit with yourself. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Agree with EKR that such a two-stage author review SHOULD make sense, and if our median time in AUTH48 wasn't something like 10 days now[1], I'd be a lot more excited about adopting this and going through AUTH48 (or its nearest equivalent) twice ... :-( Spencer [1] ftp://ftp.rfc-editor.org/in-notes/IETFreports/2005/ietf64-report.pdf and http://www3.ietf.org/proceedings/05nov/slides/plenaryw-2.pdf Jeffrey Hutzelman [EMAIL PROTECTED] writes: It sounds like an awful waste of time and effort to me. It seems like the more efficient approach would be to essentially have two stages, where the authors first sign off on the result of copy-editing, and then on whatever cosmetic changes are needed after the final conversion. It's worth mentioning that this is exactly how book publication works. Indeed, the copy-edit stage is often done on something with entirely different formatting from the final version (e.g., double-spaced). The proofreader is then responsible for ensuring that (1) Each proposed copy-edit change actually gets handled and (2) No superfluous changes are introduced in the typesetting/page layout stage. Then there's a final author approval of the galleys. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Maybe we're attacking that part of it the wrong way. What is it that makes those cosmetic changes, to get the format just right, so important? Do we really care whether there's an extra blank line, or the indentation is one character too much? Well, yes, we do. At least, the RFC Editor cares, and we believe you should care too. Blank lines are not just randomly inserted... they are put in to enhance readability, and they can make a significant difference. RFCs are input to human readers, not machines. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Maybe we're attacking that part of it the wrong way. What is it that makes those cosmetic changes, to get the format just right, so important? Do we really care whether there's an extra blank line, or the indentation is one character too much? Well, yes, we do. At least, the RFC Editor cares, and we believe you should care too. Blank lines are not just randomly inserted... they are put in to enhance readability Oh, sure, I get that, and I'm not suggesting that we ignore that. I'm asking this: If the author and the last-call commentors think the output of xml2rfc looks good, what is that that you tweak with nroff that's necessary at that point? When you say that you make cosmetic changes beyond what's been done with xml2rfc, and agreed to by those who've reviewed it, I presume you're making stylistic changes that the RFC editor cares about that we didn't (if we did, we'd have already made those changes). I'm wonder what sorts of things those are, and whether they're really worth all the extra overhead. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
(clipped down to) Maybe we're attacking that part of it the wrong way. What is it that makes those cosmetic changes, to get the format just right, so important? Do we really care whether there's an extra blank line, or the indentation is one character too much? Well, yes, we do. At least, the RFC Editor cares, and we believe you should care too. Blank lines are not just randomly inserted... they are put in to enhance readability When you say that you make cosmetic changes beyond what's been done with xml2rfc, and agreed to by those who've reviewed it, I presume you're making stylistic changes that the RFC editor cares about that we didn't (if we did, we'd have already made those changes). I'm wonder what sorts of things those are, and whether they're really worth all the extra overhead. ... and whether it would be good if the working group had been reviewing a more-readable version of the document, and had forwarded a more-readable version for last call and IESG review... Given that the RFC Editor has published more documents than I've written in my life, I don't question what's being done. I'm just asking if it might be done automatically, and be done earlier in the process. I'm guessing these are changes that the RFC Editor has been feeding to the XML2RFC authors via Bill Fenner in http://rtg.ietf.org/Members/BillFenner/rfced-xml/FrontPage/issuetracker, and that we're moving closer to fire and forget XML2RFC operation, so maybe all is well, or at least improving? Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Spencer Dawkins Agree with Barry that we need to balance things wisely. If we are routinely taking up RFC-Editor resources for cosmetic reformatting of XML2RFC output, I'm thinking that this is not a good use of resources. I heartily agree. I find it completely bizare that we have people saying that TXT is good enough then say that the process has to allow for pretification. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On Jan 13, 2006, at 12:07 PM, Dave Crocker wrote: What is important is not the files used to tailor the production service, but the prevalence of expertise and tools for that service. In reality, nroff expertise is isolated in a tiny community. In reality, xml expertise has become global. That's not an assessment of hypothetical, future adoption. It is an assessment of *existing* adoption. Agreed. Adopting an XML structure for the creation of RFCs and related documents should be moving in the right direction. At some point, even removing nroff as a crutch may ensure greater conformity for tools used to process documents. Although nroff is an extremely powerful and efficient word processing application, building upon more versatile and hierarchical structures offers many possibilities for managing the growing complexity of information being amassed. Both approaches requires post processing together with the cut and paste of some templates. As long as xml2rfc allows a means to bypass formatting difficulties in getting a good looking draft, regardless whether this requires 120 characters or 12, the end results in text form of either process _can_ be identical. Cut and paste does not take much effort either way, and even the clumsiness for some operations in xml2rfc can be readily overcome. XML data structures enable new features with less effort, like automatic generation of bibliographies or the insertion of hyperlinks in html output versions. XML also has the ability to add new elements to accommodate new features without disrupting other forms of output. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Right. And I've heard authors gripe that they wrote their books with state-of-the-art distributed systems and version control, but because the publisher's typesetting was done on a different, incompatible system, the copy-edit changes were not fed back into the authors' system, making any second edition much more difficult. AUTH48 is often quite prolonged and painful -- and I've experienced this as an author, WG chair, and AD. Let's not make it any worse. If by worse you mean I'll get back the vast majority of changes in the form of a revised version of the XML file I handed in, which I can then edit and send back, saving me hours of work retrofitting the changes into my copy, them I'm for making this as worse as possible. In my case at least this changes the first pass of AUTH48 to a simple differences check-and-merge. I do these routinely, often on much larger documents than any RFC I've written, and it is rare for the process to take more than 15-20 minutes. (It does help to have sharp tools for this: BBEdit in my case.) In contrast, the two recent RFCs I recently dealt with required several hours of work apiece. That pushes things from an activity I can pretty much squeeze in anywhere to one I have to budget time for, and that in turn tends to stretch AUTH48 into the realm of AUTH96 or even more. As long as the second pass doesn't involve wording changes I don't anticipate it taking very long. I view layout as the RFC Editor's for the most part. Bottom line: This will be a HUGE improvement for anyone that uses xml2rfc. I would not be adverse to retaining the old process for RFCs submitted to the editor as ASCII text, but holding xml2rfc users hostage to the old way of working makes no sense whatsoever. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On Fri, Jan 13, 2006 at 12:07:21PM -0800, Dave Crocker wrote: Equating the XML communities and the xml2rfc communities is not correct. Actually, it is. xml2rfc uses some tailored dtd/xslt files. They semantics in them is significant but what is far more important is the xml infrastructure that is available, in terms of expertise and tools. The xml2rfc tool that I am familiar with (available from here: http://xml.resource.org/ ) formats the text itself, without using standard xslt (or dsssl or any standard formatting language). Unless I'm really misreading it, it's a 13,000 line tcl script that does all its own text/html/nroff formatting. I don't think tcl code is an XML standard. I was operating under the assumption that rfc2xml from the above site is the program you were talking about. A system that produces RFC output from the xml2rfc markup using only (or even primarily) standard, well-supported XML parsing and formatting tools would make the communities much more congruent and reap the obvious benefits. That's not the tool I see in operation today. I'd be more likely to believe that the formatting was robust and that the system was maintainable if there was such a tool for the RFC editor to adopt. I'd also be more likely to believe your assertions that the toolchain was benefiting from the growing XML community. I now produce drafts using an off-the-shelf xml tool that take the standard-form xml2rfc dtd and xslt files and produce excellent output. (To be entirely fair, yes, there is some special software that produces the txt version.) The xml tool and knowledge of xml are broadly applicable, and growing. There's no need to copy IETFdom Assembled on this, but I'm curious what toolchain you're using and what limitations you've encountered. Knowledge of nroff is now sufficiently obscure as to be beyond mere characterization as marginalized. A word like archaic is more appropriate. And by the way, please note that the use of nroff for rfcs also requires special conventions. What is important is not the files used to tailor the production service, but the prevalence of expertise and tools for that service. In reality, nroff expertise is isolated in a tiny community. In reality, xml expertise has become global. That's not an assessment of hypothetical, future adoption. It is an assessment of *existing* adoption. You'll note that I make no assertions about the stability of nroff nor about the size of its user community in the message you're responding to. That was not accidental. If the only issue were the existence of a markup language that reliably produced plain text RFCs, I *would* be arguing that *roff would be sufficient if not optimal. The reson I'm studiously avoiding having that argument (and will continue to do so) is that I think changing to an RFC representation that is strictly a formatting language - like *roff - is not very interesting. If there's a benefit to be had, IMHO, it's from content-based markup. Right now the only serious contender I've heard for CBM of RFCs is rfc2xml (the language). And, IMHO, it's OKish. I think the tools and language will continue to improve. I don't feel confortable with their maturity to advocate for them now. (Again - I'm really not trying to run down xml2rfc. I think it's on the right track and I support the idea and the work. I'm an enthusiastic user.) I am looking forward to the day when we not only agree about where to go, but how to get there. :-) -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgphWwd5Vkbeg.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Joe Touch wrote: requires users to enter data into XML fields, which can be very tedious. it also assumes that the XML editor can be loaded with the current IETF RFC DTD, which is by no means guaranteed or easy Authors could create their own input format, transformed into the 2629bis XML by a script. Something like Wiki would be far more than good enough, and that's not very tedious. An XML editor not knowing the latest and greatest DTD would still guarantee proper nesting of tags. And if authors use US ASCII as document charset their worst problem would be to convince their XML editor that symbolic entities like nbhy; are no nonsense, but defined in the xml2rfc DTD. If authors use UTF-8 (or anything else that's not ASCII) they deserve to be in serious trouble for the resulting text/plain output, that's a point for the I18N considerations in a future 2629bis AFAICT, Word uses its own DTD, and isn't particularly cooperative with using your own Maybe Word isn't an ideal XML-editor then. Any decent text editor will do. If authors don't like vi or notepad they use something else. My favourite text editor is based on XEDIT, about 23 years old. I do think that an XML-based encoding of RFC contents is a good idea I do not; there is very little in RFCs that needs to be tagged except: MIBs lists of authors lists of references That list is not complete, e.g. you forgot to mention ABNF. Another point are the keywords for many RfCs, example: http://purl.net/net/rfc/2070 http://tools.ietf.org/html/2070 The latter tool doesn't see some meta-data like keywords, because it's not part of the ASCII version. But it's simple to specify meta-data in an XML version. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
I was operating under the assumption that rfc2xml from the above site is the program you were talking about. I use it, or a version that runs on windows, to create the txt output. But, no, it's not what I work with otherwise. What i work with normally is a commercial somewhat-wysiwyg xml editor that is driven by standard xml metafiles. I'd be more likely to believe that the formatting was robust and that the system was maintainable if there was such a tool for the RFC editor to adopt. There is. There's no need to copy IETFdom Assembled on this, but I'm curious what toolchain you're using and what limitations you've encountered. My impression is that there are now a number of entirely competent xml editing systems. I happen to use oXygen. If the only issue were the existence of a markup language that reliably produced plain text RFCs, the reason xml is interesting is that it makes editing easier, not just display. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On Fri, Jan 13, 2006 at 03:56:37PM -0800, Dave Crocker wrote: There's no need to copy IETFdom Assembled on this, but I'm curious what toolchain you're using and what limitations you've encountered. My impression is that there are now a number of entirely competent xml editing systems. I happen to use oXygen. Oxygen looks like an interesting tool, but I wasn't able to readily see that it applies stylesheets to XML to produce printable/readable documents. For example, can I go from a docbook document to cmaera-ready postscript/pdf using oxygen? Or xml2rfc - txt? If so, your argument is better than I thought; if not, I think that's a sign that we're not ready to move. Yet. I don't think editing systems by themselves are a reason to go to an XML format. Again, I think that making the RFC content and metadata available to both machines humans is facilitated by an XML format. [snip] the reason xml is interesting is that it makes editing easier, not just display. XML does not interest me for that reason. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpYn3SRM2eUd.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
A plug for XXE (Re: Alternative formats for IDs)
--On 13. januar 2006 11:44 -0800 Joe Touch [EMAIL PROTECTED] wrote: This is my impression, from trying to use it as well. I was troubled by 'yet another embedded text system' that necessitated editing source, which seemed like a stone-age throwback when I abandoned such systems in the mid 1980s (Scribe, nroff, etc. at the time). While I appreciate that, in theory: 1. there are WYSIWYG XML editors that *can* be loaded with DTDs 2. Word et al. are moving to XML Bill Fenner has made a plugin available for the XMLMind XML Editor that gives you a lot of assistance in writing XML2RFC documents. I haven't used it for production yet, but it looks wonderful - not WYSIWYG, but WYSIPU - What You See Is Pretty Useful. Details on http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ Harald pgpcSj9PEIbfC.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
Before I go on, I continue to be fascinated by the observation that, each time the we really need pictures and fancy formatting and need them frequently argument comes up, the vast majority of those who make it most strongly are people whose contributions to the IETF -- in designer, editor, or other leadership roles-- have been fairly minimal. This fascinates me too... With experience, I believe most people learn that the strict ASCII format used for RFC's is actually a strong feature of our ways of working. When I wrote my first drafts, I also believed non-ASCII graphics were needed and I made multiple versions (one TXT and one PS) of each draft, but I do not waste my time on that anymore since I have learned that I can manage very well without non-ASCII graphics. /L-E ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On 1/11/06, Henrik Levkowetz [EMAIL PROTECTED] wrote: the tools team has not received any feedback or comments from the RFC-Editor regarding the xml2rfc tool. If we had, we would have forwarded it to the xml2rfc list. Aaron (for the RFC Editor) asked me to proxy their findings, and I worked with Charles and Marshall directly instead of going through the list; perhaps this was a mistake. The comments from the RFC Editor can be found at http://rtg.ietf.org/Members/BillFenner/rfced-xml/FrontPage/issuetracker, and many of them are fixed in xml2rfc 1.31a4. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On 1/10/06, Paul Hoffman [EMAIL PROTECTED] wrote: At 9:45 AM -0500 1/10/06, Brian Rosen wrote: Do you have any idea how painful it is to build any kind of product that has good management simply because there is no library of MIBs, with references to documents? There isn't even a LIST of IETF MIBs. You can't figure out if a document has a MIB unless you actually look at the text (although many have a big hint in the title of the document). So yes, I believe better MIB tools would lead to better products, although it would be hard to prove it. Why does this need to be done in the RFCs or Internet Drafts themselves? Why, for example, can't a human with a bit of training extract all the MIBs from the current RFCs and put them into a repository that is machine-accessible? Something like http://www.icir.org/fenner/mibs/mib-index.html and http://www.icir.org/fenner/mibs/extracted/ ? Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
Lars-Erik Jonsson (LU/EAB) wrote: Before I go on, I continue to be fascinated by the observation that, each time the we really need pictures and fancy formatting and need them frequently argument comes up, the vast majority of those who make it most strongly are people whose contributions to the IETF -- in designer, editor, or other leadership roles-- have been fairly minimal. This fascinates me too... That is a completly inapproriate response to the issue at hand - in many dimensions. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
--On Thursday, 12 January, 2006 12:28 +0100 Lars-Erik Jonsson \\(LU/EAB\\) [EMAIL PROTECTED] wrote: Before I go on, I continue to be fascinated by the observation that, each time the we really need pictures and fancy formatting and need them frequently argument comes up, the vast majority of those who make it most strongly are people whose contributions to the IETF -- in designer, editor, or other leadership roles-- have been fairly minimal. This fascinates me too... With experience, I believe most people learn that the strict ASCII format used for RFC's is actually a strong feature of our ways of working. When I wrote my first drafts, I also believed non-ASCII graphics were needed and I made multiple versions (one TXT and one PS) of each draft, but I do not waste my time on that anymore since I have learned that I can manage very well without non-ASCII graphics. While I agree with you, I should stress that the authors of the current proposal have been much more in touch with IETF work and much more active than many of their predecessors. We also owe them thanks for actually preparing a proposal in I-D form rather than simply complaining about our antiquated methods on the mailing list. Most of the point I was trying to make was precisely the one you make, more appropriately, above: increasing experience within the IETF and with our style of developing and working on documents (not just publishing them) tends to cause both patience and respect for the ASCII graphics and formats to rise. Experience from other standards bodies or similar entities that work in different ways may or may not be a good basis for inference. best, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
On 1/12/06, John C Klensin [EMAIL PROTECTED] wrote: increasing experience within the IETF and with our style of developing and working on documents (not just publishing them) tends to cause both patience and respect for the ASCII graphics and formats to rise. I'm surprised folks are apologizing for the initial impression ASCII text gives, and that people feel MS Word or PDF would represent some sort of advance. I find both of those formats difficult to use, and my reaction when I see a spec in PDF or MS Word is to assume the responsible organization is clueless. The rare specification requiring elaborate illustrations would be better as HTML with a liberal sprinkling of fragment identifiers. -- Robert Sayre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On 2006-01-12 14:50 Bill Fenner said the following: Aaron (for the RFC Editor) asked me to proxy their findings, and I worked with Charles and Marshall directly instead of going through the list; perhaps this was a mistake. The comments from the RFC Editor can be found at http://rtg.ietf.org/Members/BillFenner/rfced-xml/FrontPage/issuetracker, and many of them are fixed in xml2rfc 1.31a4. Ah. Thank you. Good to see the issues. And in an issue tracker, even :-) Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
* From [EMAIL PROTECTED] Wed Jan 11 13:53:32 2006 * X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham *version=3.1.0 * Date: Wed, 11 Jan 2006 16:52:31 -0500 * From: John C Klensin [EMAIL PROTECTED] * To: Bob Braden [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] * cc: ietf@ietf.org * Subject: RE: Alternative formats for IDs * Content-Transfer-Encoding: 7bit * X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean * * * * --On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden * [EMAIL PROTECTED] wrote: * * * The RFC editor has some problems which have not, to my * knowledge, * been enumerated. ** * * Your knowledge is apparently incomplete. The RFC Editor has * been actively experimenting with using xml2rfc for * publication, and we have been passing our problems along to * the tools team. As we get more experience, new ones show up. * There is not currently a version of xml2rfc that meets our * needs. Some of our editors do the major editing in XML, but * Bob, * * Let me suggest a way to look at the above, deriving in large * measure from the experiences Ned Freed and I (mostly Ned, who * did the heavy lifting) had with what are now RFCs 4288 and 4289. * To the extent to which authors can hand XML to you, and get XML * back with whatever substantive/ editorial changes you have made, * it should ultimately not be a concern of anyone in the community * how you make the transition between the final XML, with all of * the text worked out, and the final formatting. In particular, * if that step requires you to convert the XML to nroff and then * massage the nroff, I don't think it should be an issue. The * issue arises from handing you a format that contains generic * markup and is editable but, because of your via nroff process, * requires authors to deduce substantive and editorial changes * from diffs and then retrofit them back into the XML for future * use. John, We have thought about what you suggest, and it may be workable. The problem with it is this: during the AUTH48 stage, we give the author(s) the exact final version ready for publication, for final verification. (There was a time when this was mostly pro forma, but for a variety of reasons, some good and some bad, the AUTH48 stagetoday not infrequently invovles significant changes to a document.) Suppose that we edit the document in XML (we are already doing this part of the time), do a final nroffing pass to get the format just right, and then give the author(s) the edited xml, final .txt, and a diff file. (We could easily do this today). The author(s) change the .xml (or give us a patch file for us to make the changes.) We have to make a new nroff version and PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME. Now, this may not actually be too bad; most of the changes at the nroff stage are very cosmetic, and we could use diffs and perhaps other tools to make it quite easy. OR, we could change the AUTH48 policy to let the author(s) deal only with the edited xml, without the final formatting cleanups. We would then translate to nroff and do the final formatting AFTER AUTH48. (Or, we could have two stages of AUTH48). Perhaps we should run some more experiments. Bob Braden for the RFC Editor ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Bob Braden wrote: ... Now, this may not actually be too bad; most of the changes at the nroff stage are very cosmetic, and we could use diffs and perhaps other tools to make it quite easy. OR, we could change the AUTH48 policy to let the author(s) deal only with the edited xml, without the final formatting cleanups. We would then translate to nroff and do the final formatting AFTER AUTH48. (Or, we could have two stages of AUTH48). Perhaps we should run some more experiments. I think, the latter (two stages) is clearly the best way to do that. I would appreciate it if this would be tried (optimally, with one of my documents :-). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Bob, Suppose that we edit the document in XML (we are already doing this part of the time), do a final nroffing pass to get the format just right, and then give the author(s) the edited xml, final .txt, and a diff file. (We could easily do this today). The author(s) change the .xml (or give us a patch file for us to make the changes.) We have to make a new nroff version and PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME. This sound like quite a good approach. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On Thursday, January 12, 2006 08:50:26 AM -0500 Bill Fenner [EMAIL PROTECTED] wrote: Aaron (for the RFC Editor) asked me to proxy their findings, and I worked with Charles and Marshall directly instead of going through the list; perhaps this was a mistake. I don't think so. In order to work correctly, our process requires that protocol design and decision-making be done in public. It does not require that bug reports be filed in public. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On Thursday, January 12, 2006 02:07:29 PM -0800 Dave Crocker [EMAIL PROTECTED] wrote: Bob, Suppose that we edit the document in XML (we are already doing this part of the time), do a final nroffing pass to get the format just right, and then give the author(s) the edited xml, final .txt, and a diff file. (We could easily do this today). The author(s) change the .xml (or give us a patch file for us to make the changes.) We have to make a new nroff version and PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME. This sound like quite a good approach. It sounds like an awful waste of time and effort to me. It seems like the more efficient approach would be to essentially have two stages, where the authors first sign off on the result of copy-editing, and then on whatever cosmetic changes are needed after the final conversion. In the few cases where I've had the chance to observe the AUTH48 process on a large, complex document (mostly as a WG chair), the majority of issues have been related to changes in wording the authors were unhappy with, missed spelling errors, etc. If these issues were resolved using only the XML and the output of xml2rfc, with the nroff and final text not being generated until the authors were happy with the copy, I'd bet that 95% of documents would result in no additional comments from the author based on the final text. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
John, Stewart and others, I believe some might have taken my previous note more personally than intended, as well as John's. As also made clear by John below, we both looked at this with a significantly longer time-perspective than just the last weeks or months, as these issues have been brought up many times before. I am sorry if someone felt insulted, that was for sure not the intent. It is good that we now have discussions trying to figure out actual cases when more graphics are *really* needed, then we might actually get out of these discussions with some new conclusions and agreements that can guide us on the way forward. Cheers, /L-E Original Message From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: den 12 januari 2006 17:41 To: Lars-Erik Jonsson (LU/EAB); Stewart Bryant Cc: Ash, Gerald R \(Jerry\); ietf@ietf.org Subject: RE: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)) --On Thursday, 12 January, 2006 12:28 +0100 Lars-Erik Jonsson \\(LU/EAB\\) [EMAIL PROTECTED] wrote: Before I go on, I continue to be fascinated by the observation that, each time the we really need pictures and fancy formatting and need them frequently argument comes up, the vast majority of those who make it most strongly are people whose contributions to the IETF -- in designer, editor, or other leadership roles-- have been fairly minimal. This fascinates me too... With experience, I believe most people learn that the strict ASCII format used for RFC's is actually a strong feature of our ways of working. When I wrote my first drafts, I also believed non-ASCII graphics were needed and I made multiple versions (one TXT and one PS) of each draft, but I do not waste my time on that anymore since I have learned that I can manage very well without non-ASCII graphics. While I agree with you, I should stress that the authors of the current proposal have been much more in touch with IETF work and much more active than many of their predecessors. We also owe them thanks for actually preparing a proposal in I-D form rather than simply complaining about our antiquated methods on the mailing list. Most of the point I was trying to make was precisely the one you make, more appropriately, above: increasing experience within the IETF and with our style of developing and working on documents (not just publishing them) tends to cause both patience and respect for the ASCII graphics and formats to rise. Experience from other standards bodies or similar entities that work in different ways may or may not be a good basis for inference. best, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Who is volunteering to maintain xml2rfc and guarantee backwards compatibility for the next 20 years? (And why should we believe them?) Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
* * 2. Given that the RFC Editor has the current practice of converting .txt * submissions to nroff, it is equally reasonable to pursue their changing that * conversion, to instead be into xml2rfc. Dave, Are you suggesting that the IETF adopt the xml2rfc source as the normative version of a specification, rather than the .txt (or .pdf) version? Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Are you suggesting that the IETF adopt the xml2rfc source as the normative version of a specification, rather than the .txt (or .pdf) version? yes. as I understand your current operation, the *real* normative version is in nroff. i believe that an incremental process of switching to xml2rfc -- with easy access to that source version for follow-on editing -- would be a considerable improvement over the status quo. Who is volunteering to maintain xml2rfc and guarantee backwards compatibility for the next 20 years? (And why should we believe them?) Maintaining xml2rfc is going to far less fragile than maintaining nroff. Nroff has no current industry penetration. XML has quite a lot. (Both are textual encodings, so that the fall-back position of reverting to pure text is probably equally painful.) d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
In message [EMAIL PROTECTED], Jeffrey Hutzelman writes: It seems like the more efficient approach would be to essentially have two stages, where the authors first sign off on the result of copy-editing, and then on whatever cosmetic changes are needed after the final conversion. That assumes that the xml-nroff conversion is always error-free. I think that that's an overassumption. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
It seems like the more efficient approach would be to essentially have two stages, where the authors first sign off on the result of copy-editing, and then on whatever cosmetic changes are needed after the final conversion. That assumes that the xml-nroff conversion is always error-free. I think that that's an overassumption. I've seen several cases where cosmetic changes introduced technical errors in a document. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On 1/11/06, Dave Crocker [EMAIL PROTECTED] wrote: 2. Given that the RFC Editor has the current practice of converting .txt submissions to nroff, it is equally reasonable to pursue their changing that conversion, to instead be into xml2rfc. I don't think that converting to xml is the same class of work. There's a great deal of semantic information that should be encoded in the XML that isn't in the submitted text and doesn't have to be in the nroff. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Dave sed: Nroff has no current industry penetration. fwiw - Nroff is on every Mac OSX shipped it is a shell procedure that fronts groff Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
I don't think that converting to xml is the same class of work. There's a great deal of semantic information that should be encoded in the XML that isn't in the submitted text and doesn't have to be in the nroff. Strictly speaking, you are certainly right. But I lived with nroff for quite a few years and I have had to do quite a few txt-2-xml2rfc conversions recently. The difference in semantic encoding, that you cite, is offset by how easily nroff formatting errors can be made and not readily detected. Mostly, this sort of conversion work has a small, relatively standardized vocabulary of text to add or change and one gets into a rhythm. From that perspective, I suspect the work is about the same. The real difference is that debugging the xml2rfc conversion is probably MUCH easier. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Randy.Dunlap wrote: On Tue, 10 Jan 2006, Brian E Carpenter wrote: ... What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. You can do that with meta-data encoded in plain ASCII. In fact, that would work better for automated extraction than anything visual such as using multiple fonts. code.../code Does the RFC editor accept HTML in plain ASCII RFCs? They accept ASCII. code looks like ASCII to me. Actually html looks like ASCII too :-) Seriously. If we want to embed metatdata tags in RFCs, we can just do it. Brian Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
* * Under those conditions, our precedents are that you can probably * convince the WG/WGchairs/ADs, and eventually the RFC Editor, * that a PDF document containing a picture of the Mona Lisa and an * ASCII document with * * _- * / \ * _ | o o | * | | | * | __ | * _ | | * \_/ * _ * | | | | * * as a substitute for that picture, with the marginal lines * roughly identifying your grid marks and coordinate system, is * equivalent or as close to it as one can get. John, AFAIK, there is one worked example of this ... RFC 1119 on NTP. Philosophers may speculate on the resemblance of NTP to the Mona Lisa... Bob Braden * * * ___ * Ietf mailing list * Ietf@ietf.org * https://www1.ietf.org/mailman/listinfo/ietf * ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
* I would like to enable automated testing of ABNF. Note that the RFC Editor has been running ABNF through an automated checker, for quite a long time. We find errors. RFC Editor/bb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
* From: Brian Rosen [EMAIL PROTECTED] * To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org * Date: Tue, 10 Jan 2006 20:13:35 -0500 *The RFC editor has some problems which have not, to my knowledge, * been enumerated. * Your knowledge is apparently incomplete. The RFC Editor has been actively experimenting with using xml2rfc for publication, and we have been passing our problems along to the tools team. As we get more experience, new ones show up. There is not currently a version of xml2rfc that meets our needs. Some of our editors do the major editing in XML, but they find it most efficient and effective to switch to nroff for the final cleanup of the (ASCII) document format. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
--On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden [EMAIL PROTECTED] wrote: * The RFC editor has some problems which have not, to my knowledge, * been enumerated. * Your knowledge is apparently incomplete. The RFC Editor has been actively experimenting with using xml2rfc for publication, and we have been passing our problems along to the tools team. As we get more experience, new ones show up. There is not currently a version of xml2rfc that meets our needs. Some of our editors do the major editing in XML, but they find it most efficient and effective to switch to nroff for the final cleanup of the (ASCII) document format. Bob, Let me suggest a way to look at the above, deriving in large measure from the experiences Ned Freed and I (mostly Ned, who did the heavy lifting) had with what are now RFCs 4288 and 4289. To the extent to which authors can hand XML to you, and get XML back with whatever substantive/ editorial changes you have made, it should ultimately not be a concern of anyone in the community how you make the transition between the final XML, with all of the text worked out, and the final formatting. In particular, if that step requires you to convert the XML to nroff and then massage the nroff, I don't think it should be an issue. The issue arises from handing you a format that contains generic markup and is editable but, because of your via nroff process, requires authors to deduce substantive and editorial changes from diffs and then retrofit them back into the XML for future use. Just my opinion, of course -- others may have other perspectives or agendas. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
* From: Brian Rosen [EMAIL PROTECTED] * To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org * Date: Tue, 10 Jan 2006 20:13:35 -0500 * The RFC editor has some problems which have not, to my knowledge, * been enumerated. * Your knowledge is apparently incomplete. The RFC Editor has been actively experimenting with using xml2rfc for publication, and we have been passing our problems along to the tools team. As we get more experience, new ones show up. There is not currently a version of xml2rfc that meets our needs. Some of our editors do the major editing in XML, but they find it most efficient and effective to switch to nroff for the final cleanup of the (ASCII) document format. Rather than sending such suggestions to the IETF tools team, why not bring them up on the xml2rfc list? Given that I don't see names like Charles Levert and Julian Reschke and Marshall Rose on the current tools team list, I'm a little concerned that certain things might be lost in process of getting them from the tools team to the actual xml2rfc tool maintainers. In any case, Paul can hardly be blamed for being uninformed when the issues aren't being brought up in what I, at least, think is clearly the correct venue. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
on 2006-01-11 22:02 Bob Braden said the following: * From: Brian Rosen [EMAIL PROTECTED] * To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org * Date: Tue, 10 Jan 2006 20:13:35 -0500 * The RFC editor has some problems which have not, to my knowledge, * been enumerated. * Your knowledge is apparently incomplete. The RFC Editor has been actively experimenting with using xml2rfc for publication, and we have been passing our problems along to the tools team. As we get more experience, new ones show up. There is not currently a version of xml2rfc that meets our needs. Some of our editors do the major editing in XML, but they find it most efficient and effective to switch to nroff for the final cleanup of the (ASCII) document format. This must be a different tools team than the IETF Tools-team. We've not seen any such feedback. Presumably you mean the xml2rfc maintainers? Although in that case it's a bit disappointing that this feedback then must have been passed along in private, rather than on the xml2rfc mailing list - I've not noticed such there. It would have been instructive to see the feedback on the list in order to better understand what would make things easier in the RFC editing work. Henrik (for the Tools team) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
There is not currently a version of xml2rfc that meets our needs. I do not recall seeing any input from the RFC Editor, on the XML2RFC mailing list, citing xml2rfc's deficiencies. That makes it difficult to get those deficiencies fixed. Please, please, please. Post those deficiencies to that list. The issue arises from handing you a format that contains generic markup and is editable but, because of your via nroff process, requires authors to deduce substantive and editorial changes from diffs and then retrofit them back into the XML for future use. This point has been made a number of times, recently. Its importance appears to remain under-appreciated. IETF documents are subject to revision by new editors. They currently find it difficult or impossible to ensure that they are starting from the correct master version. To the extent that they must start from the .txt version, they have significant startup costs (with significant potential for introducing new errors) in order to convert the document to a format better suited to editing -- e.g., better able to manipulate the document's structure. What the IETF community needs is to be able to obtain an accurate, revisable-form version of published documents. xml2rfc is the best candidate for that form. We therefore need to find a way for the RFC Editor to maintain the master version of RFCs in that form. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
on 2006-01-11 23:00 Ned Freed said the following: * From: Brian Rosen [EMAIL PROTECTED] * To: 'Paul Hoffman' [EMAIL PROTECTED], ietf@ietf.org * Date: Tue, 10 Jan 2006 20:13:35 -0500 * The RFC editor has some problems which have not, to my knowledge, * beenenumerated. * Your knowledge is apparently incomplete. The RFC Editor has been actively experimenting with using xml2rfc for publication, and we have been passing our problems along to the tools team. As we get more experience, new ones show up. There is not currently a version of xml2rfc that meets our needs. Some of our editors do the major editing in XML, but they find it most efficient and effective to switch to nroff for the final cleanup of the (ASCII) document format. Rather than sending such suggestions to the IETF tools team, why not bring them up on the xml2rfc list? Given that I don't see names like Charles Levert and Julian Reschke and Marshall Rose on the current tools team list, I'm a little concerned that certain things might be lost in process of getting them from the tools team to the actual xml2rfc tool maintainers. I fully agree. Comments should go to the xml2rfc list. And as a matter of fact, the tools team has not received any feedback or comments from the RFC-Editor regarding the xml2rfc tool. If we had, we would have forwarded it to the xml2rfc list. Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
There is not currently a version of xml2rfc that meets our needs. I do not recall seeing any input from the RFC Editor, on the XML2RFC mailing list, citing xml2rfc's deficiencies. That makes it difficult to get those deficiencies fixed. Please, please, please. Post those deficiencies to that list. Absolutely. The issue arises from handing you a format that contains generic markup and is editable but, because of your via nroff process, requires authors to deduce substantive and editorial changes from diffs and then retrofit them back into the XML for future use. This point has been made a number of times, recently. Its importance appears to remain under-appreciated. IETF documents are subject to revision by new editors. They currently find it difficult or impossible to ensure that they are starting from the correct master version. These are issues even when the editor doesn't change. To the extent that they must start from the .txt version, they have significant startup costs (with significant potential for introducing new errors) in order to convert the document to a format better suited to editing -- e.g., better able to manipulate the document's structure. What the IETF community needs is to be able to obtain an accurate, revisable-form version of published documents. xml2rfc is the best candidate for that form. We therefore need to find a way for the RFC Editor to maintain the master version of RFCs in that form. While I agree that this needs to be the goal, when the RFC does use xml2rfc for most of the editing process getting back a revised XML spec from the RFC Editor that has all the changes made prior to the nroff step would be a HUGE improvement. The time needed to retrofit all the RFC Editor changes into the XML is nonnegligable - I wish I didn't epeak from recent experience, but I do. For once let's not let the best be the enemy of the good. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
when the RFC does use xml2rfc for most of the editing process getting back a revised XML spec from the RFC Editor that has all the changes made prior to the nroff step would be a HUGE improvement. The time needed to retrofit all the RFC Editor changes into the XML is nonnegligable - I wish I didn't epeak from recent experience, but I do. Agree completely. 1. Constraining the initial requirement -- for maintaining the master in xml2rfc format -- to apply only to documents that are submitted to the RFC Editor in that format -- that is, the RFC Editor does not create a conversion, they merely retain the format -- strikes me as far too pragmatic to disagree with, and for the reason you cite. 2. Given that the RFC Editor has the current practice of converting .txt submissions to nroff, it is equally reasonable to pursue their changing that conversion, to instead be into xml2rfc. By 'equally reasonable' I mean as a parallel effort, on its own schedule. As with any transition, the folks doing the work need to remain productive; this requires concessions in the details of the transition process. 3. I believe that we should not plan to prohibit nroff submissions, for the foreseeable future. I'd rather deprecate the activity by virtue of community preference than by imposition of a rule. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On Jan 11, 2006, at 1:52 PM, John C Klensin wrote: --On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden [EMAIL PROTECTED] wrote: Your knowledge is apparently incomplete. The RFC Editor has been actively experimenting with using xml2rfc for publication, and we have been passing our problems along to the tools team. As we get more experience, new ones show up. There is not currently a version of xml2rfc that meets our needs. Some of our editors do the major editing in XML, but they find it most efficient and effective to switch to nroff for the final cleanup of the (ASCII) document format. Bob, Let me suggest a way to look at the above, deriving in large measure from the experiences Ned Freed and I (mostly Ned, who did the heavy lifting) had with what are now RFCs 4288 and 4289. To the extent to which authors can hand XML to you, and get XML back with whatever substantive/ editorial changes you have made, it should ultimately not be a concern of anyone in the community how you make the transition between the final XML, with all of the text worked out, and the final formatting. In particular, if that step requires you to convert the XML to nroff and then massage the nroff, I don't think it should be an issue. The issue arises from handing you a format that contains generic markup and is editable but, because of your via nroff process, requires authors to deduce substantive and editorial changes from diffs and then retrofit them back into the XML for future use. The xml2rfc tools permits injection of unformatted text using the following syntax: figure title= artwork name= type= height= width= xml:space=preserve This text represents the desired structure (without formatting)... blah, blah, blah... blah, blah, blah, ... blah, blah, blah, ... /artwork /figure This mechanism allows authors to bypass the formatting limitations within the xlm2rfc tool. As nroff is also a support input, nroff represents yet another method of achieving a desired output. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
It's trivial for a human, but not for a computer. Many things trivial for humans are not trivial for computers. The kind of harvesting you are talking about is trivial for a human from any format as long as your editor can paste while losing formatting. What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. Your statement that the IETF is getting populated with people who don't code is true. It's a fact, and we need to adapt. Most (but not all) of the people who design protocols these days don't code; they have people who work with them who do. Part of that is unavoidable. The part I regret, which could be avoided, is the loss of running code that we used to care about. Another thread. Brian -Original Message- From: Theodore Ts'o [mailto:[EMAIL PROTECTED] Sent: Monday, January 09, 2006 11:37 PM To: Brian Rosen Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org Subject: Re: Alternative formats for IDs On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote: Any format can be used for any purpose, but it might be time to fully stand up to requirements to harvest data, and to recognize (as I did on another side thread), that reading is getting harder and harder for ASCII. It may be a decent archive format still, but I'm not sure it's going to stay that way. Huh? Harvesting data from ASCII, in terms of pulling out MIB's to be fed into MIB compiler, or reference C code for algorithms like MD5 (RFC 1321) is *trivial* under ASCII. Last I checked, C compilers and MIB compilers still use ASCII text as input, and not Word documents or XML documents. Maybe part of what is going on is that IETF is getting populated with people who aren't close to coding as much as before? You can get perfectly decent text editors for all operating systems, even Windows. And even Word can import text (i.e., plain ASCII) documents Just Fine. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
Hi, What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. MIB modules may be a bad example for you to use. All MIB modules start with a BEGIN character string and end with an END character string. Plain ASCII works perfectly well for this purpose. Binary formatted documents, such as MS-Word and PDF, require much more work from the tools to find those BEGIN and END statements. David Harrington [EMAIL PROTECTED] -Original Message- From: Brian Rosen [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 8:09 AM To: 'Theodore Ts'o' Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org Subject: RE: Alternative formats for IDs It's trivial for a human, but not for a computer. Many things trivial for humans are not trivial for computers. The kind of harvesting you are talking about is trivial for a human from any format as long as your editor can paste while losing formatting. What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. Your statement that the IETF is getting populated with people who don't code is true. It's a fact, and we need to adapt. Most (but not all) of the people who design protocols these days don't code; they have people who work with them who do. Part of that is unavoidable. The part I regret, which could be avoided, is the loss of running code that we used to care about. Another thread. Brian -Original Message- From: Theodore Ts'o [mailto:[EMAIL PROTECTED] Sent: Monday, January 09, 2006 11:37 PM To: Brian Rosen Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org Subject: Re: Alternative formats for IDs On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote: Any format can be used for any purpose, but it might be time to fully stand up to requirements to harvest data, and to recognize (as I did on another side thread), that reading is getting harder and harder for ASCII. It may be a decent archive format still, but I'm not sure it's going to stay that way. Huh? Harvesting data from ASCII, in terms of pulling out MIB's to be fed into MIB compiler, or reference C code for algorithms like MD5 (RFC 1321) is *trivial* under ASCII. Last I checked, C compilers and MIB compilers still use ASCII text as input, and not Word documents or XML documents. Maybe part of what is going on is that IETF is getting populated with people who aren't close to coding as much as before? You can get perfectly decent text editors for all operating systems, even Windows. And even Word can import text (i.e., plain ASCII) documents Just Fine. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On Tue, Jan 10, 2006 at 08:09:10AM -0500, Brian Rosen wrote: It's trivial for a human, but not for a computer. Many things trivial for humans are not trivial for computers. The kind of harvesting you are talking about is trivial for a human from any format as long as your editor can paste while losing formatting. What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. True. So what? Do you think that it is possible, or even a good idea, that tools be able to rip out a MIB without reading the rest of the text? If so, why the heck do we spend so much time working on a the human-readable sections, like Security Considerations? And how much time does it really save to have an automated tool pull out the MIB, instead of having a human do it? And what percentage of the effort does that represent out of the effort to create a product, anyway? 0.0001% 0.1%? I can usually do it in under a minute with some emacs macros, but I'm willing to admit that I may be a bit better at it than others. Other people could probably do it in a few minutes using sed and awk, or even (gasp) perl. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
... What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. You can do that with meta-data encoded in plain ASCII. In fact, that would work better for automated extraction than anything visual such as using multiple fonts. code.../code Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
Ted You are arguing that we have been producing documents for a long time with only primitive tools and we don't need to make any new tools. You are losing that argument. We are increasing the number, and usefulness of tools, and most of us appreciate these tools and want more of them. The range of useful tools we can produce is related to how much meta-data we put in the source files. The more meta-data we put in, the more usefulness we can get out of the data. There is very little downside to adding meta-data as long as it's easy to put in. For most of these things, we have to do special formatting, so we are already marking the octets in some way. Do you have any idea how painful it is to build any kind of product that has good management simply because there is no library of MIBs, with references to documents? There isn't even a LIST of IETF MIBs. You can't figure out if a document has a MIB unless you actually look at the text (although many have a big hint in the title of the document). So yes, I believe better MIB tools would lead to better products, although it would be hard to prove it. I would like to enable automated testing of ABNF. I'd like to be able to cross check the ABNF from one document against its normative references to see what changes or conflicts. I'd like to be able to generate a complete list of SIP error messages a UA may be expected to encounter. I'd like to see a lot more hyperlinking of things. All of these are much easier with meta-data. Brian -Original Message- From: Theodore Ts'o [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 8:58 AM To: Brian Rosen Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org Subject: Re: Alternative formats for IDs On Tue, Jan 10, 2006 at 08:09:10AM -0500, Brian Rosen wrote: It's trivial for a human, but not for a computer. Many things trivial for humans are not trivial for computers. The kind of harvesting you are talking about is trivial for a human from any format as long as your editor can paste while losing formatting. What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. True. So what? Do you think that it is possible, or even a good idea, that tools be able to rip out a MIB without reading the rest of the text? If so, why the heck do we spend so much time working on a the human-readable sections, like Security Considerations? And how much time does it really save to have an automated tool pull out the MIB, instead of having a human do it? And what percentage of the effort does that represent out of the effort to create a product, anyway? 0.0001% 0.1%? I can usually do it in under a minute with some emacs macros, but I'm willing to admit that I may be a bit better at it than others. Other people could probably do it in a few minutes using sed and awk, or even (gasp) perl. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
sorry, couldn't help it You mean, like xml? -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 8:53 AM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: Alternative formats for IDs ... What we are seeing is increasing use of fully automated tools that don't have humans identifying which octets are MIB and which are code. You can't do that with plain ASCII. You can do that with meta-data encoded in plain ASCII. In fact, that would work better for automated extraction than anything visual such as using multiple fonts. code.../code Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
At 9:45 AM -0500 1/10/06, Brian Rosen wrote: Do you have any idea how painful it is to build any kind of product that has good management simply because there is no library of MIBs, with references to documents? There isn't even a LIST of IETF MIBs. You can't figure out if a document has a MIB unless you actually look at the text (although many have a big hint in the title of the document). So yes, I believe better MIB tools would lead to better products, although it would be hard to prove it. Why does this need to be done in the RFCs or Internet Drafts themselves? Why, for example, can't a human with a bit of training extract all the MIBs from the current RFCs and put them into a repository that is machine-accessible? Doing so would probably take less time than writing the tool to make human-readable RFCs also machine-readable. As for Internet Drafts (if we really want people implementing from Internet Drafts), it is trivial to create a convention that says if you want the MIB in your draft to be machine-readable, copy the MIB to a public web server and, in the draft, put on a line by itself: THE-MIB-IS-AT url. No changes are needed to any input or output tools, yet the problem of finding MIBs is solved. I would like to enable automated testing of ABNF. I'd like to be able to cross check the ABNF from one document against its normative references to see what changes or conflicts. I'd like to be able to generate a complete list of SIP error messages a UA may be expected to encounter. I'd like to see a lot more hyperlinking of things. All of these are much easier with meta-data. Sure. If any of those features came free or very cheap, that would be great. None of them do, particularly when you factor in the design-by-entire-IETF-mailing-list work factor. Instead, a bit of human interaction is much less expensive. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
Paul Hoffman wrote: If any of those features came free or very cheap, that would be great. JFTR: The last xml2rfc version under test (pre3) supported to validate ABNF on the fly for artwork type=abnf if the source asks for strict processing. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
I'd mostly agree if this was a one off, but it's not; it requires continuous effort to maintain. My experience that manual is usually cheapest if it only has to be done once, and automation is cheapest if it has to be continuously maintained. YMMV. Most of the harvesting of sections of things that are now text that could be harvested apply to RFCs and not IDs, but things like ABNF checking and even MIB checking could be part of ID nits. Hyperlinks apply to both. There are many ways to put meta-data in files, but I'd rather not invent a new one. xml is just fine, thank you. And we have a nice tool that puts out text and html, and with a small amount of effort, PDF from xml. Our reluctance to use it is mostly: The RFC editor has some problems which have not, to my knowledge, beenenumerated. There are currently other ways to produce ASCII output that people are reluctant to give up on. I suspect we can fix the former. The question is whether the usefulness of the harvesting and alternative outputs outweighs the latter, assuming we accept ASCII output as required and normative. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hoffman Sent: Tuesday, January 10, 2006 11:15 AM To: ietf@ietf.org Subject: RE: Alternative formats for IDs At 9:45 AM -0500 1/10/06, Brian Rosen wrote: Do you have any idea how painful it is to build any kind of product that has good management simply because there is no library of MIBs, with references to documents? There isn't even a LIST of IETF MIBs. You can't figure out if a document has a MIB unless you actually look at the text (although many have a big hint in the title of the document). So yes, I believe better MIB tools would lead to better products, although it would be hard to prove it. Why does this need to be done in the RFCs or Internet Drafts themselves? Why, for example, can't a human with a bit of training extract all the MIBs from the current RFCs and put them into a repository that is machine-accessible? Doing so would probably take less time than writing the tool to make human-readable RFCs also machine-readable. As for Internet Drafts (if we really want people implementing from Internet Drafts), it is trivial to create a convention that says if you want the MIB in your draft to be machine-readable, copy the MIB to a public web server and, in the draft, put on a line by itself: THE-MIB-IS-AT url. No changes are needed to any input or output tools, yet the problem of finding MIBs is solved. I would like to enable automated testing of ABNF. I'd like to be able to cross check the ABNF from one document against its normative references to see what changes or conflicts. I'd like to be able to generate a complete list of SIP error messages a UA may be expected to encounter. I'd like to see a lot more hyperlinking of things. All of these are much easier with meta-data. Sure. If any of those features came free or very cheap, that would be great. None of them do, particularly when you factor in the design-by-entire-IETF-mailing-list work factor. Instead, a bit of human interaction is much less expensive. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
While I personally like PDF for many things, I find PDF to be a poor choice for IETF works-in-progress, or even for RFCs because they lack many of the characteristics that ASCII files offer. Don't you mean that ASCII lacks many of the features PDF offers (font faces, font styles, diagrams, etc. etc. etc.) ? The characteristic you apparently want, i.e. being easy to plug into SW that accepts only ASCII characters, is recovered by text selection in the PDF viewer. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
--On Sunday, 08 January, 2006 14:42 +0200 Yaakov Stein [EMAIL PROTECTED] wrote: While I personally like PDF for many things, I find PDF to be a poor choice for IETF works-in-progress, or even for RFCs because they lack many of the characteristics that ASCII files offer. Don't you mean that ASCII lacks many of the features PDF offers (font faces, font styles, diagrams, etc. etc. etc.) ? The characteristic you apparently want, i.e. being easy to plug into SW that accepts only ASCII characters, is recovered by text selection in the PDF viewer. Yaakov, while I think most of this thread has continued past usefulness without a new, and narrower, proposal, because I remain interested in the potential of PDF for some purposes... I think this helps make it clear that any use PDF proposal, especially for I-Ds, needs to be very specific about a PDF profile and required feature set. It is possible to create perfectly good PDF files from which text selection won't work at all. It is possible to create PDF files that imbed font faces and styles from which text copying and pasting won't work in many operating systems even if text selection is available. Extracting a diagram from a PDF file so that _it_ can be edited is rarely an obvious operation. And so on. Unless those things are available, PDF may be fine for representing a finished document where the only requirement is accurate rendering, but it is fairly terrible for working documents, which I think is what David was trying to suggest. Even with them, it may be worse than importing ASCII into the editor of your choice, even if that editor is MS Word. One way to look at this is that one of the advantages of ASCII is that it is sufficiently feature-poor as to not require any (or much -- we still have the line-end problem) versioning or profiling. From that point of view, part of the problem with either PDF or Word is that they are feature-rich and growing (new versions are being produced with additional capabilities). So, to use them effectively in a contract in which material must be selected and worked on, one has to get into the business of specifying particular versions, features and must or must not be used, and so on. While XML formats can get quite complex, one of the advantages of that particular model is that it is extremely easy to test for whether any prohibited features have been used. My guess it that, for these complex and feature-rich systems, we will find it even harder to reach agreement on those profiling issues than on whether to permit these formats. As an example, assuming you would still like to see MS Word accepted as a submission and display format, suppose we agreed on Word 95's features and file formats. There might actually be some reasons for doing so, starting from the observation that Word- RTF conversions were much less likely to lose information than might be the case for Word 2003. But I can't go to the store and buy a copy of Word 95, no one is supporting it, and so on. Conversely, while I think Word 2003 claims to be able to write out Word 95-compatible files, we have no guarantees that capability will exist in Word 2006 or Word 2008 (?): your own observation about Microsoft's incentives about new versions would suggest that the backward support will be dropped at some stage. Worse, it is not easy to tell a Word 2003 file from a Word 97 one, at least without some serious reverse-engineering, so it is fair to predict that we would see leakage and other side effects, some with significant ill effects. So, while applauding your current I-D as a useful first step (I _really_ dislike having these discussions in the absence of a draft), if you want to propose PDF, I think it is time that you (or others) produce a starting-point draft that specifies or discusses at least: * What the PDF is to be used for (several people, not just myself, have pointed out that the rules might plausibly be different for I-Ds and RFCs) * What version of the file format is to be used. * Consistent with that version, what features are required to be supported in the PDF file * Consistent with that version, what features are prohibited in the PDF file. * What is to be required about font-embedding and whether any restrictions on fonts and styles or the size and definition of image are needed. * Probably answers to some other questions I don't know enough to ask * How, or if, it is possible to design and build good, multiplatform, tools to test for whether or not those requirements have been met. I think it would also be helpful if the draft would identify a selection of tools, for a variety of platforms, that could be used to create the relevant documents and, ideally, enforce whatever requirements are specified. If that list implies a requirement for any
RE: Alternative formats for IDs
Hi, As a MIB Doctor and chair of the Bridge WG, I have been working with the IEEE 802.1 WG, who will assume maintenance responsiblities for the Bridge WG Mib modules. IEEE 802.1 publishes their standards in PDF. We had to make a special request that they make the MIB portion of their documents available in ASCII format, partly so, as part of the transition process, IETF MIB Doctors could review their documents (e.g., running the MIB module through smilint and other compilers), but also so the MIB modules could be extracted for importing into network management applications, such as NET-SNMP and HP OvenView. A similar issue will exist for documents that contain code snippets. While I personally like PDF for many things, I find PDF to be a poor choice for IETF works-in-progress, or even for RFCs because they lack many of the characteristics that ASCII files offer. David Harrington [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John C Klensin Sent: Monday, January 02, 2006 3:37 PM To: Marshall Eubanks Cc: ietf@ietf.org Subject: Re: Alternative formats for IDs Marshall, --On Monday, 02 January, 2006 16:03 -0500 Marshall Eubanks [EMAIL PROTECTED] wrote: ... The project, currently referred to as PDF/A, will address the growing need to electronically archive documents in a way that will ensure preservation of their contents over an extended period of time, and will further ensure that those documents will be able to be retrieved and rendered with a ^^ consistent and predictable result in the future. This need exists in a growing number of international government and industry segments, including legal systems, libraries, newspapers, regulated industries, and others. The work will address the use of PDF for multi-page documents that may contain a mixture of text, raster images and vector graphics. It will also address the features and requirements that must be supported by reading devices that will be used to retrieve and render the archived documents. ^^ Emphasis added, of course. As I have understood it, PDF/A is intended as an archival format for the sorts of documents that exist on paper, with a primary goal of being able to render things that look just like the paper looked like. It has not been a requirement that PDF/A support extraction of text, editing, insertion of new materials, and other forms of markup. Indeed, some of the participants in the PDF/A effort might consider support for some of those things to be liabilities. Your note reinforces that impression. As such, it is (IMO, barely) possible that PDF/A would be a reasonable format for storing archival documents such as RFCs. But it would be a terrible format for working documents such as I-Ds, for the reasons discussed in my earlier note. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
So, the problem you are citing is the issue that you want to harvest data out of the ID or RFC. That's common now, and getting more common. You then immediately move to say ASCII is the right output format because it makes harvesting the data you want easy. Well, probably not as easy as publishing the ID/RFC in some way that is designed to make harvesting of the data within it easy. Say, xml (2629 and follow ons). I believe this issue has been raised before, but we have three uses for the ID and RFC files: we read them, we harvest data from them and we archive them (RFCs anyway) for later use. Any format can be used for any purpose, but it might be time to fully stand up to requirements to harvest data, and to recognize (as I did on another side thread), that reading is getting harder and harder for ASCII. It may be a decent archive format still, but I'm not sure it's going to stay that way. Of course, if you have three different uses, and you end up with more than one format to satisfy all of your requirements, then you have the normative problem. I really think some of you wave that particular flag a bit too strongly, but I think that most of us would be okay with publishing in multiple formats, including ASCII (for now), and even with saying that the ASCII text is the normative one, if and when there is any difference that matters between the formats. I think publishing the xml for harvesting really is the best thing we can do. If we do, we may want some more work done to make more harvesting possible. The schema now is really organized around readability. This probably has less to do with defining new tags than in using some metadata to mark things like ABNF, code, MIBs and the like. I am a proponent of PDF output format; I find it very useful for reading. I have had very few problems with PDF, fewer than with ASCII these days. I am also pretty pleased with HTML as the current tool (xml2rfc) creates. That would mean the the I-D editor and the RFC editor uses xml2rfc, we publish the xml, the ASCII and possibly PDF and/or html from the xml. If you want, the ASCII can be normative. That also implies the desired input format is xml. We can discuss if we want the RFC editor to accept something else and bear the burden of converting to xml. I've heard the RFC editor has tried using xml and xml2rfc and is not satisfied with the results as far as creating ASCII versions of RFC text. It would be interesting to hear what problems they have seen. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David B Harrington Sent: Saturday, January 07, 2006 9:33 AM To: 'John C Klensin'; 'Marshall Eubanks' Cc: ietf@ietf.org Subject: RE: Alternative formats for IDs Hi, As a MIB Doctor and chair of the Bridge WG, I have been working with the IEEE 802.1 WG, who will assume maintenance responsiblities for the Bridge WG Mib modules. IEEE 802.1 publishes their standards in PDF. We had to make a special request that they make the MIB portion of their documents available in ASCII format, partly so, as part of the transition process, IETF MIB Doctors could review their documents (e.g., running the MIB module through smilint and other compilers), but also so the MIB modules could be extracted for importing into network management applications, such as NET-SNMP and HP OvenView. A similar issue will exist for documents that contain code snippets. While I personally like PDF for many things, I find PDF to be a poor choice for IETF works-in-progress, or even for RFCs because they lack many of the characteristics that ASCII files offer. David Harrington [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John C Klensin Sent: Monday, January 02, 2006 3:37 PM To: Marshall Eubanks Cc: ietf@ietf.org Subject: Re: Alternative formats for IDs Marshall, --On Monday, 02 January, 2006 16:03 -0500 Marshall Eubanks [EMAIL PROTECTED] wrote: ... The project, currently referred to as PDF/A, will address the growing need to electronically archive documents in a way that will ensure preservation of their contents over an extended period of time, and will further ensure that those documents will be able to be retrieved and rendered with a ^^ consistent and predictable result in the future. This need exists in a growing number of international government and industry segments, including legal systems, libraries, newspapers, regulated industries, and others. The work will address the use of PDF for multi-page documents that may contain a mixture of text, raster images and vector graphics. It will also address the features and requirements that must be supported by reading devices that will be used to retrieve and render the archived documents. ^^ Emphasis added, of course. As I have understood it, PDF
ancients-moderns dispute (was: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)))
We need to get out this ancients vs moderns dispute. Ancients saying they have no experience of actual need by moderns, and moderns saying this is because the ancient culture does not permit it. Is there an objection to quote non-ascii documents hyperlinks? I suppose not. Why not to just to proceed step by step and experiment? Let create an optional non-ascii art RFC-Editor repositories, for images quoted in RFCs. This will not permit non-ASCII art to be normative but will permit non-ASCII art to be _better_ descriptive in a first time. Experience will show if there are many such images. If there is a real need for normative non-ASCII art, it will provide experience to create a non-ASCII art IANA registry making sure they will survive, at an adeqate place. jfc At 21:00 05/01/2006, John C Klensin wrote: No, I'm not saying that. But the distinction I was trying to make is pretty subtle. The ASCII is the ASCII. Normative doesn't mean much for an I-D (see below for RFCs). The rule about PDF or Postscript versions is that they are supposed to be equivalent to the ASCII (and vice versa). But equivalent gets a little subjective... We know perfectly well that there are a few cases in which, no matter what one does with ASCII art, it is not sufficient to make whatever point is being made and supplemental text --more description, in words, of what would be in the pictures-- will not help much either. Now, part of the point that the people who have said if you can't do it in ASCII art, you generally shouldn't be doing it -- use the ASCII art and write a better description are making is that the cases in which we really need fancy pictures are very few and that, except for those cases, we are better off without them or at least being able to treat them as strictly supplementary. Before I go on, I continue to be fascinated by the observation that, each time the we really need pictures and fancy formatting and need them frequently argument comes up, the vast majority of those who make it most strongly are people whose contributions to the IETF -- in designer, editor, or other leadership roles-- have been fairly minimal. Now, of course, some of them might argue that our current rules prevent them from contributing and that, if only we would let them submit documents written with the DeathRay word processor in Klingon script, not only would their productivity rise, but everyone else's would too --once we bought copies of DeathRay, learned Klingon, and persuaded UTC to get the characters into Unicode. However, that aside, assume that you are describing the new Mona Lisa protocol, and that it is really impossible to adequately describe the protocol without a high-resolution scale picture of the Mona Lisa overlaid with your coordinate system. The ASCII form of your document could (and must under our current rules) describe the coordinate system, include all of the measurements, and describe what you are doing with them. That text is normative (and the important thing is the text, not whether it is in ASCII or not) and has to be. But it is going to be _very_ hard for anyone to understand your protocol without seeing the picture unless they have a good mental image of it. Under those conditions, our precedents are that you can probably convince the WG/WGchairs/ADs, and eventually the RFC Editor, that a PDF document containing a picture of the Mona Lisa and an ASCII document with _- / \ _ | o o | | | | | __ | _ | | \_/ _ | | | | as a substitute for that picture, with the marginal lines roughly identifying your grid marks and coordinate system, is equivalent or as close to it as one can get. I would expect that to be a hard sell. I, personally, would _want_ it to be a hard sell. If it is really necessary, folks will figure out how to get the picture (maybe only the picture, which will probably not change from one version of the I-D to the next) to those who can't handle the PDF (or Postscript). But we have done it before, all of the needed rules and procedures are in place, and nothing new is needed other than your understanding that you are going to have to get consensus that the artwork is vital before making that great a departure between the ASCII and the PDF versions. Similarly, when PDF has been posted in order to exhibit non-ASCII characters, it has proven helpful to have Unicode character offsets (i.e., U+ representations) in both the ASCII and PDF forms to ensure complete precision even though the character-glyphs themselves appear only in the PDF form. So, consider the first baby step to have been taken: nothing prevents you from posting an I-D in both ASCII and PDF today, and the relevant sub-community will sort out, on a case by case basis, whether the ASCII is good enough. ...and if it's not the pdf version of the text
Re: Baby Steps (was RE: Alternative formats for IDs)
Gray, Eric wrote: Stewart, You bring up a good point. I have been assuming that - since IDs can be submitted in multiple formats - that the additional formats would also become part of the RFC library on publication. I just took a quick peek at the RFCs and there does not appear to be a single example of a version that is not in text format. I don't know if that is because they are not stored in the same place, or they are not carried forward as part of the publishing process. You must have looked in the wrong place. Where there are PS or PDF versions, they can be found via the search page at http://www.rfc-editor.org/cgi-bin/rfcsearch.pl It's less clear that all mirror sites carry them. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
Ash, Gerald R (Jerry) wrote: Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Right. The ASCII version is the only normative format. Furthermore, all diagrams, no matter how complex in the PDF version, must be converted to ASCII stick figures in the normative ASCII version. There are no tools I'm aware of to aid that conversion, and in many cases much is lost in the conversion. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. It would, and the same would apply to mathematical formulae. As a matter of fact, the relatively unmodern RFC 1119 that John mentioned does use some graphics and mathematics that would be annoying to code in ASCII. We can certainly ask the question whether that is a big enough benefit to be worth the cost. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: participation sans meeting attendance (was RE: Alternative formats for IDs)
Melinda Shore wrote: On 1/2/06 11:32 PM, Jeffrey Hutzelman [EMAIL PROTECTED] wrote: I think we're doing better on this front than we have in many years. The technical support for remote participation really has become terrific. Some sessions are run with great sensitivity to remote participation, others are not - it depends on the chairs. However, on the other hand it does seem as if groups have become more likely to make final decisions during meetings and not on mailing lists. I'd like to point out that this would be an appealable process failure, i.e. there should always be (at the minimum) an email call for consensus about decisions embedded in the minutes, and important decisions should certainly have their own email consensus call. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ancients-moderns dispute (was: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)))
* * Why not to just to proceed step by step and experiment? Let create an * optional non-ascii art RFC-Editor repositories, for images quoted in * RFCs. This will not permit non-ASCII art to be normative but will * permit non-ASCII art to be _better_ descriptive in a first time. * Experience will show if there are many such images. If there is a * real need for normative non-ASCII art, it will provide experience to * create a non-ASCII art IANA registry making sure they will survive, * at an adeqate place. * * jfc This has been in place for many years, in the form of PS and/or PDF versions of RFCs. What am I missing? Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
* * I just took a quick peek at the RFCs and there does not appear * to be a single example of a version that is not in text format. I * don't know if that is because they are not stored in the same place, * or they are not carried forward as part of the publishing process. * You must not be looking at the official RFC repository maintained by the RFC Editor. For Unix fans, looking at the ~in-notes directory: 31% ls -al rfc*.ps|wc 55 4403127 32% ls -al rfc*.pdf|wc 54 4323124 That is, there are 55 Postscript RFCs and 54 PDF RFCs (they don't exactly match because some early Postscript files could not be converted to PDF). Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ancients-moderns dispute (was: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)))
At 18:49 06/01/2006, Bob Braden wrote: * * Why not to just to proceed step by step and experiment? Let create an * optional non-ascii art RFC-Editor repositories, for images quoted in * RFCs. This will not permit non-ASCII art to be normative but will * permit non-ASCII art to be _better_ descriptive in a first time. * Experience will show if there are many such images. If there is a * real need for normative non-ASCII art, it will provide experience to * create a non-ASCII art IANA registry making sure they will survive, * at an adeqate place. * * jfc This has been in place for many years, in the form of PS and/or PDF versions of RFCs. What am I missing? I am not suggesting a repository of the RFC PDF version. But a repository of the _art_ attached to an ASCII version. So we first see if there is a real need through the usage made. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
If you do not know how to do that with Word, there is help to get. Yes, in RFC 3285. 3285 Using Microsoft Word to create Internet Drafts and RFCs. M. Gahrns, T. Hain. May 2002. (Format: TXT=34556 bytes) (Status: INFORMATIONAL) [YJS] Yes of course we all have used that. However, unfortunately there are problems with that route and no-one is supporting it (as XML2RFC is supported). True, this had not been a problem if the output from Word had been consistent. Anyway, Joe Touch has been updating these tools and you can find them at: http://www.isi.edu/touch/tools/ For example, when printing directly from Word (rather than first producing the ASCII and then printing) the margins are all wrong. True, printing directly is a missing feature of the tools provided by RFC 3285. Joe's version fixes this, so you should be happy with his version also for that reason. Also, certain combinations of characters I use in ASCII art cause (for some unknown and undocumented reason) strange unprintable characters to appear in the ASCII version. Probably this is because you have used characters not part of 7-bit ASCII. It is a good idea to always turn off the auto-correct features of Word, otherwise you will probably get strange characters. Rgds, /L-E ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
As far as I can tell, Microsoft has no idea what ASCII means. You would
expect that Save As... Text Only would produce clean ASCII from a
pretty Word file, but it does not. Instead, you get a file which
contains various 8-bit encodings of common characters such as curly
quotation marks, en- and em-dashes, bullets and so on, in spite of the
fact that there are perfectly good, and commonly-used ASCII conventions
for all of this stuff (' * -- --- ...). I can't tell you how much time I
spend fixing problems caused by this kind of stupidity. Auto-correct or
not, why can't Word have a simple ASCII-fy feature???
Ole
PS. Speaking about Word 11.2 for the Mac, your mileage may vary.
Ole J. Jacobsen
Editor and Publisher, The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972 GSM: +1 415-370-4628
E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj
On Thu, 5 Jan 2006, Lars-Erik Jonsson (LU/EAB) wrote:
[ ... ]
Probably this is because you have used characters not part of
7-bit ASCII. It is a good idea to always turn off the auto-correct
features of Word, otherwise you will probably get strange characters.
Rgds,
/L-E
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
--On Thursday, 05 January, 2006 06:57 +0200 Yaakov Stein [EMAIL PROTECTED] wrote: ... I have never had a problem opening an old file with an up-to-date version of the SW. The problems arise when you try to do the reverse. That makes sense of course, since if you could do everything with the old version, then no-one would buy the new one. After all, a company with 95% market has to be inventive in order to continue selling. Well, our experiences differ. Let's put philosophical and individual economic issues aside for a moment. Let's also temporarily ignore the observation that many members of our community do their work on operating systems on which the current version of Word is not supported. I continue to consider those issues to be showstoppers, but perhaps the compatibility argument is worth pursuing a bit. I think there are two problems here, plus one raised in a note by Lars-Erik. (1) I have had problems opening and using documents from sufficiently old versions, sometimes as recently as two versions ago. I even know the source of some of those problems. For example, I have never had a problem opening, in a clean and unmodified current version of Word, an old document that uses exactly one template and that one unmodified as if out of the box, contains no macros and no workarounds for obscure bugs, and does not use cross-references or a host of other specialized features. For the record, I don't suggest that any document that uses any of those features runs into trouble, only that a sufficiently complex combination of them do. It has often appeared to me that the machinery that converts from the formats of an older version of Word to a newer one will handle the simple cases well but, especially when the original document is several versions older, there seems to be some tendency for Word to get itself into trouble. And, if the old document contains macros or styles that are already present in the normal document template of the new version but with different definitions for some of the set... my experience has been that occasionally things work without side-effects. For some of these cases, one even has to be careful about what it means to successfully open an older document. For example, there was a considerable period in which a document written in the then-current (not even previous-generation) version of Windows Word could be opened just fine with the then-current version of Mac Word... as long either the Windows version contained no comments or one did not care that they disappeared in the transition. Now, you could reasonably suggest that good document hygiene would argue for avoiding most of those features, or removing them in the old system before trying to move documents to the new one. You would, of course, be correct. But to avoid all of those features eliminates much of the power of Word relative to, e.g., ASCII editors that are available for all platforms at negligible cost. And those extended features, once inserted in a document, are not easy to remove. It is, for example, possible to configure Word 2003 to issue a warning every time one tries to save a document containing change-tracking or comments to a file. But, at least as far as I have been able to discover, there are no warnings for macros, styles, and the like. And, while one can say don't save, there are, as far as I know, no options built into Word for cleanly removing all of that stuff and getting a document into the safest of forward-compatible forms. Similarly, there is a configurable warning when one opens a document with embedded macros. But the effect of run safely is not remove all of those macros forever but disable them in this session. If they are hostile and if, for one reason or another, the macro-removal tool (which I'd lay good odds most users of Word don't even know where to find) won't touch them because of how they are installed (a common case), they just lie around as traps for some future unwary person. (2) If I understood correctly, one of the main arguments you made for Word was its change-tracking and collaboration facilities. I certainly agree about the change-tracking. But, as for collaboration, it seems to me that you cannot simultaneously argue that it is unreasonable to expect version-downgrading to work and also argue that Word provides good and useful support for collaborative work in a heterogeneous community. Again, even putting aside economic and similar constraints, we have no way to get everyone in the community to do an upgrade on the same day. Even Microsoft can't keep the feature sets in current versions of Windows Word and Mac Word identical, if only because their release cycles differ (nor are those versions bug-compatible, of course). Even if we could somehow get around those problems, few people who obtain Word in enterprise settings are permitted to install a newer version ahead of the rest of the enterprise, precisely because of that
Re: Alternative formats for IDs
John C Klensin wrote: --On Thursday, 05 January, 2006 06:57 +0200 Yaakov Stein [EMAIL PROTECTED] wrote: ... I have never had a problem opening an old file with an up-to-date version of the SW. The problems arise when you try to do the reverse. That makes sense of course, since if you could do everything with the old version, then no-one would buy the new one. After all, a company with 95% market has to be inventive in order to continue selling. I have had that very same experience, only worse: There was no way of accessing documents from word for OS/2 after somebody had been reading them with winword. Winword cold, but for word for OS/2 they were lost. Only transfering them to CP/M 86 with kermit and processing them with wordstar and then transfering back with kermit again made them workable again. Dont ask what happened to the typesetting. Well, our experiences differ. Let's put philosophical and individual economic issues aside for a moment. Let's also temporarily ignore the observation that many members of our community do their work on operating systems on which the current version of Word is not supported. I continue to consider those issues to be showstoppers, but perhaps the compatibility argument is worth pursuing a bit. I think there are two problems here, plus one raised in a note by Lars-Erik. (1) I have had problems opening and using documents from sufficiently old versions, sometimes as recently as two versions ago. I even know the source of some of those problems. For example, I have never had a problem opening, in a clean and unmodified current version of Word, an old document that uses exactly one template and that one unmodified as if out of the box, contains no macros and no workarounds for obscure bugs, and does not use cross-references or a host of other specialized features. For the record, I don't suggest that any document that uses any of those features runs into trouble, only that a sufficiently complex combination of them do. It has often appeared to me that the machinery that converts from the formats of an older version of Word to a newer one will handle the simple cases well but, especially when the original document is several versions older, there seems to be some tendency for Word to get itself into trouble. And, if the old document contains macros or styles that are already present in the normal document template of the new version but with different definitions for some of the set... my experience has been that occasionally things work without side-effects. For some of these cases, one even has to be careful about what it means to successfully open an older document. For example, there was a considerable period in which a document written in the then-current (not even previous-generation) version of Windows Word could be opened just fine with the then-current version of Mac Word... as long either the Windows version contained no comments or one did not care that they disappeared in the transition. Now, you could reasonably suggest that good document hygiene would argue for avoiding most of those features, or removing them in the old system before trying to move documents to the new one. You would, of course, be correct. But to avoid all of those features eliminates much of the power of Word relative to, e.g., ASCII editors that are available for all platforms at negligible cost. And those extended features, once inserted in a document, are not easy to remove. It is, for example, possible to configure Word 2003 to issue a warning every time one tries to save a document containing change-tracking or comments to a file. But, at least as far as I have been able to discover, there are no warnings for macros, styles, and the like. And, while one can say don't save, there are, as far as I know, no options built into Word for cleanly removing all of that stuff and getting a document into the safest of forward-compatible forms. Similarly, there is a configurable warning when one opens a document with embedded macros. But the effect of run safely is not remove all of those macros forever but disable them in this session. If they are hostile and if, for one reason or another, the macro-removal tool (which I'd lay good odds most users of Word don't even know where to find) won't touch them because of how they are installed (a common case), they just lie around as traps for some future unwary person. (2) If I understood correctly, one of the main arguments you made for Word was its change-tracking and collaboration facilities. I certainly agree about the change-tracking. But, as for collaboration, it seems to me that you cannot simultaneously argue that it is unreasonable to expect version-downgrading to work and also argue that Word provides good and useful support for collaborative work in a heterogeneous community. Again, even putting aside economic and similar constraints, we have no way to get everyone in the community to do an
Re: Alternative formats for IDs
On 01/04/2006 17:09, Julian Reschke wrote: Stephane Bortzmeyer wrote: If we use a XML format, why the very large and complexe (700 pages) OpenDocument and not our RFC 2629? Indeed. Although, at some point of time we'll have also to realize that there most people when they say RFC2629 they really mean RFC2629bis. So, sooner or later, we'll have to start work on a proper spec revision. Best regards, Julian As I understand it, one of the major concerns of the people pushing for alternative formats is a desire to be able to include drawings and diagrams with something other than ASCII art. I don't believe that XML does much to help that. If one is worried about things like including pictures, diagrams, revision marks, etc. then I think looking into something like Open Document Format would make a lot more sense than considering a proprietary format like MS Word. OTOH, if ASCII is good enough, then I guess there's nothing to worry about. I don't have enough IETF experience to have a strong opinion either way. I just think that if alternatives are going to be looked at, then ODF ought to be one of them. Scott Kitterman ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Baby Steps (was RE: Alternative formats for IDs)
Happy New Year to all! Many thanks to Yaakov for his excellent handling of the list discussion. I'm not very surprised with the way it has gone. Déjà vu all over again :-) The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress. I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Let's set aside for now which format(s), and take that as a later step if we can take this first step. Thanks, Regards, Jerry From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yaakov Stein Sent: Sunday, January 01, 2006 12:37 AM To: ietf@ietf.org Subject: Alternative formats for IDs Happy new year to everyone. I would like to call your attention to a new ID http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt. This ID is the result of discussions here on the general list, and proposes the use of formats other than plain ASCII for IDs and RFCs. In particular, it proposes the allowance of diagrams other than ASCII-art as normative. The authors felt that further discussion on the list would not be productive, but that the writing of an ID might force more serious consideration. We furthermore suggest that this ID be advanced as a BCP under the process for process change. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
On Jan 5, 2006, at 09:25, Ash, Gerald R ((Jerry)) wrote: I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Let's set aside for now which format(s), and take that as a later step if we can take this first step. Splitting the question this way paves the way for those pushing for alternative formats to frame the next question as, Which alternative format are we going to allow?, as if it's already decided that we're going to allow *some* alternative and just have to find the best, or at least the least objectionable, even if there aren't any that fulfill the IETF's overall needs as well as plain ASCII text. If you add the qualifier, if they meet our requirements (... better than plain ASCII text?), then I doubt you'll get much disagreement with that statement, though you'll probably get a lot of discussion about how we don't yet *have* a specific list of requirements. As Brian's brown paper bag note suggests, we should start there, not with the assumption that we *will* allow some alternate format Personally, I'm skeptical that we'll find an alternative that meets our requirements as well, but perhaps we'll wind up with plain UTF-8 text or something. Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
--On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R \\(Jerry\\) [EMAIL PROTECTED] wrote: Happy New Year to all! Many thanks to Yaakov for his excellent handling of the list discussion. I'm not very surprised with the way it has gone. Déjà vu all over again :-) The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress. I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say never. Let's set aside for now which format(s), and take that as a later step if we can take this first step. Jerry, one of the nice things about baby steps is that you sometimes discover that the baby learned to take the steps without any instruction. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). When it has been done for artwork purposes, the artwork in the ASCII version has sometimes been pretty rudimentary. In practice, whether it is good enough has been made on a case by case basis by WG Chairs and WGs or, for non-WG documents, by whether or not the relevant people are willing to read and consider those documents. Similarly, when PDF has been posted in order to exhibit non-ASCII characters, it has proven helpful to have Unicode character offsets (i.e., U+ representations) in both the ASCII and PDF forms to ensure complete precision even though the character-glyphs themselves appear only in the PDF form. So, consider the first baby step to have been taken: nothing prevents you from posting an I-D in both ASCII and PDF today, and the relevant sub-community will sort out, on a case by case basis, whether the ASCII is good enough. If you do more of it, perhaps we can move some of the interoperability problems into the realm of actual IETF experience and out of the realm of extrapolation from other situations mixed with pure speculation. Free advice: if and when you want to move beyond that point, drop (or isolate into separate documents): (1) Recommendations for IETF process change or specific ways to determine consensus. They should be separate so they can be considered separately, using an appropriate process. (2) Distinguish clearly between what is required or tolerable for I-Ds and what is required or tolerable for RFCs. RFCs, in general, put a less strong requirement on easy extraction and modification of text than I-Ds. And, since I-Ds in theory expire after six months, you might be able to convince the community that the be sure it can be read twenty years later requirement for archival documents should not be taken as seriously for I-Ds. (3) Recommendations to permit any format that is (i) proprietary, or (ii) dependent on particular software for processing where that software carries either high costs, onerous licensing requirements, or licensing requirement that attempt to prohibit the development of independent tools to work with the format, or (iii) significantly operating-system dependent, or (iv) significantly version-dependent in the sense that the documents are not forward and backward compatible. I would suggest to you that the fact that Word hits a jackpot by satisfying all of the negative criteria in that third suggestion is the reason why it has been regularly rejected for IETF posting and working use in the past and is almost certain to be rejected in the future. If you want to consider that déjà vu (or deja vu, for ASCII-readers), it certainly is in the sense that we have been here before... but that rather misses the point: it has been rejected in the past for substantial and substantive reasons and the déjà vu situation, for me at least, is that someone decides to bring it up again every few years as if it had never been considered in the past. regards, john ___ Ietf mailing list
RE: Alternative formats for IDs
On Thursday, January 05, 2006 07:03:39 AM +0200 Yaakov Stein [EMAIL PROTECTED] wrote: [YJS] Actually, cuneiform on clay tablets and hieroglyphics on marble stelai seem to be better than paper if you really want your message to last a long time. I'm not convinced clay is better than paper; marble certainly is. However, neither is as widely deployed, probably due to the high costs of production and distribution. :-) -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
John C Klensin wrote: --On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R \\(Jerry\\)" [EMAIL PROTECTED] wrote: Happy New Year to all! Many thanks to Yaakov for his excellent handling of the list discussion. I'm not very surprised with the way it has gone. Déjà vu all over again :-) The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress. I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say "never". Let's set aside for now which format(s), and take that as a later step if we can take this first step. Jerry, one of the nice things about baby steps is that you sometimes discover that the baby learned to take the steps without any instruction. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). When it has been done for artwork purposes, the artwork in the ASCII version has sometimes been pretty rudimentary. In practice, whether it is "good enough" has been made on a case by case basis by WG Chairs and WGs or, for non-WG documents, by whether or not the relevant people are willing to read and consider those documents. Please clarify this. Are you saying that if the WG/WGchairs/ADs agree that the non-ASCII version should be the normative version (because they want the better artwork), then that's OK? I thought I asked this a long time ago and was told no. Similarly, when PDF has been posted in order to exhibit non-ASCII characters, it has proven helpful to have Unicode character offsets (i.e., U+ representations) in both the ASCII and PDF forms to ensure complete precision even though the character-glyphs themselves appear only in the PDF form. So, consider the first baby step to have been taken: nothing prevents you from posting an I-D in both ASCII and PDF today, and the relevant sub-community will sort out, on a case by case basis, whether the ASCII is good enough. ...and if it's not the pdf version of the text including graphics will become the RFC? - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
On 01/05/2006 11:28 AM, John C Klensin allegedly wrote: Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say never. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. Yes. I support ASCII as the output format. I appreciate the discipline it encourages of separating protocol specification from descriptive text and figures, and of being very clear about state machines, etc. However, there are cases where descriptive text and figures are much more informative in some other format, so I wouldn't say never (nor should I be forced into a position of choosing between never and always). I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). For heuristic value ... Do you think there is a correlation between restricting ourselves to formats which are good for protocol specifications but not much else, and the skew in our success record toward problems solved by protocol specifications as opposed to the really complex system problems? :-) By the way, I like emacs picture mode. You can bind the keypad keys so that e.g. 3 means draw toward the upper right. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
Scott W Brim wrote: For heuristic value ... Do you think there is a correlation between restricting ourselves to formats which are good for protocol specifications but not much else, and the skew in our success record toward problems solved by protocol specifications as opposed to the really complex system problems? :-) Of course. By the way, I like emacs picture mode. You can bind the keypad keys so that e.g. 3 means draw toward the upper right. This seems intuituve and easy, if your normal input device is a telephone keypad. Otherwise, why choose this example? -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Right. The ASCII version is the only normative format. Furthermore, all diagrams, no matter how complex in the PDF version, must be converted to ASCII stick figures in the normative ASCII version. There are no tools I'm aware of to aid that conversion, and in many cases much is lost in the conversion. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. Agreed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
Jerry, And this is a déjà vu over and over again as well. We could - in theory - allow draft versions in any format an author chooses. It would make quite a mess of the draft repository and - eventually - the RFC library. But we need to agree on one or more versions that can be (more or less) viewed by anyone, if we expect that everyone will actually read and use them. I believe the current practice allows for multiple formats, but requires that at least one is in ASCII text. And, in cases where the document is expected to be of an authoritative nature, the authoritative version is the one in the common (ASCII text) format. If that were acceptable to everyone, we could stop there, rather than taking the next baby step off the top stair. :-) However, there are a number of people who feel that complex figures are required to understand authoritative text in at least some cases - and this is a good argument for making a version that contains these complex figures authoritative. At this point, all agreement breaks down. The only way to go forward (assuming that change is part of the definition of going forward) is through arbitration. I am certain that (déjà vu, yet again) arbitration has been tried again and again... -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Ash, Gerald R (Jerry) -- Sent: Thursday, January 05, 2006 9:26 AM -- To: Yaakov Stein; ietf@ietf.org -- Cc: Ash, Gerald R (Jerry) -- Subject: Baby Steps (was RE: Alternative formats for IDs) -- -- Happy New Year to all! -- -- Many thanks to Yaakov for his excellent handling of the -- list discussion. I'm not very surprised with the way it -- has gone. Déjà vu all over again :-) -- -- The challenge is to focus the discussion to try to reach -- consensus on moving forward with a process change, i.e., we -- need to take baby steps to make progress. -- -- I'd suggest we try to reach consensus first on the following: -- Alternative format(s) for IDs, in addition to ASCII text, -- should be allowed. -- -- One requirement/motivation for this change (as set forth in -- the ID) is to be able to include drawings and diagrams with -- something much more flexible than ASCII art. -- -- Based on the prior discussion of 'ASCII art', and the -- current discussion, I see few people arguing that ASCII -- text is all we need and that no other formats should ever -- be allowed. -- -- Let's set aside for now which format(s), and take that as a -- later step if we can take this first step. -- -- Thanks, -- Regards, -- Jerry -- -- -- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Yaakov Stein -- Sent: Sunday, January 01, 2006 12:37 AM -- To: ietf@ietf.org -- Subject: Alternative formats for IDs -- -- Happy new year to everyone. -- -- I would like to call your attention to a new ID -- http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt. -- -- This ID is the result of discussions here on the general list, -- and proposes the use of formats other than plain ASCII -- for IDs and RFCs. In particular, it proposes the allowance -- of diagrams other than ASCII-art as normative. -- -- The authors felt that further discussion on the list would -- not be productive, -- but that the writing of an ID might force more serious -- consideration. -- We furthermore suggest that this ID be advanced as a BCP -- under the process for process change. -- -- Y(J)S -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
John, I believe - for the record - that Post-Script is also allowed. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of John C Klensin -- Sent: Thursday, January 05, 2006 11:28 AM -- To: Ash, Gerald R \(Jerry\); Yaakov Stein; ietf@ietf.org -- Subject: Re: Baby Steps (was RE: Alternative formats for IDs) -- -- -- -- --On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R -- \\(Jerry\\) [EMAIL PROTECTED] wrote: -- -- Happy New Year to all! -- -- Many thanks to Yaakov for his excellent handling of the list -- discussion. I'm not very surprised with the way it has gone. -- Déjà vu all over again :-) -- -- The challenge is to focus the discussion to try to reach -- consensus on moving forward with a process change, i.e., we -- need to take baby steps to make progress. -- -- I'd suggest we try to reach consensus first on the following: -- Alternative format(s) for IDs, in addition to ASCII text, -- should be allowed. -- -- One requirement/motivation for this change (as set forth in -- the ID) is to be able to include drawings and diagrams with -- something much more flexible than ASCII art. -- -- Based on the prior discussion of 'ASCII art', and the current -- discussion, I see few people arguing that ASCII text is all we -- need and that no other formats should ever be allowed. -- -- Even those of us who are strongly supportive of ASCII as our -- primary base format and those who believe that the effort needed -- to simplify illustrations and diagrams sufficiently that they -- can be accurately represented in ASCII artwork is helpful in -- forcing clarity are reluctant to say never. -- -- Let's set aside for now which format(s), and take that as a -- later step if we can take this first step. -- -- Jerry, one of the nice things about baby steps is that you -- sometimes discover that the baby learned to take the steps -- without any instruction. -- -- Unless the IESG has changed the rules while I was not looking, -- it has been permitted to post I-Ds in PDF in addition to ASCII -- for some years. I find it interesting that it has not been taken -- advantage of more often (and, for the record, I'm one of those -- who has taken advantage of it). When it has been done for -- artwork purposes, the artwork in the ASCII version has sometimes -- been pretty rudimentary. In practice, whether it is good -- enough has been made on a case by case basis by WG Chairs and -- WGs or, for non-WG documents, by whether or not the relevant -- people are willing to read and consider those documents. -- Similarly, when PDF has been posted in order to exhibit -- non-ASCII characters, it has proven helpful to have Unicode -- character offsets (i.e., U+ representations) in both the -- ASCII and PDF forms to ensure complete precision even though the -- character-glyphs themselves appear only in the PDF form. -- -- So, consider the first baby step to have been taken: nothing -- prevents you from posting an I-D in both ASCII and PDF today, -- and the relevant sub-community will sort out, on a case by case -- basis, whether the ASCII is good enough. If you do more of it, -- perhaps we can move some of the interoperability problems into -- the realm of actual IETF experience and out of the realm of -- extrapolation from other situations mixed with pure speculation. -- -- Free advice: if and when you want to move beyond that point, -- drop (or isolate into separate documents): -- -- (1) Recommendations for IETF process change or specific -- ways to determine consensus. They should be separate so -- they can be considered separately, using an appropriate -- process. -- -- (2) Distinguish clearly between what is required or -- tolerable for I-Ds and what is required or tolerable for -- RFCs. RFCs, in general, put a less strong requirement -- on easy extraction and modification of text than I-Ds. -- And, since I-Ds in theory expire after six months, you -- might be able to convince the community that the be -- sure it can be read twenty years later requirement for -- archival documents should not be taken as seriously for -- I-Ds. -- -- (3) Recommendations to permit any format that is (i) -- proprietary, or (ii) dependent on particular software -- for processing where that software carries either high -- costs, onerous licensing requirements, or licensing -- requirement that attempt to prohibit the development of -- independent tools to work with the format, or (iii) -- significantly operating-system dependent, or (iv) -- significantly version-dependent in the sense that the -- documents are not forward and backward compatible. -- -- I would suggest to you that the fact that Word hits a jackpot by -- satisfying all of the negative criteria in that third suggestion -- is the reason why it has been regularly rejected for IETF
RE: Baby Steps (was RE: Alternative formats for IDs)
Stewart, You bring up a good point. I have been assuming that - since IDs can be submitted in multiple formats - that the additional formats would also become part of the RFC library on publication. I just took a quick peek at the RFCs and there does not appear to be a single example of a version that is not in text format. I don't know if that is because they are not stored in the same place, or they are not carried forward as part of the publishing process. Frankly, if the process of getting an ID published as an RFC seems to require (or at least encourage) use of at least one additional format, then the additional format(s) should also be incorporated in the RFC library. In other words, if there was a non-ASCII version of the ID, there should also be a non-ASCII version of the RFC. For some reason I thought this at least used to be the case. If it is not, then that should be fixed - for exactly the reasons you point out. Irrespective of questions about the legitimacy of using a non-ASCII version as normative or authoritative, the fact that a non-ASCII version might contain useful explanatory material is more than sufficient cause to keep it. -- Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stewart Bryant Sent: Thursday, January 05, 2006 12:01 PM To: John C Klensin Cc: Ash, Gerald R \(Jerry\); ietf@ietf.org Subject: Re: Baby Steps (was RE: Alternative formats for IDs) John C Klensin wrote: --On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R \\(Jerry\\) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Happy New Year to all! Many thanks to Yaakov for his excellent handling of the list discussion. I'm not very surprised with the way it has gone. Déjà vu all over again :-) The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress. I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say never. Let's set aside for now which format(s), and take that as a later step if we can take this first step. Jerry, one of the nice things about baby steps is that you sometimes discover that the baby learned to take the steps without any instruction. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). When it has been done for artwork purposes, the artwork in the ASCII version has sometimes been pretty rudimentary. In practice, whether it is good enough has been made on a case by case basis by WG Chairs and WGs or, for non-WG documents, by whether or not the relevant people are willing to read and consider those documents. Please
Re: Alternative formats for IDs
On Thu, 5 Jan 2006, Scott Kitterman wrote: As I understand it, one of the major concerns of the people pushing for alternative formats is a desire to be able to include drawings and diagrams with something other than ASCII art. I don't believe that XML does much to help that. It does in the same way HTML does i.e. you can create separate drawing as jpg or png and include it in the document along with information as to how it would fit in that document. That means that if we use XML as publication or submission format, then data submitted for one draft/rfc can be more then just document itself (probably some rfc editor tools would need to be modified to take care of managing this too). In general it is a good idea to keep just document (i.e. it includes embedded pictures) for at least publication as official standard so I believe most appropriate is indeed to support PDF/A as official publication format but keep the source (XML pictures) available for those who need it as well. If one is worried about things like including pictures, diagrams, revision marks, etc. then I think looking into something like Open Document Format would make a lot more sense than considering a proprietary format like MS Word. You probably missed it, but I did in fact say in my earlier post that if we do want to consider direct editor format,then only good choice would be opendoc. The problem is that it is still relatively new and not enough programs and tools are available that support it on all platforms (but it is already supported in more systems then MS Word can!). That will surely change in the next few years if the format proves itself. Ultimately what I believe will happen is that there would be free (and commercial) tools to convert from MSWord XML (if that format stabilizes) to OpenDoc and back without any loss (at least as far as document text and its presentation) and so this means that those who want to use Word will be able to do it easily. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
On Jan 5, 2006, at 11:49, Stewart Bryant wrote: Ken Raeburn wrote: Personally, I'm skeptical that we'll find an alternative that meets our requirements as well, but perhaps we'll wind up with plain UTF-8 text or something. How would I encode graphics in UTF-8? Same as you do in ASCII now (i.e., poorly), but you get a few more characters to choose from. :-) Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
