RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
Hmm. With Word, for instance, virtually every correction to the text results in a huge clutter of change-tracking notes about format changes and similar drivel. For many documents, it makes the S/N ratio just miserable. If there were a track substantive textual changes only option, an ignore format changes one, or some sort of accept all format, font, and style changes command, I'd probably agree with you about utility. But, given the reality of those systems today, I tend to agree with Ned, even though I like a feature of those system that you didn't mention (the ability to insert comments whose appearance in the output can easily turned on and off. cref and some processing options comes close, but isn't quite the same). [YJS] My experience has been quite different. I work, on a daily basis, with many extremely complex Word documents each of which is handled by many different people (often with conflicting aims). These documents often go through dozens of revisions. And although (as mentioned often before) I am no great fan of Word, I have never seen S/N problems of the type you mention. I suspect that your co-authors are really fooling around way too much with presentation aspects rather than content. Next time agree on a ground rule that first the ideas should be gotten right, and leave the pretty-printing for the final round. Not only does this make sense and save everyones time, it will probably eliminate your S/N problem. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 21-jun-2006, at 9:25, Yaakov Stein wrote: And although (as mentioned often before) I am no great fan of Word, I have never seen S/N problems of the type you mention. I suspect that your co-authors are really fooling around way too much with presentation aspects rather than content. ++ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 20-jun-2006, at 1:07, Ned Freed wrote: does the RFC editor really live up to his/her name and perform extensive edits? The answer is it depends. I've had some documents that were pretty much unchanged while others were edited quite extensively. In recent work I've observed that most edits are good ones, but occasionally the RFC Editor doesn't quite get what's going on and bolixes something up. It is therefore imperative that every change be carefully reviewed by the document authors. I see. No matter how good my tools are, I'm going to have to do considerable, mostly manual, work to retrofit those changes into my source. I don't know what other authors do, but I edit all the changes back into my xml2rfc source, iterating until my output matches, modulo numbering and paragraphing and whatnot, what the RFC Editor produced. Ouch! That must be a colossal waste of time for everyone involved. The RFC Editor provides an annotated differences listing showing you what changed between your final draft and what's in the actual RFC. It is a simple matter to duplicate this tool and use it to tweak your sources to match the actual RFC. I've tried using change bars and other fancier tools, but I have concluded they're more trouble than they're worth. Then you haven't been doing it right... If you use Word, for instance (but Open Office has the same functionality) you can set up track changes and highlight changes when editing or words to the same effect, and then you'll see text that's added in a different color depending on who added it, and you can reject or accept changes made by others. You can also easily skip to the next edit. I can't imagine two or more people working on the same document without this functionality. Yes, this makes sense. Especially if the Word format is only used as a lingua franca without depending on specific details. I.e., I can write a text in Open Office, tag it with the right styles and export to .doc format. My immediate thought in response to all this is what a colossal waste of time. I want to focus on document content, not stylistic frills and irrelevant minutiae. That's what the RFC Editors gets the big bucks to do... I therefore want a tool that lets me engage in semantic markup with as little attention paid to layout issues as possible. And that's exactly what the style mechanism is for: you can indicate headings of different levels (= generate numbering and table of contents automatically), have different kinds of lists (bulleted, numbered) and so on. It is exceedingly unfortunate that some amount of device-level markup is still needed in xml2rfc, but hopefully as the tools improve over time actual use of such facilites will become less necessary. Speaking of time wasting: it doesn't make much sense to me to work on a tool specifically for this purpose while much more powerful general purpose tools are readily available. I.e., wouldn't it make sense to move towards a situation where it's possible to write a draft or RFC with a regular word processor with only a little post processing rather than spend time perfecting yet another tool that's hard to learn? THis is not to say there aren't cases where I want precise control of document output. I don't care about that (well, obviously to some degree, but not much). As an author, I mark up my text correctly and then the layout people can do their magic and get it right about 98% of the time. So I suggest that, generally, we would find that, in a text plus figures model, the editing process would generally change the text only, permitting the figures/images to remain unchanged. That is not my experience. Figures are very hard to get right, they very often require edits. It depends on what sort of edits you're talking about. Both figures and equations move things away from pure semantic markup and towards presentation specifics. It's unavoidable, and once you enter the presentation realm the list of possible tweaks to make things just a little bit better often seems endless. I'm talking about stuff like the text in this box should be A but it's B and there shouldn't be a line between those two boxes. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
--On Tuesday, 20 June, 2006 12:00 +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 20-jun-2006, at 1:07, Ned Freed wrote: ... I've tried using change bars and other fancier tools, but I have concluded they're more trouble than they're worth. Then you haven't been doing it right... If you use Word, for instance (but Open Office has the same functionality) you can set up track changes and highlight changes when editing or words to the same effect, and then you'll see text that's added in a different color depending on who added it, and you can reject or accept changes made by others. You can also easily skip to the next edit. I can't imagine two or more people working on the same document without this functionality. Hmm. With Word, for instance, virtually every correction to the text results in a huge clutter of change-tracking notes about format changes and similar drivel. For many documents, it makes the S/N ratio just miserable. If there were a track substantive textual changes only option, an ignore format changes one, or some sort of accept all format, font, and style changes command, I'd probably agree with you about utility. But, given the reality of those systems today, I tend to agree with Ned, even though I like a feature of those system that you didn't mention (the ability to insert comments whose appearance in the output can easily turned on and off. cref and some processing options comes close, but isn't quite the same). My immediate thought in response to all this is what a colossal waste of time. I want to focus on document content, not stylistic frills and irrelevant minutiae. That's what the RFC Editors gets the big bucks to do... I therefore want a tool that lets me engage in semantic markup with as little attention paid to layout issues as possible. And that's exactly what the style mechanism is for: you can indicate headings of different levels (= generate numbering and table of contents automatically), have different kinds of lists (bulleted, numbered) and so on. If it worked, that would be how it would work. My own experience is that it is very hard to get it to work well. To take a handy example, try to generate a cross reference to a heading that hasn't been generated with a built-in style in Word (2000/ XP/ 2003). ... That is not my experience. Figures are very hard to get right, they very often require edits. It depends on what sort of edits you're talking about. Both figures and equations move things away from pure semantic markup and towards presentation specifics. It's unavoidable, and once you enter the presentation realm the list of possible tweaks to make things just a little bit better often seems endless. I'm talking about stuff like the text in this box should be A but it's B and there shouldn't be a line between those two boxes. But those are precisely the things that, in our environment, one wants the author to get right and the RFC Editor to not mess with. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
--On Tuesday, 20 June, 2006 12:00 +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 20-jun-2006, at 1:07, Ned Freed wrote: ... I've tried using change bars and other fancier tools, but I have concluded they're more trouble than they're worth. Then you haven't been doing it right... If you use Word, for instance (but Open Office has the same functionality) you can set up track changes and highlight changes when editing or words to the same effect, and then you'll see text that's added in a different color depending on who added it, and you can reject or accept changes made by others. You can also easily skip to the next edit. I can't imagine two or more people working on the same document without this functionality. Hmm. With Word, for instance, virtually every correction to the text results in a huge clutter of change-tracking notes about format changes and similar drivel. For many documents, it makes the S/N ratio just miserable. This matches my (much more limited) experience with OpenOffice. If there were a track substantive textual changes only option, an ignore format changes one, or some sort of accept all format, font, and style changes command, I'd probably agree with you about utility. But, given the reality of those systems today, I tend to agree with Ned, even though I like a feature of those system that you didn't mention (the ability to insert comments whose appearance in the output can easily turned on and off. cref and some processing options comes close, but isn't quite the same). IMO this is something that needs to be added to xml2rfc. It is very common to have text of various sorts in drafts that has no business being in the final RFC, and the current mechanisms for controlling this are a bit primitive. Consider this a vote for some added functionality in xml2rfc to cover this case. My immediate thought in response to all this is what a colossal waste of time. I want to focus on document content, not stylistic frills and irrelevant minutiae. That's what the RFC Editors gets the big bucks to do... I therefore want a tool that lets me engage in semantic markup with as little attention paid to layout issues as possible. And that's exactly what the style mechanism is for: you can indicate headings of different levels (= generate numbering and table of contents automatically), have different kinds of lists (bulleted, numbered) and so on. If it worked, that would be how it would work. My own experience is that it is very hard to get it to work well. To take a handy example, try to generate a cross reference to a heading that hasn't been generated with a built-in style in Word (2000/ XP/ 2003). It actually sounds like Word is more capable than some other high end tools in this specific case. ... That is not my experience. Figures are very hard to get right, they very often require edits. It depends on what sort of edits you're talking about. Both figures and equations move things away from pure semantic markup and towards presentation specifics. It's unavoidable, and once you enter the presentation realm the list of possible tweaks to make things just a little bit better often seems endless. I'm talking about stuff like the text in this box should be A but it's B and there shouldn't be a line between those two boxes. But those are precisely the things that, in our environment, one wants the author to get right and the RFC Editor to not mess with. Exactly so. I will also add that while the temptation is great to use the most powerful tool available, the most powerful tool is often not the best tool for the job. When it comes to producing RFCs, xml2rfc plus a competent XML editing tool (I'm currently using Exchanger XML Editor) is a clear winner in my book. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
I would say that getting always the same printout is a non-goal. Why? As has been stated previously, in most SDOs the printed page is the final word. One of the many inconveniences of xml2rfc is the need to add vspace blankLines to avoid unfortunate page breaks. You're comparing apples and oranges here. For instance, you could use XSL-FO (an XML format...) which also is closer to presentation markup than the RFC2629 XML format. Why should the IETF be inventing new tools to create documents at all? Why aren't we focusing on developing protocols for the IP world, and adopting existing tools for the mundane task of document creation? Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Yaakov Stein schrieb: I would say that getting always the same printout is a non-goal. Why? As has been stated previously, in most SDOs the printed page is the final word. One of the many inconveniences of xml2rfc is the need to add vspace blankLines to avoid unfortunate page breaks. Because it's sufficient to generate the ASCII version once on publication and then keep it. Keeping the source is essential for completely separate tasks (meta data extraction, document revision, generating other formats such as HTML or PDF). You're comparing apples and oranges here. For instance, you could use XSL-FO (an XML format...) which also is closer to presentation markup than the RFC2629 XML format. Why should the IETF be inventing new tools to create documents at all? Why aren't we focusing on developing protocols for the IP world, and adopting existing tools for the mundane task of document creation? So far the IETF hasn't done that. The format is ASCII. One good reason to use a specific XML grammar is that when the only thing that's available is a presentation-oriented format (such as Word or PDF), it gets *much* harder to do meaningful things with the source. And that's one of the reasons why volunteers maintain xml2rfc (both the format itself and various implementations). Speaking of which, that's probably the reason why the W3C is doing the same with their xmlspec XML format. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Because it's sufficient to generate the ASCII version once on publication and then keep it. Keeping the source is essential for completely separate tasks (meta data extraction, document revision, generating other formats such as HTML or PDF). You are using the ASCII version as a proxy for a printed page (and as I once complained, it is not a faithful proxy on all platforms). However, the problems we wanted to solve were precisely those where ASCII is not sufficient, namely graphics and equations, and so we need to return to the printed page as the final word. So far the IETF hasn't done that. The format is ASCII. See above. One good reason to use a specific XML grammar is that when the only thing that's available is a presentation-oriented format (such as Word or PDF), it gets *much* harder to do meaningful things with the source. You are making assumptions about presentation formats. It is quite easy to do meaningful manipulations on TeX source. And that's one of the reasons why volunteers maintain xml2rfc (both the format itself and various implementations). And here is precisely where we are expending efforts. I too enjoy coding, but why are we recreating for the XML2RFC environment mechanisms that exist in available tools? The zenith of these efforts is a script to extract TeX-style math expressions, run TeX on each separately, create images, and then embed them into a PDF created from the xml. ... and all that just to avoid using TeX. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
On Monday, June 19, 2006 10:05:30 AM +0200 Yaakov Stein [EMAIL PROTECTED] wrote: And that's one of the reasons why volunteers maintain xml2rfc (both the format itself and various implementations). And here is precisely where we are expending efforts. I too enjoy coding, but why are we recreating for the XML2RFC environment mechanisms that exist in available tools? We aren't expending any effort. The IETF has not spent any resources on defining the xml2rfc grammar or implementing tools that operate on it. We haven't formed a working group, spent any meeting time, or done anything to suggest that people are required to use it. A few volunteers developed a language and some tools, not in an effort to define a standard source format, but because they wanted to make life easier for themselves as document authors. They were kind enough to share their tools with the community, and other people started using them, and contributing to their maintenance and development. I find those tools to be quite useful, as do many other people. Please stop suggesting that these people are somehow wasting our time with their efforts. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Besides the misquote of myself, the I-D has some misleading examples of bad ASCII art. You cannot honestly prove that ASCII art is unusable by abusing it. I spent a few minutes cleaning up the terrible example in the I-D (Sorry, I am in Washington and don't have ready access to it; I will forward it when I get back.) The example of the network in ASCII art was from a real ID that is being discussed in one of the WG that the experiment is targeting. We can find many others from active work in the IETF. The equations are also from active drafts or from RFCs. This in itself set a limit on the examples that were included in the draft. Perhaps we should have included examples of things beyond ASCII art, for example the formal diagrams employed by the ITU, or the state tables used by the IEEE. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Joe Touch schrieb: ... Sure - but if I cite an I-D, and have only the name of the I-D in the XML source, but all the references' details are in the xml2rfc support files, I need to archive them. ... Correct. That's one of the reasons not to do that (that is, copy the reference into the document). Those files change as I-Ds come out. While I can enter that info into the doc, most people do not. Correct. We need to educate them. For instance, once we get there the RFC Editor could refuse to accept documents like these. And I'm worried about changes to XML that render the result uncompilable, not minor text formatting changes. See the changes to 2629 (sometimes referred to as 2629bis, although no I-D has been issued - and we're currently using this 'bis' version) noted on the xml2rfc pages. What happens when a real 'bis' WG is created? will the current changes be supported into the future or not? Do you have any evidence of non-backwards compatible changes that occurred in the past? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Julian Reschke wrote: Joe Touch schrieb: ... And I'm worried about changes to XML that render the result uncompilable, not minor text formatting changes. See the changes to 2629 (sometimes referred to as 2629bis, although no I-D has been issued - and we're currently using this 'bis' version) noted on the xml2rfc pages. What happens when a real 'bis' WG is created? will the current changes be supported into the future or not? Do you have any evidence of non-backwards compatible changes that occurred in the past? As I noted off-list, I had this experience, but didn't bother saving the failed file; that was the 'straw' that shifted me over to revising the Word template, and I didn't save the failed version (unfortunately). Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Joe Touch schrieb: ... As I noted off-list, I had this experience, but didn't bother saving the failed file; that was the 'straw' that shifted me over to revising the Word template, and I didn't save the failed version (unfortunately). ... Well, maybe what you saw actually was a bug fix. xml2rfc is using an embedded almost XML parser, which of course is asking for trouble. I recommend to run all input through a validating *conforming* XML parser first. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
* * Note 2: Unlike some others on the IETF list, I recognize the * importance of having illustrations in better-than-ASCII forms. * We may disagree on how often it is important, or even on whether * important should be a criterion or the criterion should be * closer to convenience. I am nonetheless very sympathetic to * the arguments that fancy illustrations often hide fuzzy thinking * while the discipline of producing ASCII line art tends to * clarify thinking and encourage simplicity in design. Perhaps as * a result of those possible disagreement, we might disagree on * the relevance of ASCII versions of text and ASCII approximations * to the more advanced, image-type, illustrations. But we at * least share the belief that there is a problem in this area that * should be solved. I am not positive that even that position has * IETF community consensus. * * regards, * john John, This discussion has seemed to overlook that fact that for the past 20 years or so the RFC Editor HAS offered a .ps/.pdf alternative output format; it just can't be normative. With very few exceptions, a protocol specifications (that's what we are supposed to be documenting here, the last time I checked) can be defined normatively quite satisfactorily using ASCII. But, sometimes it is helpful to add additional explanatory (non-normative) diagrams, equations, etc., which can be in an auxiliary .ps/.pdf version. I believe there are roughly 50 worked examples of this approach among the 4000+ RFCs in the archive. The one caveat is that processing RFCs with a .ps/.pdf version does take more time and effort, so we hope it does not happen very often. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
On 6/18/06, Julian Reschke [EMAIL PROTECTED] wrote: Clement Cherlin schrieb: ... Unicode Box Drawing ┌┐ │ This is a box │ ├┤ │With another box│ │ underneath │ └┘ ... I like that. In fact I like it so much that I did add some machinery to rfc2629.xslt that helps in producing those (based on existing ASCII line art). Example at: http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.14 Best regards, Julian Very nice. That's a good example of the sorts of diagram that could be displayed in an easier-to-read manner in an RFC using Unicode. And that's only a small sample; there are even more box-drawing characters, arrows and math symbols available in Unicode. Charts are available at http://www.unicode.org/charts/symbols.html, particularly the Mathematical Symbols section. On 6/18/06, Julian Reschke [EMAIL PROTECTED] wrote: As far as I am concerned, at some point the IETF should start on relying on some of 1990's technology being present, such as relying on certain Unicode code points to be readable by everybody. That being said, at least on Win XP the standard fonts seem to support only a subset of the Unicode box drawing characters, which is a shame. It's true that Unicode font support is somewhat spotty. If Unicode were to be specified as the standard for RFCs, there would first need to be an effort to determine which codepoints are available in good quality, freely-available monospace fonts. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
--On Monday, 19 June, 2006 09:32 -0700 Bob Braden [EMAIL PROTECTED] wrote: * Note 2: Unlike some others on the IETF list, I recognize the* importance of having illustrations in better-than-ASCII forms.* We may disagree on how often it is important, or even on whether* important should be a criterion or the criterion should be* closer to convenience. I am nonetheless very sympathetic to* the arguments that fancy illustrations often hide fuzzy thinking * while the discipline of producing ASCII line art tends to * clarify thinking and encourage simplicity in design. Perhaps as* a result of those possible disagreement, we might disagree on* the relevance of ASCII versions of text and ASCII approximations* to the more advanced, image-type, illustrations. But we at* least share the belief that there is a problem in this area that* should be solved. I am not positive that even that position has * IETF community consensus. John, This discussion has seemed to overlook that fact that for the past 20 years or so the RFC Editor HAS offered a .ps/.pdf alternative output format; it just can't be normative. With very few exceptions, a protocol specifications (that's what we are supposed to be documenting here, the last time I checked) can be defined normatively quite satisfactorily using ASCII. But, sometimes it is helpful to add additional explanatory (non-normative) diagrams, equations, etc., which can be in an auxiliary .ps/.pdf version. I believe there are roughly 50 worked examples of this approach among the 4000+ RFCs in the archive. The one caveat is that processing RFCs with a .ps/.pdf version does take more time and effort, so we hope it does not happen very often. Bob, I certainly was not ignoring that possibility, and have commented on it several times. However I see three major disadvantages of it which may or may not be subsumed by more time and effort. The proposers of this particular experiment would add a third, which is precisely that the ps/pdf forms are not normative. Those disadvantages are, in increasing order of importance for this discussion (but perhaps not more generally), are: (1) Because the ps/pdf files are not normative, we haven't spent nearly enough time making sure that they are long-term readable. Perhaps we should; perhaps we now assume that, since they are not normative, we don't care. But there have been, e.g., many postscript files of the vintage of last 1989 that are not readable by modern tools without at least some fussing. (2) If I prepare an RFC draft using some mechanism which produces a document in form X, where X might include * ASCII text, via emacs or vi, with a post processor for headers, footers, or page numbers * xml2rfc * MSWord plus some templates and post processing * nroff with a profile different from the RFC Editor's standard * LaTeX or TeX * Obscure word processor 7b then the RFC Editor makes changes, possibly extensive and returns the revised document in an ASCII text format. No matter how good my tools are, I'm going to have to do considerable, mostly manual, work to retrofit those changes into my source. The retrofit will be easiest with the fourth, but nroff preparation is part of what some of us have never used and others would like to get away from. It will be second-easiest if I prepared the input with the ASCII editors, but they won't help me produce PS/PDF for the textual part of the document (which we both assume will be most of it). For the others, based on experience with three of the four, it has considerable costs in time and effort, costs that are high enough to act as a considerable deterrent to ever getting around to producing the PDF or PS forms. If that deterrent is what the RFC Editor is after, perhaps on a if we make it hard, then only those who think it is really important will put in the time and create the extra work for us, I wish you would be more candid about it with the community. But I haven't concluded, so far, that it is intentional. But, if it is not, then one of the discussions we should be having, IMO, is about selecting one or two additional input formats (xml2rfc and Word stand out as candidates to me) in which the RFC Editor is willing to accept input documents and return editing results to the authors for review. Doing so would solve a large number of problems, not only wrt easily producing PS/PDF forms when needed, but for producing revised versions of the relevant documents for updated standards, etc. That suggestion has been made several times; as far as I know, the discussion has never gotten off the ground. (3) Finally, if one adopts the plates in the back model, the PDF (or whatever) document contains the illustrations and _only_ the illustrations. That makes it fairly insensitive to the RFC editing process. In that process, almost all changes are to
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
John, The advantage of using PDF is that we already use it, for both drafts and RFCs, and have a lot of experience using it. For most people it seems to work just fine. IMO PDF is our best shot in IETF at solving the graphics and equations issues raised in the draft. Good. I actually agree, albeit very tentatively, that it is our best shot. But I believe that saying PDF isn't adequate and that a lot of work has to be done and specified before we are able to use it as a normative or exclusive form for archival RFC documents. ... Note 1: I believe that constraints are imposed on _any_ normative publication format for the IETF by the way we use these documents. In particular, I believe that for files containing the text of the specifications, searchability and extractability are absolutely critical. One thing almost all of those of us who have used PDF know is that some files have those properties while others, often referred to as PDF image files, do not.As soon as one gets to need to be able to search, then it is necessary to profile PDF so that the right sorts of files appear. And, as I think Bob Braden pointed out, one also has to have the tools in place to verify that. It is reasonable for you to disagree with the main premise of the above paragraph, i.e., you may believe that we can dispense with searching and extraction. If so, I would encourage you to say that, since it would make the PDF profiling problem much easier. My personal guess is that you would find it quite hard to sell to the IETF community, but that is just a guess. Of course I believe that searching and extraction from PDF is highly desirable. However I think that is probably not easy, and it's likely that most people can't generate such searchable/extractable PDF files. I also doubt that searchable/extractable PDF is the secret sauce that will suddenly lead to agreement on this list. Besides the beatings administered RE the proposed experiment, we've seen the usual myriad proposals all over again. Based on these discussions, it's hard to see how any way forward other than do nothing will fly. Hopefully the IESG, in spite of the discussions, will propose a viable way forward. Note 2: Unlike some others on the IETF list, I recognize the importance of having illustrations in better-than-ASCII forms. We may disagree on how often it is important, or even on whether important should be a criterion or the criterion should be closer to convenience. I am nonetheless very sympathetic to the arguments that fancy illustrations often hide fuzzy thinking while the discipline of producing ASCII line art tends to clarify thinking and encourage simplicity in design. Perhaps as a result of those possible disagreement, we might disagree on the relevance of ASCII versions of text and ASCII approximations to the more advanced, image-type, illustrations. But we at least share the belief that there is a problem in this area that should be solved. I am not positive that even that position has IETF community consensus. It's good that a key person such as yourself sees a problem that needs solving. Hopefully we'll find a way forward to solve the problem. Thanks, Regards, Jerry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 19-jun-2006, at 20:09, John C Klensin wrote: (2) If I prepare an RFC draft using some mechanism which produces a document in form X, where X might include * ASCII text, via emacs or vi, with a post processor for headers, footers, or page numbers * xml2rfc * MSWord plus some templates and post processing * nroff with a profile different from the RFC Editor's standard * LaTeX or TeX * Obscure word processor 7b then the RFC Editor makes changes, possibly extensive and returns the revised document in an ASCII text format. Now I have never written an RFC so I don't know how all of this works, but I have written two books for different publishers so I know how this kind of thing works elsewhere. My question: does the RFC editor really live up to his/her name and perform extensive edits? And if so, what are the nature of those edits? I can't imagine they go to the technical content, so either it's language (copy edit) or formatting, right? No matter how good my tools are, I'm going to have to do considerable, mostly manual, work to retrofit those changes into my source. Ok. If we're talking about copy edits here, then this is one for the problem statement. Note by the way that the formatting authors are normally expected to do is indicating heading levels, block quotes, captures, that kind of thing. This is very easy to do with styles in modern word processing applications, which generally make anything tagged with a style look different. It's also easy to do with old school tools such as nroff and HTML/XML, and unless I'm mistaken, there are tools available to convert between the two approaches. (Word processors generally have a document format in common that preserves the style tags if not their attributes.) If there is an iterative cycle of changes between the authors and the RFC editor, I think it's necessary that this is done with some form of style tagging. In addition, more advanced word processors such as Word and Star/Open Office/Writer support a track changes feature where any changes made to a document are identified along with who made them. This makes sending different versions of a document back and forth infinitely easier, but it has the downside that many word processors and other tools don't support this, so the selection in tools is much smaller. But, if it is not, then one of the discussions we should be having, IMO, is about selecting one or two additional input formats (xml2rfc and Word stand out as candidates to me) in which the RFC Editor is willing to accept input documents and return editing results to the authors for review. Yes, this makes sense. Especially if the Word format is only used as a lingua franca without depending on specific details. I.e., I can write a text in Open Office, tag it with the right styles and export to .doc format. In Word or another word processor that can read those files, the styles will still be present even if the document looks slightly different from the way it did when I wrote it because some information is lost when saving in a non-native file format. Doing so would solve a large number of problems, not only wrt easily producing PS/PDF forms when needed, but for producing revised versions of the relevant documents for updated standards, etc. That suggestion has been made several times; as far as I know, the discussion has never gotten off the ground. Let's see if we can do better now. (3) Finally, if one adopts the plates in the back model, the PDF (or whatever) document contains the illustrations and _only_ the illustrations. That makes it fairly insensitive to the RFC editing process. I'm not too happy about that. If we're going the route of using images for formulas and drawings, it makes sense to make those available as separate files in an easy format such as GIF or PNG, or, in addition or alternatively, a PDF can be produced where the images are present in-line with the text. Having the images separate from the text in a PDF has all the disadvantages of PDF: possibly large files, small selection in viewers, security and compatibility issues, but it's still inconvenient when reading the text and having to hunt for the images separately. So I suggest that, generally, we would find that, in a text plus figures model, the editing process would generally change the text only, permitting the figures/images to remain unchanged. That is not my experience. Figures are very hard to get right, they very often require edits. As I have said in response to other notes, I'm not convinced that text plus figures (or image attachments) is a good enough idea to be worth writing up and considering -- in terms of either IETF needs or RFC Editor workload. But it has enough advantages relative to either version of the status quo --ASCII-only or of course you can produce a version in PDF if you are
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 19-jun-2006, at 20:09, John C Klensin wrote: (2) If I prepare an RFC draft using some mechanism which produces a document in form X, where X might include * ASCII text, via emacs or vi, with a post processor for headers, footers, or page numbers * xml2rfc * MSWord plus some templates and post processing * nroff with a profile different from the RFC Editor's standard * LaTeX or TeX * Obscure word processor 7b then the RFC Editor makes changes, possibly extensive and returns the revised document in an ASCII text format. Now I have never written an RFC so I don't know how all of this works, but I have written two books for different publishers so I know how this kind of thing works elsewhere. My question: does the RFC editor really live up to his/her name and perform extensive edits? The answer is it depends. I've had some documents that were pretty much unchanged while others were edited quite extensively. In recent work I've observed that most edits are good ones, but occasionally the RFC Editor doesn't quite get what's going on and bolixes something up. It is therefore imperative that every change be carefully reviewed by the document authors. And if so, what are the nature of those edits? I can't imagine they go to the technical content, so either it's language (copy edit) or formatting, right? Most are editorial in nature. Occasionally there will be a change with technical implications though. We're not dealing with fools here, you know. No matter how good my tools are, I'm going to have to do considerable, mostly manual, work to retrofit those changes into my source. I don't know what other authors do, but I edit all the changes back into my xml2rfc source, iterating until my output matches, modulo numbering and paragraphing and whatnot, what the RFC Editor produced. This way I am sure to catch any mistakes introduced by the editing process. I also end up with a source file that's a useful starting point for the next revision of the document. This is quite tedious but not especially difficult as long as you have provided xml2rfc sources to the RFC Editor as a starting point. If you haven't done that my guess is the process isn't nearly as nice. Ok. If we're talking about copy edits here, then this is one for the problem statement. Note by the way that the formatting authors are normally expected to do is indicating heading levels, block quotes, captures, that kind of thing. This is very easy to do with styles in modern word processing applications, which generally make anything tagged with a style look different. It's also easy to do with old school tools such as nroff and HTML/XML, and unless I'm mistaken, there are tools available to convert between the two approaches. (Word processors generally have a document format in common that preserves the style tags if not their attributes.) The RFC Editor provides an annotated differences listing showing you what changed between your final draft and what's in the actual RFC. It is a simple matter to duplicate this tool and use it to tweak your sources to match the actual RFC. I've tried using change bars and other fancier tools, but I have concluded they're more trouble than they're worth. If there is an iterative cycle of changes between the authors and the RFC editor, I think it's necessary that this is done with some form of style tagging. There already is such a process, but IMO you're mistaken about what's needed to improve it. The thing I'd like to have that isn't already there is a way to get the xml2rfc sources the RFC editor used back for comparison purposes. In addition, more advanced word processors such as Word and Star/Open Office/Writer support a track changes feature where any changes made to a document are identified along with who made them. This makes sending different versions of a document back and forth infinitely easier, but it has the downside that many word processors and other tools don't support this, so the selection in tools is much smaller. Again, I've tried these things a couple of times and found them to be more pain than gain. But, if it is not, then one of the discussions we should be having, IMO, is about selecting one or two additional input formats (xml2rfc and Word stand out as candidates to me) in which the RFC Editor is willing to accept input documents and return editing results to the authors for review. As I indicated above, the RFC Editor already accepts xml2rfc source for documents as a starting point. My understanding is that they then do as much of their editing as possible against the xml2rfc source, then generate nroff, then tweak the nroff and possibly even the final output to get exactly what they are after. it would be great if more of the work was done on the xml2rfc and less in the later stages, but I think the RFC Editor is already moving in that direction. Yes, this makes sense. Especially if the Word format is only used
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
On Jun 19, 2006, at 7:05 PM, Anthony G. Atkielski wrote: It's true that Unicode font support is somewhat spotty. It's worse than spotty; it is quite poor. It's pretty good on modern Mac Windows boxes. When I go to a page in Devanagari or Chinese or Russian, it usually displays OK. -Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On Saturday, June 17, 2006 12:07:51 AM +0200 Peter Dambier [EMAIL PROTECTED] wrote: You are not programming in APL, are you? That is the only programming language I know, that does not use either ASCII or EBCDIC. Some folks at Sun have designed a language whose source format uses Unicode: http://research.sun.com/projects/plrg/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On Friday, June 16, 2006 02:31:51 PM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] When I was 16 years old, I wrote a text editor in BASIC that would probably have allowed me to edit RFCs. I wrote a text editor in Basic for the ZxSpectrum that was published commercially when I was 15. I guess I could use it to edit RFCs as well if I could find a ZxSpectrum that still worked to read the program off the cassette tape. My computing needs have grown somewhat since then. ... and, you've completely missed the point. Currently, RFC's are published and distributed in a form which is so straightforward that a child could write software to view or produce it. Show me a PDF viewer written by a 16-year-old in BASIC, or whatever it is that bored kids write software in these days. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
On 17-jun-2006, at 16:59, Eliot Lear wrote: I do think that ASCII art has its limits, particularly when it comes to mathematics. I'm pretty sure I read as many RFCs as the next IETF participant (well, the ones that don't have a three or four letter acronym starting with I in their job description, anyway) and the only formula I seem to remember is this one: log(number of allocated objects) HD = -- log(maximum number of allocatable objects) In other words: is this really a significant issue in practice? It's much better to use the way this is expressed in well-known programming languages anyway, like: hd = log(numberofallocatedobjects) / log (maximumnumberofallocatableobjects) This also gets around the limitation that exists in math and perl where you're lost if you don't know the meaning of a certain symbol because you can't easily look up unknown symbols like you can with unknown words. An interesting side-issue is that if RFCs are no longer plain ASCII, it gets a lot more difficult to discuss them in email. But I think a more gradual evolution is called for in this case, with more consideration given to not only the normative issue but all the others Joel raised. Looks to me that we don't even agree on what the problem is yet. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
On 6/17/06, Eliot Lear [EMAIL PROTECTED] wrote: I do think that ASCII art has its limits, particularly when it comes to mathematics. But I think a more gradual evolution is called for in this case, with more consideration given to not only the normative issue but all the others Joel raised. Eliot I believe one gradual approach that hasn't been discussed is using Unicode instead of ASCII. Many of the problems of representing mathematics and diagrams could be resolved that way, while still retaining the compatibility and portability advantages of plain text. The majority of the solutions I've seen proposed would end up using Unicode as their base character set, so why not cut out the elaborate markup languages and use Unicode directly? I just whipped up some sample fixed-width Unicode art, to illustrate the possibilities: Unicode Math __ −b±√b²−4ac ── 2a Unicode Box Drawing ┌┐ │ This is a box │ ├┤ │With another box│ │ underneath │ └┘ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] ... and, you've completely missed the point. Currently, RFC's are published and distributed in a form which is so straightforward that a child could write software to view or produce it. Show me a PDF viewer written by a 16-year-old in BASIC, or whatever it is that bored kids write software in these days. I am more concerned about making a document readable and intelligible by a 16 year old doing a high school class than the somewhat bizare notion of them writing text editors for use by people writing them. The steps required to format an RFC nicely are far from trivial. I have written ps peresentation software, its essentially the same problem as pdf. Its not that much harder to do. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Clement Cherlin wrote: On 6/17/06, Eliot Lear [EMAIL PROTECTED] wrote: I do think that ASCII art has its limits, particularly when it comes to mathematics. But I think a more gradual evolution is called for in this case, with more consideration given to not only the normative issue but all the others Joel raised. Eliot I believe one gradual approach that hasn't been discussed is using Unicode instead of ASCII. Many of the problems of representing mathematics and diagrams could be resolved that way, while still retaining the compatibility and portability advantages of plain text. The majority of the solutions I've seen proposed would end up using Unicode as their base character set, so why not cut out the elaborate markup languages and use Unicode directly? I just whipped up some sample fixed-width Unicode art, to illustrate the possibilities: Unicode Math __ -b±?b²-4ac ?? 2a The Math I could see, except for the divider line, Iguess. Unicode Box Drawing ?? ? This is a box ? ?? ?With another box? ? underneath ? ?? There were no boxes but a peculiar line below. How about Tex? It is as old as the internet and you can use vi to read and edit. You still can use grep to scan all old documents to find something. ASCII has its limits, yes. All the alternatives mentioned are even more limited. Except EBCDIC of course :) I dont mind getting something new - if somebody else pays for it :) But I dont like to lose something I need. -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 18-jun-2006, at 13:23, Hallam-Baker, Phillip wrote: Show me a PDF viewer written by a 16-year-old in BASIC, or whatever it is that bored kids write software in these days. I am more concerned about making a document readable and intelligible by a 16 year old doing a high school class than the somewhat bizare notion of them writing text editors for use by people writing them. It's not _that_ bizarre. Suppose that we decide to allow publishing RFCs in PDF only. Suppose that within the next few years some company comes up with a replacement for PDF that is better is some important regard so that everyone switches to the new format. Suppose that a decade later, someone wants to read one of those RFCs that is only available in PDF. At that point, it will be extremely hard to do that, because all the new software doesn't support PDF anymore, or in a way that's too limited to be useful. Using old software that with good PDF support isn't an option either, because very little software still runs after a decade or so of OS updates. And writing a PDF viewer just for this isn't really an option either, while writing a viewer or even editor that can handle today's RFC format is. The steps required to format an RFC nicely are far from trivial. It's simple enough, it just takes a lot of effort without good tools. But I'm still not sure what problem exactly we're trying to solve. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 18-jun-2006, at 16:20, Hallam-Baker, Phillip wrote: It's not _that_ bizarre. Suppose that we decide to allow publishing RFCs in PDF only. Suppose that within the next few years some company comes up with a replacement for PDF that is better is some important regard so that everyone switches to the new format. And suppose some Vogons came along and demolished the planet to make way for a hyperspace bypass. There is a slight difference here: the earth hasn't seen any successful demolishion attempts in the last 4.5 billion years, while nearly any word processing document format from the 1990s can't be read properly. In many cases the text itself can be retrieved but there is almost always loss of some or even all formatting. I gather that the current version of Word can't read documents made by all previous versions of itself successfully. The idea that any of the formats being discussed will become impossible to read is silly. There are billions of HTML document and hundreds of millions of PDFs Of course it will not be impossible to read. But there is a big difference between being able to have copies of all published RFCs on local storage (another issue with PDF: the files are many orders of magnitude larger) that are searchable with widely available tools and having to enlist specialist help to extract the desired information. I'm convinced that the success of the TCP/IP and web families of standards has a great deal to do with the fact that the standards documents involved are freely and easily available. The output of the IETF is simply not that critical for this level of concern to be warranted. RFCs are exactly that, requests for comment. Go ask the people at the company you work for how important they think their GTLD servers are, and how critical RFCs 791, 768 and 1035 (to name a few old ones) are for their continued operation. The real standards are and will always be set by running code. This is so absurd that I don't even know what to say. Without continued maintenance the value of standards is quickly lost in any case. RFC 822 has long since ceased to be the Internet email standard, it is of historic interest only. The same is close to being the case for RFC 2822 as well. That's nice. But I doubt you're going to be able to read that email message exchanged through the latest version of the SMTP protocol without some support for RFC 894 along the way. The underlying fallacy here is that the documents are holy scriptures, they are not, they are merely an engineering tool to effect an engineering outcome. Talk about what may happen in fifty or a hundred years time is simply an ego trip. Its like those folk who in the dotcom boom took out million dollar key man insurance. It had nothing to do with the damage that might be done to the company if they died unexpectedly it was a pure ego trip from start to finish. It's the other way around. Time and time again, when an engineer thought well, by that time surely the system will be replaced this turned out to be a mistake. Is Y2K really that long ago that we don't remember that lesson? By the way: I happened to see a documentary on sky scrapers on the BBC the other night. I was surprised to see that the Woolworth building in New York (built in 1913) still has the original elevator machinary in operation. It would suck to have to replace a bunch of elevators because you don't have the documentation to prove that they're still up to code... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
How about Tex? It is as old as the internet and you can use vi to read and edit. You still can use grep to scan all old documents to find something. It is also the only method to always get precisely the same printout, has the best equation typesetting, makes perfectly good diagrams, and the source is pure future-proof ASCII. And there are advanced tools for editing and comparison on all platforms of which I know, for those who desire something a bit stronger than vi and grep. As I have said before, if we decide on TeX instead of XML we solve all the problems. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Yaakov Stein schrieb: How about Tex? It is as old as the internet and you can use vi to read and edit. You still can use grep to scan all old documents to find something. It is also the only method to always get precisely the same printout, has the best equation typesetting, makes perfectly good diagrams, and the source is pure future-proof ASCII. I would say that getting always the same printout is a non-goal. And there are advanced tools for editing and comparison on all platforms of which I know, for those who desire something a bit stronger than vi and grep. As I have said before, if we decide on TeX instead of XML we solve all the problems. You're comparing apples and oranges here. For instance, you could use XSL-FO (an XML format...) which also is closer to presentation markup than the RFC2629 XML format. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Clement Cherlin schrieb: ... Unicode Box Drawing ┌┐ │ This is a box │ ├┤ │With another box│ │ underneath │ └┘ ... I like that. In fact I like it so much that I did add some machinery to rfc2629.xslt that helps in producing those (based on existing ASCII line art). Example at: http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.14 Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Date:Sat, 17 Jun 2006 21:40:06 -0700 From:Joe Touch [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | That's a problem when it changes page numbers (which end up being as | useful as semantic tags) or figures. Or (as importantly) template or | boilerplate text. That's only true if the purpose of re-processing is to make the original document again for some reason - which would only be useful if the formatted version were not to be archived, but only the source, and I don't believe anyone is suggesting that. Archiving the source is useful for people who want to make revisions - certainly that is possible without the source, and for some source formats and some later editors, ignoring the source and using the formatted version might even be preferable - but not always, for many, having the source available makes things much easier. If you accept that the purpose of archiving the source is to ease the production of a revised document, and not to reproduce the original unchanged, then whether or not the formatting tool would produce the original, unchanged, is completely irrelevant. I'm not entirely sure what any of this has to do with the question of allowing non-ascii normative formats, but it seems to be what this discussion has turned into, so ... kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Joe Touch schrieb: Julian Reschke wrote: Joe Touch schrieb: Stephane Bortzmeyer wrote: On Thu, Jun 15, 2006 at 09:01:22AM -0700, Joe Touch [EMAIL PROTECTED] wrote a message of 34 lines which said: IMHO, IETF should always publish the source of its documents (the current RFC process is far from perfect in that respect). Which source The source. The author certainly knows it (yes, I'm aware that the RFC editor performs changes which are not backported in the author's copy, a really annoying thing; that's why I said the current process is bad). That's part of the problem. The other is that 'source' is useful only with a snapshot of the tools that are used to process it. XML2RFC is a moving target in that regard, as is Word. Re XML2RFC: why do you need a snapshot if future development produces versions that continue to implement the semantics defined in RFC2629? It doesn't use 2329; it extends it based on its unofficial successor (see the web pages). Yes, but: 1) If there'd be a decision to officially use rfc2629bis for document production, we certainly would revise rfc2629 first, so the extensions then would be sufficiently described in an RFC, and 2) how's that relevant for the initial question? As long as future versions of xml2rfc are compatible with the one you used, why would you *need* to keep a snapshot of an old version? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Just to explain why I'm agreeing here... It doesn't use 2329; it extends it based on its unofficial successor (see the web pages). Yes, but: 1) If there'd be a decision to officially use rfc2629bis for document production, we certainly would revise rfc2629 first, so the extensions then would be sufficiently described in an RFC, and (Because the XML2RFC community is not excessively perverse - see following point where their lack of perversity also matters) 2) how's that relevant for the initial question? As long as future versions of xml2rfc are compatible with the one you used, why would you *need* to keep a snapshot of an old version? Without reference to any other point that has been made in this thread or its predecessors, I have to say that the idea of the XML2RFC tool breaking compatbility with RFC2629/RFC2629bis is simply amazing. Please see the last three letters of XML2RFC to better understand why I think this is less likely than me winning the lottery. In an jurisdiction that doesn't have a lottery. And blocks access to Internet lottery sites. Given that I don't buy lottery tickets. And, if the XML2RFC community lost its collective mind, it would not be beyond the realm of possibilities that we might ask for a translator to be produced before adopting the new and even more wonderful XML2RFC, and that this community (which includes RFC authors who just MIGHT have RFC2629/RFC2629bis input files they don't want to cut-and-paste themselves) might even think of this on their own. XML2RFC is a moving target, but we could have a lot of influence on where this target moves, and when, and whether there's still a target in the same place as last year, after moving. Sheesh. Can we go back to discussing appeals about appeals again? Even that was more productive. Spencer p.s. I didn't start using XML2RFC the first day the tool existed, but I have been using it since the late 1990s, when it was not much/any easier to use than nroff. It's not perfect now, but it's gotten a lot better, especially on providing line numbers where processing failed (this used to be a real gamble) for diagnostics. If we could decide on using XML input (as opposed to ASCII output from XML input), XML2RFC would probably work even better. The most recent frustrations *I've* been having were about combining formatting and verification/enforcement - for example, the standard tool doesn't produce an output at all, if you have more than five authors listed, and if someone manages to create a document with a section called Security Consideration, that's also a fatal error (because it's not Security Considerations, plural). If we could make a decision about using this tool as a part of the process, it would make sense to bitch about stuff like this, but if the tool is only one way of producing ASCII text, why bother? And yet I use XML2RFC to this very day. I must be nuts. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
Ash, Gerald R (Jerry), ALABS [EMAIL PROTECTED] wrote: I think you're referring to the comment (from a couple of people) that the authors ignored a consensus to specify PDF profiles in the proposed experiment. There's a bit of a straw-man here, in that I'm pretty sure that no two commenters said exactly that; but no matter -- that's not the point I mean to speak to. However, we did not ignore anything. s/anything/any such thing/ It was not clear to me (or the other co-authors) prior to the -02 version that there was any consensus RE specifying PDF profiles/formats/versions, Here's the point I wish to speak to. It is a perversion of the meaning of consensus to take the attitude that nothing in a draft needs to be changed unless there is consensus on the exact nature of the change. I'm seeing that usage among too many IETF participants; and it is _very_ annoying! The proper use of consensus process is to go through the excruciating pain to reach near-unanimity _once_ to produce a base document; thereafter discussing _small_ changes and waiting for reasonable consensus before applying small changes. Where there isn't consensus to make a change, consensus theory holds that the group isn't yet ready for the change (and needs time to learn to accept it). Consensus theory evolved in response to well-known failings of democratic decision-making: in particular the tendency to random-walk as there are small shifts around a nearly-even split. In my experience consensus theory works well for a very large set of issues in group dynamics -- but not all situations. The difficulty lies in determining whether one is faced with a situation in which consensus theory _cannot_ work, or merely a situation in which too few folks understand consensus theory. This determination becomes arbitrarily difficult as personal agendas of people who _do_ understand consensus theory cause them to act as if they don't. :^( I will not attempt to offer a solution here; but I would appreciate it as a personal favor if folks would stop using the word consensus to refer to things quite alien to consensus theory. -- John Leslie [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
For many of the reasons Joel mentioned, I also do not support the experiment as stated in the draft. I want to amplify one point: Joel M. Halpern wrote: Finally, this experiment will produce a set of RFCs which live forever with the limitation that those RFCs do not have normative ASCII. What if we decide that this is a bad idea? How do we fix it? A change from ASCII should not be a flag day, as this document would do to two WGs, but rather based on more experience retrieving the appropriate format. So for instance, it might be interesting if the RFC Editor made available HTML versions of documents produced with XML2RFC, with a caveat that the normative form is still ASCII. This also allows for the continued evolution of XML2RFC to include other objects in a more planned manner. The costs of doing this sort of thing are a concern, of course. I do think that ASCII art has its limits, particularly when it comes to mathematics. But I think a more gradual evolution is called for in this case, with more consideration given to not only the normative issue but all the others Joel raised. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
--On Friday, June 16, 2006 16:28 -0500 Ash, Gerald R \\(Jerry\\), ALABS [EMAIL PROTECTED] wrote: John, I continue to wonder whether what we should be doing here is not to invent a new normative document format, but to figure out how attach image-type figures to ASCII RFCs. plates glued in the back is almost exactly the same as the analogy I have been thinking about. This is a new output format, and previous suggestions for new input/output formats have not reached any agreement whatever -- there is every possible opinion expressed on what format to use or not to use, and why. IMO a big drawback of this approach is that figures (and equations) don't appear with the text, which is not easy to use. Also, your suggestion for a figure supplement to RFCs (with multiple figures in a single PDF? file) has the same drawback. Jerry, It seemed to me to be a plausible middle ground. I prefer books with the figures together with the text that refers to them, rather than one with plates bound in the middle or at the end, too, but I've figured out a way to live with the latter when necessary. And I believe that an image-only file would not have the same requirements that make unrestricted PDF feel like a bad choice for me (see note one below). It is an idea. I haven't written it up in an I-D because I'm not convinced that it is a good idea (although I think it may be worth some investigation) and because I'm out of energy for this, have been able to create ASCII drawings when needed for the RFCs I write, and am busy with other things (see note two below). What I think we do with ideas in the IETF is to think about them and maybe discuss them with others and then either write them up as I-Ds or let them drop. If we get community input on those ideas, we try to understand them and respond to them... typically either by making changes or by explicitly discussing why the input is not applicable. Were I to float that idea as a proposal that we actually do something, I would expect to be beaten up from both the group that considered the idea completely inadequate if we were to do anything (and therefore too much work) and from the side that didn't believe it was necessary. Hmm, that has happened already, even without my making a specific proposal. As the result of those beatings -- the IETF sometimes gets fairly rough in the pursuit of rough consensus -- I would have the choice, if I wanted to make a formal proposal, of taking either of two approaches: (i) to generate essentially the same idea, with no additional changes, qualification, or explanation as a formal proposal or (ii) to try to respond clearly to the ideas, comments, and suggestions that came out of the discussion. If I did the first, I'd expect the same beatings to be administered again, possibly with a higher level of irritation by those who commented. If I did the second, I wouldn't expect automatic acceptance but I'd at least hope for a different set of discussions and arguments. Ultimately, the proposal would succeed iff I was able to convince the community that my draft addressed a problem that existed and was worth solving and that the draft contained a satisfactory solution to it. I can't find that out for a particular proposal without posting it and risking a beating or, worse, dead silence. And, especially in the last couple of years, I've written a lot of I-Ds proposing ideas that have never come to anything ... some after extensive and heated discussion and some just quietly sinking from sight. I have no right to assume that, simply because I make a proposal that I think is reasonable, the community is obligated to accept it or convince me it is a bad idea. The default answer to any proposal here must be no or we all spin into insanity... at least IMO. Accounting for and responding to earlier comments is where you and your colleagues, IMO, partially but critically failed to do between your original drafts and this one.You did part of it -- the proposal for normative MSWord is gone -- but, again IMO, not enough of it. In particular, my belief is that you got a lot of input, from multiple people, that image-only PDF was not adequate for the IETF (see note one) and that enough problems had been encountered with more text-oriented forms with incompatibilities between versions that at least some profiling was going to be necessary. Now I believe --personal opinion of someone who has some experience reading the community but who is certainly not infallible -- that there was actual consensus around the need to tightly specify and constrain PDF if we were to use PDF. But John Leslie's recent note is absolutely right: getting into an argument about consensus at this stage just isn't the point.If there had been only a few well-reasoned arguments about why unrestricted PDF was a bad idea, it would still be your obligation (or at least wise of
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Julian Reschke wrote: Joe Touch schrieb: Julian Reschke wrote: Joe Touch schrieb: Stephane Bortzmeyer wrote: On Thu, Jun 15, 2006 at 09:01:22AM -0700, Joe Touch [EMAIL PROTECTED] wrote a message of 34 lines which said: IMHO, IETF should always publish the source of its documents (the current RFC process is far from perfect in that respect). Which source The source. The author certainly knows it (yes, I'm aware that the RFC editor performs changes which are not backported in the author's copy, a really annoying thing; that's why I said the current process is bad). That's part of the problem. The other is that 'source' is useful only with a snapshot of the tools that are used to process it. XML2RFC is a moving target in that regard, as is Word. Re XML2RFC: why do you need a snapshot if future development produces versions that continue to implement the semantics defined in RFC2629? It doesn't use 2329; it extends it based on its unofficial successor (see the web pages). Yes, but: 1) If there'd be a decision to officially use rfc2629bis for document production, we certainly would revise rfc2629 first, so the extensions then would be sufficiently described in an RFC, and 2) how's that relevant for the initial question? As long as future versions of xml2rfc are compatible with the one you used, why would you *need* to keep a snapshot of an old version? As long as future versions are backward compatible with all past versions, that's fine. That has not been my impression of xml2rfc over the small window I tried to use it. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Joe Touch schrieb: ... As long as future versions are backward compatible with all past versions, that's fine. That has not been my impression of xml2rfc over the small window I tried to use it. ... I guess that depends on the expectation. RFC2629 defines semantical markup. If your expectation is that a given input document will produce *identical* ASCII output over time, then yes, you may experience incompatibilities. As far as I am concerned, that's fine, as long as the meaning of the source is not distorted (of course that's the reason one should stay away from features for presentation, such as vspace). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On Jun 16, 2006, at 11:40 PM, Hallam-Baker, Phillip wrote: From: John L [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 8:27 PM To: Hallam-Baker, Phillip Cc: John C Klensin; ietf@ietf.org Subject: RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)) You mean that we should update the current medieval print format to take advantage of the best technology available to the Victorians? Yeah. I realize that it's appealing to upgrade to the latest half inch nine track tapes (a format that lasted 20 years, after all), but I get the impression that I'm not the only person who would prefer to move with greater caution. Nine track was effectively obsolete a decade ago. I disagree. In my past employment, whenever we would have press attention, the TV guys would want pictures of spinning tape drives to show how scientifically and technically advanced we were. The last time this happened, we had to hunt around to find someone who could get an old 9 track running for the photo-op. I see no adequate replacement for this from new technology. Regards Marshall No problem getting support for it: http://www.chicorporation.com/ninetrack/drives/9906.html The key to making sure you have lasting support is to make sure you choose a standard that enough people depend on that you are not going to be the only person needing a compatible exit strategy. ___ 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: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
From: Marshall Eubanks [mailto:[EMAIL PROTECTED] Nine track was effectively obsolete a decade ago. I disagree. In my past employment, whenever we would have press attention, the TV guys would want pictures of spinning tape drives to show how scientifically and technically advanced we were. The last time this happened, we had to hunt around to find someone who could get an old 9 track running for the photo-op. I see no adequate replacement for this from new technology. Try a bank of flashing LEDS. If you really want to look high tech make a Jacob's ladder. All you need is two pieces of wire, a high tension supply and an insulating backboard. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
Hallam-Baker, Phillip writes: Try a bank of flashing LEDS. Even banks of flashing LEDs are rare these days. I recall mainframes with large control panels that were awash in LEDs (or small neon lamps, earlier on), and I thought they were exceedingly cool (and still do). But they were very expensive and weren't used very often, and so they went away. Banks of switches disappeared a bit earlier. Spinning tape drives should always be shot from low oblique angles, with the computer room lights turned off and replaced by carefully placed colored spotlights (the ones in the back have to be blue or green). Test and diagnostic software that zips through tapes at high speed can be very handy. Or you can run tape copies with delay loops or on a heavily-loaded system so that the tapes screech to a halt every few seconds. For still photography, make sure someone dressed for a board meeting is extending an index finger towards a button on the equipment somewhere. In fact, the person pushing the button should be a woman, and there should be a man in conservative dress behind her standing with a clipboard, looking on with authority and approval. In the U.S., they must not both be WASPs, but one should be. If you must shoot screens, keep them monochrome and run listings of program source code (any language will do). Memory dumps can work too, although they are a bit less varied. It used to be that there had to be an oscilloscope somewhere in the frame, but that's not necessary now. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Julian Reschke wrote: Joe Touch schrieb: ... As long as future versions are backward compatible with all past versions, that's fine. That has not been my impression of xml2rfc over the small window I tried to use it. ... I guess that depends on the expectation. RFC2629 defines semantical markup. If your expectation is that a given input document will produce *identical* ASCII output over time, then yes, you may experience incompatibilities. That's a problem when it changes page numbers (which end up being as useful as semantic tags) or figures. Or (as importantly) template or boilerplate text. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Well, we agree on some things :-) From: Joe Touch [EMAIL PROTECTED] Sent: Saturday, June 17, 2006 11:40 PM Julian Reschke wrote: Joe Touch schrieb: ... As long as future versions are backward compatible with all past versions, that's fine. That has not been my impression of xml2rfc over the small window I tried to use it. ... I guess that depends on the expectation. RFC2629 defines semantical markup. If your expectation is that a given input document will produce *identical* ASCII output over time, then yes, you may experience incompatibilities. That's a problem when it changes page numbers (which end up being as useful as semantic tags) or figures. Or (as importantly) template or boilerplate text. (a) I see changing page numbers as pretty darned inconsequential, because it's just as easy to reference section numbers (and certainly works better when one suspects that all of the readers are cheating, and looking up the references in HTML versions that don't have page numbers anyway, but ignore that for now) (b) template and boilerplate changes are pretty darned CONsequential. One obvious boilerplate item that needs to NOT change is IPR conformance statements, for example. There are likely others. (c) I believe we are talking in good faith, and are both bright enough guys. I would love to have a meaningful and terminating discussion on requirements for XML2RFC backward compatibility, etc. but suspect this would work better if we were making a commitment to use XML2RFC as a normal part of our processes and procedures (so we also have skin in the game). I wonder how best to move forward on this stuff (as much fun as chattering on the IETF list has proven to be). Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
In total, assuming that those are for different documents, that is still less than 1% if those RFCs published in that time period. I know some folks are vocal that there is a problem. But, the evidence suggests otherwise. I don't understand the logic here. Of course there are very few PDFs, since they are not normative and you have to do all the ASCII work anyway. Face with this requirement, people have several options 1) write partial and/or hard to understand descriptions 2) publish elsewhere 3) patent the ideas and charge us for them (it says something about our process if a Government bureaucracy that insists on archaic procedures can handle figures and equations better than we can) 4) give up. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Having a more organized and documented source management mechanism in place would help. While I agree with your and Stephane's points, I think that's a seperate discussion to have. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
My reasoning is very simple: If the ASCII were that unreasonable, and if producing PDF is practical, then I would expect some folks to choose to produce the PDF even if it is not normative. A few folks have done so. VERY few. I was prompted to look at this aspect of the question by attempting to draw a conclusion about the evidence suggested for evaluating the experiment. I found the suggested evaluation criteria awkward. And when I asked myself what would constitute reasonable criteria, it seemed to me that the existing evidence was relevant. Yours, Joel M. Halpern At 08:53 AM 6/16/2006, Yaakov Stein wrote: In total, assuming that those are for different documents, that is still less than 1% if those RFCs published in that time period. I know some folks are vocal that there is a problem. But, the evidence suggests otherwise. I don't understand the logic here. Of course there are very few PDFs, since they are not normative and you have to do all the ASCII work anyway. Face with this requirement, people have several options 1) write partial and/or hard to understand descriptions 2) publish elsewhere 3) patent the ideas and charge us for them (it says something about our process if a Government bureaucracy that insists on archaic procedures can handle figures and equations better than we can) 4) give up. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
--On Thursday, June 15, 2006 09:39 -0400 John R Levine [EMAIL PROTECTED] wrote: But one of the important criteria for an acceptable alternate form, one which came up in the earlier discussion on this list, is that the format be searchable. In case it wasn't clear, my quite informal suggestion was that one might attach a few GIF illusttrations to an ASCII document, sort of like a paper book that has a few color plates glued in the back. I agree it would be nuts to put text into GIF. I continue to wonder whether what we should be doing here is not to invent a new normative document format, but to figure out how attach image-type figures to ASCII RFCs. plates glued in the back is almost exactly the same as the analogy I have been thinking about. So, while I don't think this particular experiment, as described, is plausible, there are two ideas I'd like to see proposed, perhaps experimentally, for the future: (1) A PDF approach, but with PDF carefully researched and profiled (to include searchability and copy-and-paste extraction in addition to stability and very wide availability for readers and formatters) and a back-out plan should the community not be happy about the experimental results. (2) Some specific and well-thought out proposals for a figure supplement to RFCs with multiple figures in a single file, good naming conventions, and so on. A PDF file of figure-images might be the right thing to use; there might be better ones. But, as a strawman, we might have. rfc.txt (as now) and rfc-figs.pdf Where rfc.txt would contain things like Figure 3. A Left Handed Foogle (please see supplement) with or without a rudimentary ASCII drawing. and rfc-figs.pdf would contain numbered and captioned figures, one per page. There are probably better ways to do this -- I haven't thought through the details -- but I think that there is the core of an interesting idea in this. It would _not_ be a small experiment: it implies changes to our archives, changes to indexing systems, more work for the RFC Editor in verifying that figure numbers, captions, and content were consistent between the ASCII RFC and the plates, and so on. But it would appear to me to point to a way forward that would not share most of the disadvantages of normative PDF files. john p.s. When I said should not have been last-called in a prior note, I wasn't trying to suggest that the _idea_ was obviously dead or bad. I was trying to suggest, instead, that, when an idea is discussed at length on the IETF list and a number of issues raised with it, it is normal for the IESG to insist that any version of the idea that is subsequently to be last-called address most of those issues in some substantive way. We don't see X as a problem may be appropriate; pretending (deliberately or by accidental omission) that X was not raised or discussed as an issue is usually not. The fraction of the Last Call discussion that essentially duplicates the discussions of some months ago is probably testimony to the wisdom of that principle. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
I could not agree with John more on the desirablilty of a tighter definition of PDF and the reasonableness of plates in the back. And about the usefulness of including a list of places we've already been. I note that we use issue trackers in a number of working groups, but this is an individual submission... until we come up with a better plan, keeping an issues list in the draft might at least cut down on the number of times we deja vu. Spencer --On Thursday, June 15, 2006 09:39 -0400 John R Levine [EMAIL PROTECTED] wrote: But one of the important criteria for an acceptable alternate form, one which came up in the earlier discussion on this list, is that the format be searchable. In case it wasn't clear, my quite informal suggestion was that one might attach a few GIF illusttrations to an ASCII document, sort of like a paper book that has a few color plates glued in the back. I agree it would be nuts to put text into GIF. I continue to wonder whether what we should be doing here is not to invent a new normative document format, but to figure out how attach image-type figures to ASCII RFCs. plates glued in the back is almost exactly the same as the analogy I have been thinking about. So, while I don't think this particular experiment, as described, is plausible, there are two ideas I'd like to see proposed, perhaps experimentally, for the future: (1) A PDF approach, but with PDF carefully researched and profiled (to include searchability and copy-and-paste extraction in addition to stability and very wide availability for readers and formatters) and a back-out plan should the community not be happy about the experimental results. (2) Some specific and well-thought out proposals for a figure supplement to RFCs with multiple figures in a single file, good naming conventions, and so on. A PDF file of figure-images might be the right thing to use; there might be better ones. But, as a strawman, we might have. rfc.txt (as now) and rfc-figs.pdf Where rfc.txt would contain things like Figure 3. A Left Handed Foogle (please see supplement) with or without a rudimentary ASCII drawing. and rfc-figs.pdf would contain numbered and captioned figures, one per page. There are probably better ways to do this -- I haven't thought through the details -- but I think that there is the core of an interesting idea in this. It would _not_ be a small experiment: it implies changes to our archives, changes to indexing systems, more work for the RFC Editor in verifying that figure numbers, captions, and content were consistent between the ASCII RFC and the plates, and so on. But it would appear to me to point to a way forward that would not share most of the disadvantages of normative PDF files. john p.s. When I said should not have been last-called in a prior note, I wasn't trying to suggest that the _idea_ was obviously dead or bad. I was trying to suggest, instead, that, when an idea is discussed at length on the IETF list and a number of issues raised with it, it is normal for the IESG to insist that any version of the idea that is subsequently to be last-called address most of those issues in some substantive way. We don't see X as a problem may be appropriate; pretending (deliberately or by accidental omission) that X was not raised or discussed as an issue is usually not. The fraction of the Last Call discussion that essentially duplicates the discussions of some months ago is probably testimony to the wisdom of that principle. ___ 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: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Joe Touch schrieb: Stephane Bortzmeyer wrote: On Thu, Jun 15, 2006 at 09:01:22AM -0700, Joe Touch [EMAIL PROTECTED] wrote a message of 34 lines which said: IMHO, IETF should always publish the source of its documents (the current RFC process is far from perfect in that respect). Which source The source. The author certainly knows it (yes, I'm aware that the RFC editor performs changes which are not backported in the author's copy, a really annoying thing; that's why I said the current process is bad). That's part of the problem. The other is that 'source' is useful only with a snapshot of the tools that are used to process it. XML2RFC is a moving target in that regard, as is Word. Re XML2RFC: why do you need a snapshot if future development produces versions that continue to implement the semantics defined in RFC2629? ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
I could not agree with John more on the desirablilty of a tighter definition of PDF and the reasonableness of plates in the back. The problem with tightly defining which piece of PDF you will support is that most clients don't give the user choice on what they do. A user gets a export to PDF button, but they don't get a export to PDF/A and make sure all fonts are self-contained and don't include embedded video. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
--On Friday, June 16, 2006 12:34 -0700 Carl Malamud [EMAIL PROTECTED] wrote: I could not agree with John more on the desirablilty of a tighter definition of PDF and the reasonableness of plates in the back. The problem with tightly defining which piece of PDF you will support is that most clients don't give the user choice on what they do. A user gets a export to PDF button, but they don't get a export to PDF/A and make sure all fonts are self-contained and don't include embedded video. I understand that. But it leaves us in an odd state. On the one hand, some of us have experience with PDF files created in some applications not opening in others and, in particular, not opening in the presumably-normative Adobe Reader. Then we have RFC 3778 and PDF/A, which more or less specify profiles for PDF (although whether or not those profiles are appropriate for our purpose here is a separate question). To the extent to which a user is not able to specify those, or other, profiles, or options that would cause them to be created, the argument that PDF is widely supported by multiple vendors breaks down in practice and, with it, the argument that PDF is really ready for prime time and/or applications that require stability over very long timelines. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
John, You mean that we should update the current medieval print format to take advantage of the best technology available to the Victorians? Why go to all that trouble to create infrastructure to support an obsolete document format when we can get all the infrastructure required to support a modern, open format that delivers professional results for free? Moreover there is a much higher probability that third party tools will support a common W3C/IETF format than an IETF only format. Phill -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 1:14 PM To: John R Levine Cc: ietf@ietf.org Subject: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)) --On Thursday, June 15, 2006 09:39 -0400 John R Levine [EMAIL PROTECTED] wrote: But one of the important criteria for an acceptable alternate form, one which came up in the earlier discussion on this list, is that the format be searchable. In case it wasn't clear, my quite informal suggestion was that one might attach a few GIF illusttrations to an ASCII document, sort of like a paper book that has a few color plates glued in the back. I agree it would be nuts to put text into GIF. I continue to wonder whether what we should be doing here is not to invent a new normative document format, but to figure out how attach image-type figures to ASCII RFCs. plates glued in the back is almost exactly the same as the analogy I have been thinking about. So, while I don't think this particular experiment, as described, is plausible, there are two ideas I'd like to see proposed, perhaps experimentally, for the future: (1) A PDF approach, but with PDF carefully researched and profiled (to include searchability and copy-and-paste extraction in addition to stability and very wide availability for readers and formatters) and a back-out plan should the community not be happy about the experimental results. (2) Some specific and well-thought out proposals for a figure supplement to RFCs with multiple figures in a single file, good naming conventions, and so on. A PDF file of figure-images might be the right thing to use; there might be better ones. But, as a strawman, we might have. rfc.txt (as now) and rfc-figs.pdf Where rfc.txt would contain things like Figure 3. A Left Handed Foogle (please see supplement) with or without a rudimentary ASCII drawing. and rfc-figs.pdf would contain numbered and captioned figures, one per page. There are probably better ways to do this -- I haven't thought through the details -- but I think that there is the core of an interesting idea in this. It would _not_ be a small experiment: it implies changes to our archives, changes to indexing systems, more work for the RFC Editor in verifying that figure numbers, captions, and content were consistent between the ASCII RFC and the plates, and so on. But it would appear to me to point to a way forward that would not share most of the disadvantages of normative PDF files. john p.s. When I said should not have been last-called in a prior note, I wasn't trying to suggest that the _idea_ was obviously dead or bad. I was trying to suggest, instead, that, when an idea is discussed at length on the IETF list and a number of issues raised with it, it is normal for the IESG to insist that any version of the idea that is subsequently to be last-called address most of those issues in some substantive way. We don't see X as a problem may be appropriate; pretending (deliberately or by accidental omission) that X was not raised or discussed as an issue is usually not. The fraction of the Last Call discussion that essentially duplicates the discussions of some months ago is probably testimony to the wisdom of that principle. ___ 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: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Julian Reschke wrote: Joe Touch schrieb: Stephane Bortzmeyer wrote: On Thu, Jun 15, 2006 at 09:01:22AM -0700, Joe Touch [EMAIL PROTECTED] wrote a message of 34 lines which said: IMHO, IETF should always publish the source of its documents (the current RFC process is far from perfect in that respect). Which source The source. The author certainly knows it (yes, I'm aware that the RFC editor performs changes which are not backported in the author's copy, a really annoying thing; that's why I said the current process is bad). That's part of the problem. The other is that 'source' is useful only with a snapshot of the tools that are used to process it. XML2RFC is a moving target in that regard, as is Word. Re XML2RFC: why do you need a snapshot if future development produces versions that continue to implement the semantics defined in RFC2629? It doesn't use 2329; it extends it based on its unofficial successor (see the web pages). Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 16-jun-2006, at 22:39, Hallam-Baker, Phillip wrote: You mean that we should update the current medieval print format to take advantage of the best technology available to the Victorians? Why go to all that trouble to create infrastructure to support an obsolete document format when we can get all the infrastructure required to support a modern, open format that delivers professional results for free? Moreover there is a much higher probability that third party tools will support a common W3C/IETF format than an IETF only format. Don't diss medieval archiving: that stuff is still around. That's very different for a plethora of more modern ways to archive stuff, especially in the digital domain. (Ever looked at a two year old fax?) When I was 16 years old, I wrote a text editor in BASIC that would probably have allowed me to edit RFCs. In the intervening decades I went to software engineering school, but I'm pretty sure that unless I want to dedicate one or more years of my life to it, I can't write something that can decode and display, let alone edit, PDF. Having RFCs only available in a format encumbered with the complexity and ambiguity of PDF (I'm not even mentioning patent/copyright/ trademark issues) is just asking for trouble. And there is absolutely no need for it: it's possible NOW to create a pretty PDF version when you write an RFC. You just have to create an ASCII version too. Is that such a big deal that we're willing to risk losing the ability to access our past work? Although common wisdom tells us that a picture is worth a thousand words, I doubt that greatly in the area of technical documents: yes, they can be useful but they can also be misleading. The text should be able to stand on its own. I'm not opposed to having images attached to (ASCII) RFCs (but not in PDF or another complex format!) but I don't really see the need. This goes double for formulas: those can be rewritten into pseudo code, which generally makes them more accessible to boot. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
John, I continue to wonder whether what we should be doing here is not to invent a new normative document format, but to figure out how attach image-type figures to ASCII RFCs. plates glued in the back is almost exactly the same as the analogy I have been thinking about. This is a new output format, and previous suggestions for new input/output formats have not reached any agreement whatever -- there is every possible opinion expressed on what format to use or not to use, and why. IMO a big drawback of this approach is that figures (and equations) don't appear with the text, which is not easy to use. Also, your suggestion for a figure supplement to RFCs (with multiple figures in a single PDF? file) has the same drawback. The advantage of using PDF is that we already use it, for both drafts and RFCs, and have a lot of experience using it. For most people it seems to work just fine. IMO PDF is our best shot in IETF at solving the graphics and equations issues raised in the draft. So, while I don't think this particular experiment, as described, is plausible, there are two ideas I'd like to see proposed, perhaps experimentally, for the future: (1) A PDF approach, but with PDF carefully researched and profiled (to include searchability and copy-and-paste extraction in addition to stability and very wide availability for readers and formatters) and a back-out plan should the community not be happy about the experimental results. Specifying profiles for PDF is fine, as long as there is agreement that it's necessary. When I said should not have been last-called in a prior note, I wasn't trying to suggest that the _idea_ was obviously dead or bad. I was trying to suggest, instead, that, when an idea is discussed at length on the IETF list and a number of issues raised with it, it is normal for the IESG to insist that any version of the idea that is subsequently to be last-called address most of those issues in some substantive way. We don't see X as a problem may be appropriate; pretending (deliberately or by accidental omission) that X was not raised or discussed as an issue is usually not. The fraction of the Last Call discussion that essentially duplicates the discussions of some months ago is probably testimony to the wisdom of that principle. I think you're referring to the comment (from a couple of people) that the authors ignored a consensus to specify PDF profiles in the proposed experiment. However, we did not ignore anything. It was not clear to me (or the other co-authors) prior to the -02 version that there was any consensus RE specifying PDF profiles/formats/versions, a couple of people as I recall commented on that perhaps, among dozens of other suggestions. Which suggestions are we supposed to treat as consensus? It isn't up to any one individual to declare one comment or another comment as consensus and then charge the authors with ignoring the supposed consensus after the fact. If the authors agree to address a particular comment, OK, but we didn't get that far in the discussion of the -01 draft leading up to the -02 draft. Also, no additional comments were made during the 3-week comment period on the -02 draft before last call was initiated; there was time to raise the comment again. In any case, it is OK to specify profiles/versions/features in the next revision if there is agreement. It is a last call comment that can be incorporated in the -03 version. Jerry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] When I was 16 years old, I wrote a text editor in BASIC that would probably have allowed me to edit RFCs. I wrote a text editor in Basic for the ZxSpectrum that was published commercially when I was 15. I guess I could use it to edit RFCs as well if I could find a ZxSpectrum that still worked to read the program off the cassette tape. My computing needs have grown somewhat since then. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
From: Hallam-Baker, Phillip [EMAIL PROTECTED] Why go to all that trouble to create infrastructure to support an obsolete document format when we can get all the infrastructure required to support a modern, open format Because those of us who've been around for a while have been repeatedly screwed when something that was, at one time, the latest and greatest modern, open format turns out, N years later, to no longer be supported. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
Hallam-Baker, Phillip wrote: From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] When I was 16 years old, I wrote a text editor in BASIC that would probably have allowed me to edit RFCs. I wrote a text editor in Basic for the ZxSpectrum that was published commercially when I was 15. I guess I could use it to edit RFCs as well if I could find a ZxSpectrum that still worked to read the program off the cassette tape. My computing needs have grown somewhat since then. You are not programming in APL, are you? That is the only programming language I know, that does not use either ASCII or EBCDIC. The modern, not so algorithmic languages like lisp or prolog do rely on ASCII or EBCDIC. They cannot use wordstar or word documents. I tried it only once in old MSDOS times :) Cheers Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
The problem with tightly defining which piece of PDF you will support is that most clients don't give the user choice on what they do. A user gets a export to PDF button, but they don't get a export to PDF/A and make sure all fonts are self-contained and don't include embedded video. There's no question that we have a significant tools issue if we use a format as complex as PDF. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://johnlevine.com, Mayor I dropped the toothpaste, said Tom, crestfallenly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
You mean that we should update the current medieval print format to take advantage of the best technology available to the Victorians? Yeah. I realize that it's appealing to upgrade to the latest half inch nine track tapes (a format that lasted 20 years, after all), but I get the impression that I'm not the only person who would prefer to move with greater caution. Moreover there is a much higher probability that third party tools will support a common W3C/IETF format than an IETF only format. Part of the charm of ASCII and GIF is that they already widely supported by tools that have nothing to do with either the W3C or IETF. It seems to me that a good next move would be to figure out if we can arrive at some consensus about what problem we're trying to solve. R's, John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
From: John L [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 8:27 PM To: Hallam-Baker, Phillip Cc: John C Klensin; ietf@ietf.org Subject: RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)) You mean that we should update the current medieval print format to take advantage of the best technology available to the Victorians? Yeah. I realize that it's appealing to upgrade to the latest half inch nine track tapes (a format that lasted 20 years, after all), but I get the impression that I'm not the only person who would prefer to move with greater caution. Nine track was effectively obsolete a decade ago. No problem getting support for it: http://www.chicorporation.com/ninetrack/drives/9906.html The key to making sure you have lasting support is to make sure you choose a standard that enough people depend on that you are not going to be the only person needing a compatible exit strategy. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Two observations on this... --On Wednesday, June 14, 2006 22:16 -0400 John L [EMAIL PROTECTED] wrote: The key question is whether there exists a format which is likely to be sufficiently stable that we won't have to revisit this decision in another 35 years. All the proposed formats - including PDF, XML, etc. - are moving targets at this time. That's why I suggested GIF. Like ASCII, GIF has its shortcomings, but its definition hasn't changed in 16 years and I've never seen GIF software that doesn't interoperate. But one of the important criteria for an acceptable alternate form, one which came up in the earlier discussion on this list, is that the format be searchable. With PDF, page-image forms may not permit that but, as far as I know, searching inside GIFs is impossible except perhaps via fancy AI tools and heuristics. More generally and to reinforce a point that I think Bob Braden made, I believe there was general consensus on this IETF list when the earlier discussion occurred that PDF, if it was to be used, be narrowly profiled so as to permit only those variations that appeared to be stable and meet various other criteria, notably ease of searching and extraction by text copying operations. It seems to me that this draft, by omitting specifics about versions and features of PDF to be permitted and, if it isn't obvious, how the submission or editing process automatically verifies that those rules were followed, is not responsive to that consensus. Arguably, on that basis, it should never have been Last Called. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Two observations on this... --On Wednesday, June 14, 2006 22:16 -0400 John L [EMAIL PROTECTED] wrote: The key question is whether there exists a format which is likely to be sufficiently stable that we won't have to revisit this decision in another 35 years. All the proposed formats - including PDF, XML, etc. - are moving targets at this time. That's why I suggested GIF. Like ASCII, GIF has its shortcomings, but its definition hasn't changed in 16 years and I've never seen GIF software that doesn't interoperate. But one of the important criteria for an acceptable alternate form, one which came up in the earlier discussion on this list, is that the format be searchable. With PDF, page-image forms may not permit that but, as far as I know, searching inside GIFs is impossible except perhaps via fancy AI tools and heuristics. More generally and to reinforce a point that I think Bob Braden made, I believe there was general consensus on this IETF list when the earlier discussion occurred that PDF, if it was to be used, be narrowly profiled so as to permit only those variations that appeared to be stable and meet various other criteria, notably ease of searching and extraction by text copying operations. It seems to me that this draft, by omitting specifics about versions and features of PDF to be permitted and, if it isn't obvious, how the submission or editing process automatically verifies that those rules were followed, is not responsive to that consensus. Arguably, on that basis, it should never have been Last Called. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
On Wed, Jun 14, 2006 at 10:56:03AM -0400, The IESG [EMAIL PROTECTED] wrote a message of 18 lines which said: - 'Proposed Experiment: Normative Format in Addition to ASCII Text ' draft-ash-alt-formats-02.txt as an Experimental RFC This draft is a bad answer to a very real and important problem. I agree with many of the nagtive remarks done on the IETF mailing list. But I want to add one: authorizing an *output* format without the corresponding *input* format (the source) would be a very dangerous step away from open formats. Because it would mean a great difficulty, should we need to modify the RFC for a future version. Even a simple bug fix would be difficult. IMHO, IETF should always publish the source of its documents (the current RFC process is far from perfect in that respect). BTW, the draft completely fails to mention that there are text formats which are better than ordinary raw ASCII and able to be automatically translated to a nice rendering (typical candidates are LaTeX for equations and Graphviz for state machines). In short: no. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Bob, First, I must request that the Internet Draft be retracted in its present form. Section 4 contains a direct quote from one of my messages. However, the quoted sentence was taken brazenly out of context; its sense is quite the opposite of the sense of my original message. This is intolerable. That kind of behavior may get you elected in the US ;-) but it does not belong in the IETF. Please take that up directly with the author. We don't 'retract' I-Ds but we certainly update them. ... How DID it get last called, by the way? If I write up a arbitrary process experiment, will the IESG automatically last call it? Yummy. No. It requires an AD (Bill Fenner in this case) who is willing to shepherd the draft. The IESG as a whole doesn't normally review drafts until after the Last Call has ended - that's why we have Last Calls. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
But one of the important criteria for an acceptable alternate form, one which came up in the earlier discussion on this list, is that the format be searchable. In case it wasn't clear, my quite informal suggestion was that one might attach a few GIF illusttrations to an ASCII document, sort of like a paper book that has a few color plates glued in the back. I agree it would be nuts to put text into GIF. More generally and to reinforce a point that I think Bob Braden made, I believe there was general consensus on this IETF list when the earlier discussion occurred that PDF, if it was to be used, be narrowly profiled so as to permit only those variations that appeared to be stable and meet various other criteria, notably ease of searching and extraction by text copying operations. It seems to me that this draft, by omitting specifics about versions and features of PDF to be permitted and, if it isn't obvious, how the submission or editing process automatically verifies that those rules were followed, is not responsive to that consensus. Arguably, on that basis, it should never have been Last Called. Entirely agree. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
As the author notes, there was indeed a replay of the usual discussion about RFC formats in winter 2006. The author says, ... the quite thoughtful, extended, and detailed discussion ... resulted in no change. There is a reason it did not result in change... there were cogent arguments against all proposals that were made. Cogent arguments against? Very few people came out and said that we need nothing beyond ASCII art. OTOH, many supported the need for something better than archaic ASCII art/equations, given that almost all of us recognize the limitations of ASCII art/equations, generate/use complex graphics every day (in many formats), and very few of us generate/use stick figures beyond IETF. So, when it has no good ideas, the IETF randomly picks one of the bad ones? That is apparently happening here. How DID it get last called, by the way? If I write up a arbitrary process experiment, will the IESG automatically last call it? Yummy. It is quite reasonable to last call this draft at this point. It has been reviewed for ~6 months. This version posted to the list for comments more than 3 weeks ago, plenty of time for more comments, but no comments were posted to the list on this version. In addition, you/RFC Editor were asked to comment on this version (before it was submitted), starting on May 5, but you did not comment. There was an exchange with the AD during this period regarding his concerns RE RFC Editor buy-in, but you still did not comment. We could have incorporated your comments into the LC version had we known them. The experiment picks on two working groups and specifies that for one year review it will treat the results of these working groups differently from all other working group output. Only 2 drafts are involved, and both WGs have agreed. Both of these drafts are good examples of where .pdf is preferable to ASCII art. How will a future implementor know which version is normative? At present, there is a simple rule... it is always the ASCII version. If this exercise goes ahead, some PDF files (which ones?) will be normative, and some ASCII files won't. I'm sure with all the brain power at hand we can solve that daunting riddle with another simple rule. the I-D has some misleading examples of bad ASCII art. You cannot honestly prove that ASCII art is unusable by abusing it. I spent a few minutes cleaning up the terrible example in the I-D (Sorry, I am in Washington and don't have ready access to it; I will forward it when I get back.) Yes please send us the competing ASCII diagrams. We can provide you with even more complex artwork/diagrams to convert to ASCII art -- this will allow you to further prove your point. As Joel mentions, this experiment will have a negative impact on RFC Editor throughput. Shouldn't the IAB and perhaps the IAD have some part in this? .pdf is allowed now for drafts and RFCs. There are procedures in place for .pdf output. In fact, the proposed experiment uses exactly the same procedures followed now wrt RFC Editor processing of .pdf output documents. As stated in the draft: These documents will be progressed through WG review, IESG review, and RFC Editor review and approval. The method to progress the PDF format version is as specified in [RFC2223bis]: When the .pdf version is submitted with the .txt version, the RFC Editor will first edit the .txt version. The final form of the .txt version (or, when feasible, the diffs) will be returned to the author. The author must then update the .pdf files to match, as closely as possible, the content and format of the ASCII .txt file. When the RFC Editor agrees that the .pdf version is acceptable, it is published simultaneously with the .txt version. Since these same procedures are specified in [RFC2223bis] http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt, authored by the RFC Editor, it is reasonable to assume they are OK for our experiment. It is also hard to see how these procedures will lead to more work for the RFC Editor given they are used now. In addition, tools can be developed to assist the authors and RFC editor if necessary. It is straightforward to specify required .pdf versions/formats if that is essential, as some have suggested (although there is no such requirement now on .pdf drafts and RFCs AFAIK). For all the reasons that Joel said, plus the reasons I have given, I request that the IESG reject this last call. At the very least, the base document needs more work, and the implications need more mature thought. And it seems to there is a badly broken process lurking here. I am somewhat astonished that the IESG chose to last call 'this document. It's quite legitimate to last call this (6 months of discussion, several weeks to comment on this version, etc.). I'm rather astonished that you ignored specific requests to comment on
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
As I said in my comments, there is a big difference in the situations. Currently, if the RFC Editor misses something in the PDF applied corrections, that is unfortunate but not fundamentally significant, in that the text file is normative, not the PDF. With your proposed change, the PDF would be normative, not the text. As such, the degree of care and review required for the PDF document is much higher. Similarly, the issue of version change and feature set is not central when one is dealing with informative PDF. But becomes critical if the PDF is normative. (It is extremely undesirable for a normative document to be inaccessible.) As such, your persistent comparisons with the current state are at best misleading. As an example of the necessity of profiling the PDF, at the very least we would want searchable PDF. (Some PDFs with text are searchable, some are not.) Yours, Joel M. Halpern At 09:44 AM 6/15/2006, Ash, Gerald R \(Jerry\), ALABS wrote: As Joel mentions, this experiment will have a negative impact on RFC Editor throughput. Shouldn't the IAB and perhaps the IAD have some part in this? .pdf is allowed now for drafts and RFCs. There are procedures in place for .pdf output. In fact, the proposed experiment uses exactly the same procedures followed now wrt RFC Editor processing of .pdf output documents. As stated in the draft: ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
It is quite reasonable to last call this draft at this point. It has been reviewed for ~6 months. This version posted to the list for comments more than 3 weeks ago, plenty of time for more comments, but no comments were posted to the list on this version. Maybe reviewer fatigue? One thing missing from this discussion (that I think would have been helpful) is running all the previous comments through an issue tracker, so folk could go review the history, and most important of all, those who raised issue can go see if they believe their issues have been dealt with appropriately. One of the most frustrating and demoralizing aspects of IETF participation is spending time doing a careful review, and then feeling like your comments have been blown off. Trackers make it much harder for that to happen, which in my experience is a very good thing for all involved. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
There is a reason it did not result in change... there were cogent arguments against all proposals that were made. I thought that some of the arguments were just arguments against change, and some of the arguments did argue for a change in the experiment but not that the experiment was bad per se. How DID it get last called, by the way? I evaluated the document, the discussion, the feedback from the stakeholders, and decided that a Last Call would be a good forcing function to make sure we have a real discussion about it. I think the idea has promise. How will a future implementor know which version is normative? Presumably, the documents will include a note, something like This document is part of an experiment described in RFC; unlike all other RFCs, the PDF version of this document is normative. Thanks for pointing out that the experiment description forgot to mention that. As Joel mentions, this experiment will have a negative impact on RFC Editor throughput. I didn't quite buy Joel's argument. If the author can generate ASCII from his source that matches the RFC-Editor's edited ASCII, and then generates the PDF from the same source, where does the extra verification come in? ...and the implications need more mature thought. If all we get when discussing on the ietf list is knee-jerk reactions, where is this more mature thought going to come from? Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Thomas, This is a different discussion, however, you are right on target with that discussion - at least for IDs in general. Wouldn't this be subject to a DoS attack, if applied to individual ID submissions? -- Eric -- -Original Message- -- From: Thomas Narten [mailto:[EMAIL PROTECTED] -- Sent: Thursday, June 15, 2006 11:12 AM -- To: Ash, Gerald R (Jerry), ALABS -- Cc: Bob Braden; ietf@ietf.org -- Subject: Re: Last Call: 'Proposed Experiment: Normative -- Format in Addition to ASCII Text' to Experimental RFC -- (draft-ash-alt-formats) -- -- It is quite reasonable to last call this draft at this -- point. It has -- been reviewed for ~6 months. This version posted to the list for -- comments more than 3 weeks ago, plenty of time for more -- comments, but no -- comments were posted to the list on this version. -- -- Maybe reviewer fatigue? -- -- One thing missing from this discussion (that I think would have been -- helpful) is running all the previous comments through an issue -- tracker, so folk could go review the history, and most important of -- all, those who raised issue can go see if they believe their issues -- have been dealt with appropriately. One of the most frustrating and -- demoralizing aspects of IETF participation is spending time doing a -- careful review, and then feeling like your comments have been blown -- off. Trackers make it much harder for that to happen, which in my -- experience is a very good thing for all involved. -- -- Thomas -- -- ___ -- 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: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Stephane Bortzmeyer wrote: ... IMHO, IETF should always publish the source of its documents (the current RFC process is far from perfect in that respect). Which source (XML2RFC is only one; some use troff, and others use Word, among others)? Why would inter-source conversion be more useful than cut-and-paste? Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
That's why I suggested GIF. Like ASCII, GIF has its shortcomings, but its definition hasn't changed in 16 years and I've never seen GIF software that doesn't interoperate. But one of the important criteria for an acceptable alternate form, one which came up in the earlier discussion on this list, is that the format be searchable. With PDF, page-image forms may not permit that but, as far as I know, searching inside GIFs is impossible except perhaps via fancy AI tools and heuristics. Complete agreement here. GIF may win on stability, but loses badly in several other ways. In addition to not being searchable, I really don't relish having to create a revision to a long document starting with only pictures of the text the document contains. More generally and to reinforce a point that I think Bob Braden made, I believe there was general consensus on this IETF list when the earlier discussion occurred that PDF, if it was to be used, be narrowly profiled so as to permit only those variations that appeared to be stable and meet various other criteria, notably ease of searching and extraction by text copying operations. Bingo. And this is the problem with the experiment as it is presently formulated: It tests nothing of significance. It's completely obvious that we can create PDF RFCs. It is equally obvious that block diagrams and equations done in ASCII are inferior in appearance to those done using more powerful formatting tools. All of these things get a 10 on the duh scale. A genuinely useful process experiment in this space would have to: (0) Nail down format requirements. Perhaps the requirements are the same as for ASCII documents, but I doubt it. (1) Carefully examine the subsetting and profiling issue and decide what does or does not need to be done. (2) If subsetting is needed tools need to be identified that conform to those subsetting guidelines. Additionally, we almost certainly need a validation tool that checks to see if the guidelines are being followed. (3) Given how popular xml2rfc is I think it makes sense to at least look at how it would best be used to produce PDF documents containing equations and block diagrams. (4) The criteria for assessing the experiemnt need to address our need for long term accessibility. Now, it may or may not be appropriate for the document defining the experiment to specify all of this stuff. But if the document doesn't specify these things it at least has to specify the processes that are going to be used to create these specifications. I will also point out that the current draft talks about there being a phase 2 experiment involving XML or OpenOffice as input formats. The vagueness of this part of the proposal is very disturbing - additional details either need to be given or this material needs to be removed. Yet another problem with the current proposal is the security considerations section, which basically says there aren't any. Given that this document proposes using PDF in its full and unrestricted glory it should be obvious why this isn't true. It seems to me that this draft, by omitting specifics about versions and features of PDF to be permitted and, if it isn't obvious, how the submission or editing process automatically verifies that those rules were followed, is not responsive to that consensus. Arguably, on that basis, it should never have been Last Called. I can sort of justify last calling it in order to force people to review it. I certainly hadn't read it all that carefully before. But now that I have read it, my position is that we urgently need a process experiment in this space, but this is absolutely not the right one to run. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
I would also observe that there is significant evidence that there is not a real problem here. It seems to me that if there was a real problem with the graphics, that folks would be publishing RFCs with PS or PDF forms, even if those were not normative. For the thousand RFCs starting with RFC 3000, there are 4 PS and 4 PDF documents. In total, assuming that those are for different documents, that is still less than 1% if those RFCs published in that time period. I know some folks are vocal that there is a problem. But, the evidence suggests otherwise. In contrast, the evidence suggested for judging the experiment is going to be very limited, very subjective, and heavily influenced by the fact that the target are folks who are presumably particularly interested in a positive outcome. This experiment is a bad idea. I am sorry that this is not constructive input. But sometimes the right answer is no. We already have provision for people to publish pretty pictures when they think that is helpful. If lots of folks do that, and if we conclude that those PDFs are more useful than the text documents, then we would have something to discuss. Sure, I hate producing ASCII art. But then, I hate producing document art in any form. The problem is not ASCII. It is finding a good, clean, understandable, way to express ones ideas. Yours, Joel M. Halpern ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
One of the persistent problem today is that bis drafts are harder to write than they should be. Rather than being able to work from the final source, there are often only almost-final, pre-RFC-editor versions in XML (or Word), where one then has to make sure that no late-stage changes are being missed. It can be done, but its tedious. (Even access to the pre-final versions relies on individuals keeping old files around.) Having a more organized and documented source management mechanism in place would help. Joe Touch wrote: Stephane Bortzmeyer wrote: ... IMHO, IETF should always publish the source of its documents (the current RFC process is far from perfect in that respect). Which source (XML2RFC is only one; some use troff, and others use Word, among others)? Why would inter-source conversion be more useful than cut-and-paste? Joe ___ 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: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
(3) Given how popular xml2rfc is I think it makes sense to at least look at how it would best be used to produce PDF documents containing equations and block diagrams. I did this the N-2nd (or maybe 3rd) time we had this discussion and have refined it since. See, e.g., http://electricrain.com/fenner/tmp/draft-my-document-01.pdf . That's svg for the picture (also supported are gif, png, jpg, etc.) and latex for the equation. It's obviously just a proof of concept implementation. The editor screen when working on this document is something like http://electricrain.com/fenner/tmp/svg_eqn_editing.png . There's no WYSIWYG editing of the svn or latex, but you get to see what they look like. This is a $220 XML editor, but its job is mostly to string together other pieces of software so although it's not free software in this implementation, I don't think that means that the same thing can't be implemented with free software (e.g., it uses Batik to render the svg, and if Apache FOP improved some perhaps it could render the FOP to PDF instead of the for-pay (or free-to-download-personal-edition) RenderX) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
The problem here is that the requirement to produce ASCII means that many of the advantages of the pdf format are lost. Any diagrams must be replicated as ASCII art. Any formulas have to be replicated in TXT format. The result is that producing a good PDF version adds hugely to the already complex process of complying with the TXT requirements. -Original Message- From: Joel M. Halpern [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 1:53 PM To: ietf@ietf.org Subject: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats) I would also observe that there is significant evidence that there is not a real problem here. It seems to me that if there was a real problem with the graphics, that folks would be publishing RFCs with PS or PDF forms, even if those were not normative. For the thousand RFCs starting with RFC 3000, there are 4 PS and 4 PDF documents. In total, assuming that those are for different documents, that is still less than 1% if those RFCs published in that time period. I know some folks are vocal that there is a problem. But, the evidence suggests otherwise. In contrast, the evidence suggested for judging the experiment is going to be very limited, very subjective, and heavily influenced by the fact that the target are folks who are presumably particularly interested in a positive outcome. This experiment is a bad idea. I am sorry that this is not constructive input. But sometimes the right answer is no. We already have provision for people to publish pretty pictures when they think that is helpful. If lots of folks do that, and if we conclude that those PDFs are more useful than the text documents, then we would have something to discuss. Sure, I hate producing ASCII art. But then, I hate producing document art in any form. The problem is not ASCII. It is finding a good, clean, understandable, way to express ones ideas. Yours, Joel M. Halpern ___ 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: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Hi, on 2006-06-15 19:52 Joel M. Halpern said the following: I would also observe that there is significant evidence that there is not a real problem here. It seems to me that if there was a real problem with the graphics, that folks would be publishing RFCs with PS or PDF forms, even if those were not normative. For the thousand RFCs starting with RFC 3000, there are 4 PS and 4 PDF documents. In total, assuming that those are for different documents, that is still less than 1% if those RFCs published in that time period. I know some folks are vocal that there is a problem. But, the evidence suggests otherwise. Oh, *good* point. In contrast, the evidence suggested for judging the experiment is going to be very limited, very subjective, and heavily influenced by the fact that the target are folks who are presumably particularly interested in a positive outcome. This experiment is a bad idea. I am sorry that this is not constructive input. But sometimes the right answer is no. We already have provision for people to publish pretty pictures when they think that is helpful. If lots of folks do that, and if we conclude that those PDFs are more useful than the text documents, then we would have something to discuss. Agreed. Thinking some more about this, the lack of inter-document links seem to be a complaint that I hear much more often than the lack of good graphics support. Regards, Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Henrik Levkowetz schrieb: ... Agreed. Thinking some more about this, the lack of inter-document links seem to be a complaint that I hear much more often than the lack of good graphics support. ... I was just thinking about how I'm using RFCs day to day. Answer: usually I don't use the ASCII versions at all. Instead, I try to obtain XML (RFC2629) versions of them, produce HTML, and use that instead (collected at: http://greenbytes.de/tech/webdav/). Why? - Readability - Navigation - Ability to reference a particular section or paragraph with a URL ...and so on. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
This effect may well be the result of the difficulty of getting the draft through the process. It is painful enough dealling with the editing process without having the additional complication of having two documents. -Original Message- From: Henrik Levkowetz [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 3:29 PM To: Joel M. Halpern Cc: ietf@ietf.org Subject: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats) Hi, on 2006-06-15 19:52 Joel M. Halpern said the following: I would also observe that there is significant evidence that there is not a real problem here. It seems to me that if there was a real problem with the graphics, that folks would be publishing RFCs with PS or PDF forms, even if those were not normative. For the thousand RFCs starting with RFC 3000, there are 4 PS and 4 PDF documents. In total, assuming that those are for different documents, that is still less than 1% if those RFCs published in that time period. I know some folks are vocal that there is a problem. But, the evidence suggests otherwise. Oh, *good* point. In contrast, the evidence suggested for judging the experiment is going to be very limited, very subjective, and heavily influenced by the fact that the target are folks who are presumably particularly interested in a positive outcome. This experiment is a bad idea. I am sorry that this is not constructive input. But sometimes the right answer is no. We already have provision for people to publish pretty pictures when they think that is helpful. If lots of folks do that, and if we conclude that those PDFs are more useful than the text documents, then we would have something to discuss. Agreed. Thinking some more about this, the lack of inter-document links seem to be a complaint that I hear much more often than the lack of good graphics support. Regards, Henrik ___ 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: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Henrik Levkowetz schrieb: ... Agreed. And this is of course also the reason why I went to the effort of writing and setting up the htmlization mechanism on tools.ietf.org: Accessing, for any RFC or draft, its name under http://tools.ietf.org/html/ will give you a htmlized version, with at least rudimentary links and section anchors. Example: http://tools.ietf.org/html/rfc4510#section-1 ... Oops. I wasn't aware of the anchors for sections. You may want to make them hrefs as well so people notice. That is, instead of...: a name=section-11/a make it a name=section-1 href=#section-11/a Good stuff! Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
I am personally skeptical about the value of the this experiment. I am concerned about the long term viability of this particular format. (I saw a recent note about a postscript document that supposedly used only core features of postscript, but still could not be printed on a modern printer.) I am also concerned that the document does not specify versions and features. I understand that people may have trouble knowing what versions and features of PDF they are using, it is important to remember that PDF is an active format, and I have seen reports that suitably arranged PDF can carry content which causes harm. Another concern is that this increases the work on the RFC Editor. After performing the editing, and receiving the normative PDF, the RFC Editor must carefully determine if it actually matches the agreed text changes. (Let us assume the author was trying in good faith to do so. Mistakes still get made.) When the PDF was secondary to the text, this was not as large a concern. Finally, this experiment will produce a set of RFCs which live forever with the limitation that those RFCs do not have normative ASCII. What if we decide that this is a bad idea? How do we fix it? Yours, Joel M. Halpern At 10:56 AM 6/14/2006, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Proposed Experiment: Normative Format in Addition to ASCII Text ' draft-ash-alt-formats-02.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-07-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
This draft addresses none of the problems identified the last time it came around, and I strongly encourage the IESG to say no. Although I sympathize with the concern that some RFCs would work better with fancier graphics, PDF isn't a solution to any problem I understand. Most importantly, PDF is not one format, it is a family of formats, and it is all too common to find PDF documents that do not display properly, most often because they depend on non-standard fonts, but sometimes because they depend on features not found in all PDF viewers or printers. I see that librarians who are concerned about archival documents have defined a profile called PDF/A intended for documents with long lifetimes that should work reliably. But I don't know any more about it than that, and in particular I don't know what tools are available to produce PDF/A or to verify that a purported PDF document is indeed compliant with PDF/A. Since the main concern in this draft is that RFCs need better graphics, I would suggest that a simple solution would be to permit ASCII drafts to have accompanying illustrations in a well standardized graphic file format such as GIF (which I think is now out of patent everywhere) or PNG. That would require little change to the editorial process. Finally, I have to say that some of the concerns in this draft are just silly, notably the complaint that ASCII documents look lousy when loaded into Microsoft Word and printed. It's true, but if you think ASCII documents look bad in Word, try loading a PDF into Word and printing that. If someone is using a Windows system, the Notepad program included with all versions of Windows can load and print ASCII files quite nicely. So anyway, please do not conduct this experiment. If we agree that better graphics are important, there are simpler and less risky ways to accomodate them. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor More Wiener schnitzel, please, said Tom, revealingly. The IESG has received a request from an individual submitter to consider the following document: - 'Proposed Experiment: Normative Format in Addition to ASCII Text ' draft-ash-alt-formats-02.txt as an Experimental RFC ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Joel Halpern's comments (below) are right on target. However, Joel is rather too polite. First, I must request that the Internet Draft be retracted in its present form. Section 4 contains a direct quote from one of my messages. However, the quoted sentence was taken brazenly out of context; its sense is quite the opposite of the sense of my original message. This is intolerable. That kind of behavior may get you elected in the US ;-) but it does not belong in the IETF. Now, on to the substance. As the author notes, there was indeed a replay of the usual discussion about RFC formats in winter 2006. The author says, ... the quite thoughtful, extended, and detailed discussion ... resulted in no change. There is a reason it did not result in change... there were cogent arguments against all proposals that were made. So, when it has no good ideas, the IETF randomly picks one of the bad ones? That is apparently happening here. How DID it get last called, by the way? If I write up a arbitrary process experiment, will the IESG automatically last call it? Yummy. The experiment picks on two working groups and specifies that for one year it will treat the results of these working groups differently from all other working group output. How will a future implementor know which version is normative? At present, there is a simple rule... it is always the ASCII version. If this exercise goes ahead, some PDF files (which ones?) will be normative, and some ASCII files won't. This seems like a little hint that process experiment is not a useful procedure for changing the fundamentals of standards publication by the IETF. Besides the misquote of myself, the I-D has some misleading examples of bad ASCII art. You cannot honestly prove that ASCII art is unusable by abusing it. I spent a few minutes cleaning up the terrible example in the I-D (Sorry, I am in Washington and don't have ready access to it; I will forward it when I get back.) As Joel mentions, this experiment will have a negative impact on RFC Editor throughput. Shouldn't the IAB and perhaps the IAD have some part in this? For all the reasons that Joel said, plus the reasons I have given, I request that the IESG reject this last call. At the very least, the base document needs more work, and the implications need more mature thought. And it seems to there is a badly broken process lurking here. I am somewhat astonished that the IESG chose to last call 'this document. Bob Braden At 03:15 PM 6/14/2006 -0400, Joel M. Halpern wrote: I am personally skeptical about the value of the this experiment. I am concerned about the long term viability of this particular format. (I saw a recent note about a postscript document that supposedly used only core features of postscript, but still could not be printed on a modern printer.) I am also concerned that the document does not specify versions and features. I understand that people may have trouble knowing what versions and features of PDF they are using, it is important to remember that PDF is an active format, and I have seen reports that suitably arranged PDF can carry content which causes harm. Another concern is that this increases the work on the RFC Editor. After performing the editing, and receiving the normative PDF, the RFC Editor must carefully determine if it actually matches the agreed text changes. (Let us assume the author was trying in good faith to do so. Mistakes still get made.) When the PDF was secondary to the text, this was not as large a concern. Finally, this experiment will produce a set of RFCs which live forever with the limitation that those RFCs do not have normative ASCII. What if we decide that this is a bad idea? How do we fix it? Yours, Joel M. Halpern At 10:56 AM 6/14/2006, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Proposed Experiment: Normative Format in Addition to ASCII Text ' draft-ash-alt-formats-02.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-07-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ 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: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
On 6/15/06, Bob Braden [EMAIL PROTECTED] wrote: I am somewhat astonished that the IESG chose to last call 'this document. The document does not specify a particular variety of PDF. There are many. The document does not specify the permitted embedded data formats. PDF allows raster and vector images, JavaScript, form validation, fonts, and much more. PDF and some possible embedded data formats are patent encumbered. There are IPR disclosures available. The document incorrectly states that RFC 1119 is available in PDF/PostScript, when it is only available in PostScript. The authors state that commercial software does support ASCII well. Their stated favorite editor, Microsoft Word, does not and will not support PDF: http://www.mercurynews.com/mld/mercurynews/business/14748212.htm PDF/UA is the universally accessible flavor of PDF, but it is not yet standardized, AFAIK. The process outlined in this document is completely inappropriate for an archival document series, for the reasons outlined above. Those were just the glaringly obvious concerns. There are probably more. -- Robert Sayre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
John Levine wrote: This draft addresses none of the problems identified the last time it came around, and I strongly encourage the IESG to say no. Although I sympathize with the concern that some RFCs would work better with fancier graphics, PDF isn't a solution to any problem I understand. Most importantly, PDF is not one format, it is a family of formats, and it is all too common to find PDF documents that do not display properly, most often because they depend on non-standard fonts, but sometimes because they depend on features not found in all PDF viewers or printers. I see that librarians who are concerned about archival documents have defined a profile called PDF/A intended for documents with long lifetimes that should work reliably. But I don't know any more about it than that, and in particular I don't know what tools are available to produce PDF/A or to verify that a purported PDF document is indeed compliant with PDF/A. Since the main concern in this draft is that RFCs need better graphics, I would suggest that a simple solution would be to permit ASCII drafts to have accompanying illustrations in a well standardized graphic file format such as GIF (which I think is now out of patent everywhere) or PNG. That would require little change to the editorial process. If we're talking about line drawings, an object format is more useful than a bitmap such as GIF or PNG. However, like Bob, I don't see the format as the issue, but often the illustrator. It's possible to write poor text and draw poor pictures in ASCII and PDF. The key question is whether there exists a format which is likely to be sufficiently stable that we won't have to revisit this decision in another 35 years. All the proposed formats - including PDF, XML, etc. - are moving targets at this time. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
The key question is whether there exists a format which is likely to be sufficiently stable that we won't have to revisit this decision in another 35 years. All the proposed formats - including PDF, XML, etc. - are moving targets at this time. That's why I suggested GIF. Like ASCII, GIF has its shortcomings, but its definition hasn't changed in 16 years and I've never seen GIF software that doesn't interoperate. I did want to distinguish between targets that someone else moves and targets we move. If we care, we can make sure that some variant of XML2RFC continues to work even if XML is a moving target, so relying on our ability to process XML and produce RFCs in 35 years is probably pretty darned safe. If someone else can move a target, that's more likely to be living dangerously, I think. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Spencer Dawkins wrote: The key question is whether there exists a format which is likely to be sufficiently stable that we won't have to revisit this decision in another 35 years. All the proposed formats - including PDF, XML, etc. - are moving targets at this time. That's why I suggested GIF. Like ASCII, GIF has its shortcomings, but its definition hasn't changed in 16 years and I've never seen GIF software that doesn't interoperate. I did want to distinguish between targets that someone else moves and targets we move. If we care, we can make sure that some variant of XML2RFC continues to work even if XML is a moving target, so relying on our ability to process XML and produce RFCs in 35 years is probably pretty darned safe. And forces us to use a single version of a tool in which to write I-Ds. By that argument, any format we define is a static target, but equally useless in a fairly short time. It'd also be nice for us to be able to use modern editing tools, rather than chiseling out drafts in source code like we did in the 1970s. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
