Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
On Jun 16, 2006, at 3:46 PM, Joe Touch wrote: Forcing the input format means one of two things: - edit source code (argh - back to the stone age) I think we would generally get better results if Internet Standards were authored by people who are comfortable editing source code. - force a limited set of editing software That's a fair complaint. But for what it's worth, professional reference publishing organizations, who care a whole lot about the longevity and re- usability of the material they create, generally do standardize on the editable input format, and assume there will be a variety of output formats generated to meet consumer needs, which change from place to place and time to time. -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))
> 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: ASCII is dead, long live ASCII (was: Image attachments to ASCII RFCs)
By the way, might we - - - perhaps EBCDIC ??? It is much better than ASCII because it sorts numbers where they belong, behind the letters and not in front of them. And please keep a space not a tab and no printable character in column one. I need it for printcontrol. EBCDIC has got all the graphic characters you ever need. It is a standart and it is multiplatform. Any comments? Well, you left out my personal favorite: In ASCII: 'z' - 'a' + 1 = 26 but in EBCDIC: 'z' - 'a' + 1 = 41 (or something close to that - it has been a while since I had to deal with EBCDIC.) With cool properties like this, EBCDIC sure seems like a winner to me... lol and rofl favoured :) Agreed! Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs
Carl Malamud wrote: 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." Is this an issue? "Most clients" and "the user" doesn't realistically describe the entity which produces RFCs, do they? Whatever we decide that the RFC editor needs the ability to do, whether it be "export to PDF/A and make sure all fonts are self-contained and don't include embedded video" or "produce clay tablets in cunieform", then we need only ensure that the RFC editor has access to _a_ tool which can do what we decided. Everyone else need merely _read_ what the RFC editor produced. And, "Most clients" can probably do that. Isn't that one of the primary responsibilities of this office, to ensure that, whatever format we decide upon, the RFCs all match the chosen format? -- Unable to locate coffee. Operator halted. ___ 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))
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: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
Carl Malamud wrote: This is not a job for a committee-of-the-whole ... I'd be perfectly happy to let the IAB or IESG pick a religion and let a working group define the rules of procedure. And, again, piggybacking on the w3c religion seems like a really easy way out of this never-ending debate. As a point of information, although w3c do do a fine job, they do change their Pubrules [1] now and then too, so that roughly every time you get to the equivalent of the rfc-editor, some subtle rule has changed and you have to figure stuff out. Not a show-stopper, but w3c's approach isn't hassle free and mightn't travel that well in some respects. Having said that, I'd be for us experimenting with a parallel ascii/w3c-html approach and we even have an excellent precedent with xmldsig [2,3]. Stephen. [1] http://www.w3.org/Guide/pubrules [2] http://www.ietf.org/rfc/rfc3275.txt [3] http://www.w3.org/TR/xmldsig-core/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
Iljitsch van Beijnum wrote: > On 17-jun-2006, at 0:18, Joe Touch wrote: > >> It's worth distinguishing the search for alternate normative output >> formats from the search for a standard input format. > > I think the mistake is to make the output format normative. If we make > the input format normative and publish that we're out of the woods: > obviously the input format is editable, and if it's sufficiently (but > not overly) well-defined output formats can be generated as desired. Forcing the input format means one of two things: - edit source code (argh - back to the stone age) - force a limited set of editing software I find neither useful nor productive. >>> I'm very partial to xml2rfc, > > I'm sorry to be so negative, but I hate it. The stupid thing can't even > handle my name properly so I have to live with what it does or edit the > result manually. I gave up on it when cut/paste of blocks was more likely to render the result uncompilable and impossible to repair. > XML2RFC once made me miss a draft deadline by choking on some XML I > wrote without saying why or where, leaving me with an impossible > debugging task. Formatting drafts in vi may take longer on average than > working with xml2rfc but it's more deterministic. I found the new Word template let me focus on what it was I was writing, and freed me from the arcane details of how it was encoded or processed. That, IMO, is the purpose of the input format. Anything that's less freeing is a step backwards. 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: 'ProposedExperiment: Normative Format in Addition to ASCII Text' toExperimental RFC (draft-ash-alt-formats))
> From: Noel Chiappa [mailto:[EMAIL PROTECTED] > > 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. Do you fear that the world's desire to hear the pearls of wisdom of the IETF will be any less than for Tim's team? This problem is precisely the reason why standards exist for HTML. Congress has its archives kept in SGML, the Oxford English Dictionary is in HTML. Unless there is a major catastrophe that wipes out enough human life that the Internet ceases to be viable in any case there is absolutely no possibility that the ability to read legacy HTML formats will be lost. Congress and other world governments have committed billions worth of documents to digital archives. It could be that the IETF has got this right and everyone else including the professionals in the document archiving business have got it right. But the probability is overwhelmingly that the reverse is the case. And if the professionals have perchance got it wrong more billions will be available to fix their mess. All it takes to ensure that the IETF XHTML corpus is compliant with the latest version is to run a perl script once a decade. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
Carl Malamud wrote: >> It's worth distinguishing the search for alternate normative output >> formats from the search for a standard input format. >> >> Or are you proposing 2629bis as a standard intermediate format, which >> makes both camps (input and output) unhappy? > > I think we should pick one somewhat complete solution set and > ride on top of that. For example, the w3c approach is one wagon > to hitch up to. After we hitch up to a wagon, we should commission > a working group to work out any additional details and the rest of > us agree to live with it if they do a decent job. Anything that results in an editor that supports what modern word processors support (collapsible outline views, in particular) is fine with me; right now, that means Word. > This is not a job for a committee-of-the-whole ... I'd be > perfectly happy to let the IAB or IESG pick a religion and let > a working group define the rules of procedure. And, again, > piggybacking on the w3c religion seems like a really easy > way out of this never-ending debate. I'd prefer if they pick an output format that is supported by a number of editors, rather than forcing an editing system designed, implemented, and supported by amateurs on me. 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 Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
On 17-jun-2006, at 0:18, Joe Touch wrote: It's worth distinguishing the search for alternate normative output formats from the search for a standard input format. I think the mistake is to make the output format normative. If we make the input format normative and publish that we're out of the woods: obviously the input format is editable, and if it's sufficiently (but not overly) well-defined output formats can be generated as desired. I'm very partial to xml2rfc, I'm sorry to be so negative, but I hate it. The stupid thing can't even handle my name properly so I have to live with what it does or edit the result manually. The problem with xml2rfc is that tries to be too smart by encoding semantics. In theory this is the right thing to do, because you can then do stuff like search for a specific author without catching acknowledgment sections or find certain versions of the legalese. But the problem is that this requires tools that either don't exist at all, or aren't in wide use, so in practice it's actually harder to work with the XML source than with the resulting draft/RFC format. XML2RFC once made me miss a draft deadline by choking on some XML I wrote without saying why or where, leaving me with an impossible debugging task. Formatting drafts in vi may take longer on average than working with xml2rfc but it's more deterministic. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
> It's worth distinguishing the search for alternate normative output > formats from the search for a standard input format. > > Or are you proposing 2629bis as a standard intermediate format, which > makes both camps (input and output) unhappy? I think we should pick one somewhat complete solution set and ride on top of that. For example, the w3c approach is one wagon to hitch up to. After we hitch up to a wagon, we should commission a working group to work out any additional details and the rest of us agree to live with it if they do a decent job. This is not a job for a committee-of-the-whole ... I'd be perfectly happy to let the IAB or IESG pick a religion and let a working group define the rules of procedure. And, again, piggybacking on the w3c religion seems like a really easy way out of this never-ending debate. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
It's worth distinguishing the search for alternate normative output formats from the search for a standard input format. Or are you proposing 2629bis as a standard intermediate format, which makes both camps (input and output) unhappy? Joe Carl Malamud wrote: > Hi - > > There's been an awful lot of traffic on this subject, both this time > around and in the perpetual past. My $0.02 is that we're a standards > body and we shouldn't invent a new document profile/standard. That's > not our business, so we should steal code. > > We have a home-grown effort done by a few people since 1998, which > has been doing fairly well. That's a self-contained body of work, > which could easily be supplemented by a working group effort to > evolve the specs. If we're going to be NIH, that seems like the > logical option to consider. > > If we don't do that, we should adopt what seems to work well for others. > W3C standards look great, they've thought hard about the document format, > and that's the business they're in. > > If we're going to last call something, I think it should be a choice > from a list of existing bodies of work: w3c, xml2rfc, or any of the > other document-production systems (OASIS, Docbook, ITU, OSI, or > whatever you want). > > I'm very partial to xml2rfc, but I also see a lot of power in a > joint w3c/ietf spec. That will get you tools pretty quick. If the > IESG or the IAB recommended one path to take, a working group could > pretty quickly do any necessary tweaks (e.g., mapping to 2629 or > 2629bis). > > Carl > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf 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))
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: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
Hi - There's been an awful lot of traffic on this subject, both this time around and in the perpetual past. My $0.02 is that we're a standards body and we shouldn't invent a new document profile/standard. That's not our business, so we should steal code. We have a home-grown effort done by a few people since 1998, which has been doing fairly well. That's a self-contained body of work, which could easily be supplemented by a working group effort to evolve the specs. If we're going to be NIH, that seems like the logical option to consider. If we don't do that, we should adopt what seems to work well for others. W3C standards look great, they've thought hard about the document format, and that's the business they're in. If we're going to last call something, I think it should be a choice from a list of existing bodies of work: w3c, xml2rfc, or any of the other document-production systems (OASIS, Docbook, ITU, OSI, or whatever you want). I'm very partial to xml2rfc, but I also see a lot of power in a joint w3c/ietf spec. That will get you tools pretty quick. If the IESG or the IAB recommended one path to take, a working group could pretty quickly do any necessary tweaks (e.g., mapping to 2629 or 2629bis). Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ASCII is dead, long live ASCII (was: Image attachments to ASCII RFCs)
Michael Thomas wrote: Hallam-Baker, Phillip wrote: 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. Which tools would those be? Cat, tr, emacs, vi, grep, cut, sed, curses, wc, more or less? I absolutely need vi and grep. PDF is nasty because is lacks these tools. Am a Luddite. I like ASCII. I despise PDF, and most especially its hideous anti-aliased fonts. As software engineer, I don't need drawings that I can use to run a lathe or a milling machine. Simple stick figures, ladder diagrams, and boxes for bits and bytes are about all I really need to see to transform an RFC into code. As protocol designer, the fewer Paper Clips sent by Beelzebub himself, the better. If it can't be edited using the buffer gap method, I'm not interested. Victorian? Pah. The death of Prince Albert of Ascii would require a minimum of a year of mourning, and a smart new black wardrobe for Phill. Not to mention a cross sovereign. Mike, we are not amused. By the way, might we - - - perhaps EBCDIC ??? It is much better than ASCII because it sorts numbers where they belong, behind the letters and not in front of them. And please keep a space not a tab and no printable character in column one. I need it for printcontrol. EBCDIC has got all the graphic characters you ever need. It is a standart and it is multiplatform. Both kermit and ftp can handle EBCDIC. Even the PC and Apple addicts can use it. You can use dd to translate between ASCII and EBCDIC http://www.scit.wlv.ac.uk/cgi-bin/mansec?1M+dd So it is already present on all decent operating systems. Using the 3270 telnet option, all decent browsers allow reading EBCDIC pages. No need for plugins. Any comments? lol and rofl favoured :) apropos There exist readers for ASCII and EBCDIC either Braille or literally readers for the blind and for people with reading disabilities. Internet sans frontiers. 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))
> 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))
> 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: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
On 16-jun-2006, at 22:57, Ted Faber wrote: SVG is currently exportable into most major bitmap formats. http://librsvg.sourceforge.net/ the converter is rsvg. Runs out of the box on most free unices. Of course, you can't go back from the bitmap to the vector, which is exactly the point. Right. And since most of us don't have native vector displays, you can't work directly with what you see, you need to go through a layer of software. When you're designing stuff that has to look pretty in print, such as logos, you'll want to use vector so you can use whatever native resolution you find on your way down the road. Figures in technical documents are a very different matter: there is no reason for making the pixels so small that you can't see them as individual pixels anymore. The opposite is true: if you make them nice and big you can make each and every one of them count, think MacPaint. Yes, this looks bad and backwards, but it's very easy to draw in the first place compared with the more advanced stuff, and this goes double for editing an existing image. With a 16 color 640x480 bitmap you can easily pick pieces up and move them somewhere else, and align them exactly. With vector graphics this is infinitely harder Once you've sampled the image to put it in a bitmap you've lost information. You assume that there is information in the barely visible details. I hope this isn't true for the technical drawings you work with. One of the complications with vector graphics is that you can scale them easily, but they're not usable at every scale. For instance, I regularly receive Visio documents where the text is SO small that I can't read it even if I make the picture fill my entire laptop screen. Apparently the person who created that image likes small fonts and has a very high resolution monitor. With bitmaps you can easily set a maximum size and whether text is readable is painfully obvious so this problem can't really happen. But we are describing an *archival* format. It's not important that they be editable, Yes, it is. It's useful, but the primary issue is to be able to view them. That's what archival means. JUST being abble to view them isn't good enough. Even if you care about editing, it really depends on what kind of editing you want to do. Edge detection is not so easy in a vector representation, but selecting a box or hunk of text is much easier. I think I'm much more likely to do the latter on an RFC document than the former. Well, if you like doing this in SVG or PDF, I have no problem with that. As long as the normative version is the simple version: ASCII for text, simple bitmap for images. Or even better: no images. ___ 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))
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
ASCII is dead, long live ASCII (was: Image attachments to ASCII RFCs)
Hallam-Baker, Phillip wrote: 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. Which tools would those be? Cat, tr, emacs, vi, grep, cut, sed, curses, wc, more or less? Am a Luddite. I like ASCII. I despise PDF, and most especially its hideous anti-aliased fonts. As software engineer, I don't need drawings that I can use to run a lathe or a milling machine. Simple stick figures, ladder diagrams, and boxes for bits and bytes are about all I really need to see to transform an RFC into code. As protocol designer, the fewer Paper Clips sent by Beelzebub himself, the better. If it can't be edited using the buffer gap method, I'm not interested. Victorian? Pah. The death of Prince Albert of Ascii would require a minimum of a year of mourning, and a smart new black wardrobe for Phill. Not to mention a cross sovereign. Mike, we are not amused. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
On Fri, Jun 16, 2006 at 10:24:26PM +0200, Iljitsch van Beijnum wrote: > On 16-jun-2006, at 19:25, Lyndon Nerenberg wrote: > > >>As far as I know, support for SVG or _any_ vector image format is > >>much, much less common than for bitmap formats such as PNG or GIF. > > >Yes, but SVG is catching up rapidly. As a W3C standard, it *will* > >be widely implemented. > > We'll have to wait for that before we could use it. And I don't > believe for a second that it will come close to bitmap formats. SVG is currently exportable into most major bitmap formats. http://librsvg.sourceforge.net/ the converter is rsvg. Runs out of the box on most free unices. Of course, you can't go back from the bitmap to the vector, which is exactly the point. Once you've sampled the image to put it in a bitmap you've lost information. That's why we're advocating starting from a maximum information remresentation. (Yes it's only maxmimum information for diagrams and the like, but that's what appear in RFCs.) > >But we are describing an *archival* format. It's not important > >that they be editable, > > Yes, it is. It's useful, but the primary issue is to be able to view them. That's what archival means. Even if you care about editing, it really depends on what kind of editing you want to do. Edge detection is not so easy in a vector representation, but selecting a box or hunk of text is much easier. I think I'm much more likely to do the latter on an RFC document than the former. > >it's important that they be renderable on the widest range of > >output devices as is possible. > > And you think vector graphics fit that requirement better than bitmap > graphics??? Any time you scale a bitmap to a new resolution you lose information. This is not true of a vector representation. At the very worst, I can render an SVG (or a pic diagram - choose your favorite vector representation) into a PNG and display it however you would display the PNG you want to store. But the SVG user can pick the resolution of their PNG to match the output device and that PNG will be undistorted beyond the natural sampling limits. An SVG user always has the highest possible resolution bitmap available as well as the thumbnails free from scaling artifacts. No matter what resolution or encoding future devices use, a vector representation starts from a very high (if not maximal) amount of information about the image. That high content description can be sampled into a raster at whatever resolution or color model is approriate. If you start from the sampled raster you will never be able to generate a more detailed image free from artifacts. Breathe deeply and think about that. That's the point, not how many browsers will render SVGs today, or whether the gimp or photoshop likes them. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpH6qLYtOdzp.pgp Description: PGP 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)
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))
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: 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: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
On 16-jun-2006, at 19:25, Lyndon Nerenberg wrote: As far as I know, support for SVG or _any_ vector image format is much, much less common than for bitmap formats such as PNG or GIF. Yes, but SVG is catching up rapidly. As a W3C standard, it *will* be widely implemented. We'll have to wait for that before we could use it. And I don't believe for a second that it will come close to bitmap formats. So editing bitmaps is fairly trivial with well-defined results. With vector formats, there is a very complex one-way relationship between the file and what you see on the screen so the ability to edit them requires much, much more complexity. But we are describing an *archival* format. It's not important that they be editable, Yes, it is. it's important that they be renderable on the widest range of output devices as is possible. And you think vector graphics fit that requirement better than bitmap graphics??? ___ 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: IETF IPv6 platform configuration
All, Thank you for your feedback and request. By default, our practice is to disable these functions until there is a justified need/request. We have enabled ICMP echo, ICMP traceroute, and UDP traceroute. Once again, we encourage and look forward to your responses and requests. The IETF Secretariat. > > -Original Message- > From: Joe Touch [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 15, 2006 11:56 AM > To: Iljitsch van Beijnum > Cc: [EMAIL PROTECTED]; Mark Andrews; ietf@ietf.org > Subject: Re: IETF IPv6 platform configuration > > > > Iljitsch van Beijnum wrote: > > On 15-jun-2006, at 1:51, Mark Andrews wrote: > > > >> > >>> *Only HTTP, SMTP, FTP, and DNS traffic are permitted > through an IPv6 > >>> Native firewall (pings, traceroutes etc. are dropped) > > > >> Why? Shouldn't we be prompting good firewall practices? > > > >> Droping ICMP was a knee jerk reaction to ICMP echo to > >> directed broadcast addresses. Modern routers can be > >> configured to drop directed broadcast packets. > > > > And all of this doesn't even apply to IPv6, it doesn't even support > > broadcasts in general or anything resembling directed > broadcast. ICMP > > replies are also supposed to be rate limited in IPv6. > > IPv4 too. There are other reasons to drop them at firewalls (net > mapping, protecting other protocols), but I agree we ought to be an > example of the best the Internet can provide, not the most paranoid. > > Joe > > ___ 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". 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 Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
As far as I know, support for SVG or _any_ vector image format is much, much less common than for bitmap formats such as PNG or GIF. Yes, but SVG is catching up rapidly. As a W3C standard, it *will* be widely implemented. So editing bitmaps is fairly trivial with well-defined results. With vector formats, there is a very complex one-way relationship between the file and what you see on the screen so the ability to edit them requires much, much more complexity. But we are describing an *archival* format. It's not important that they be editable, it's important that they be renderable on the widest range of output devices as is possible. --lyndon ___ 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: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
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. ... >> Why would inter-source conversion be more useful than cut-and-paste? > > I don't have experience with MS-Word but (re)generating the RFC 2629 > source from the ASCII version is a big pain (while there are automatic > converters, for instance from *roff to XML and, of course, from one > XML to the other). In Word it's fairly simple to paste, remove the leftside indent, and rewrap the paragraphs quickly. Setting heading types, lists, and figures can be automated with scripts, but I haven't bothered to do that; it's sufficiently quick to do that manually, IMO. I have heard there are tools to back-port output to XML or nroff approximations which, like Word paste, often need manual adjusting, but haven't used them myself. 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)
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
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching ofLanguage Tags' to BCP (draft-ietf-ltru-matching)
With respect to the specific document that led to this discussion, draft-ietf-ltru-matching, I have asked the WG members at http://www1.ietf.org/mail-archive/web/ltru/current/msg04975.html as follws: If anybody who has contributed would like their name to be mentioned, or thinks that somebody else's name is missing, please don't hesitate to say so, or to contact the editors or chairs directly. I am not aware of any such requests up to now, but maybe my co-chair or the editors have received some. Just for completeness, and because this is due to a Last Call comment brought up on this mailing list, I would like to extend the above request to this list: If you think that you should be listed in the Acknowledgements section of draft-ietf-ltru-matching, please contact the editors or the chairs of the LTRU WG. Regards, Martin. At 17:02 06/06/07, Stephane Bortzmeyer wrote: >On Wed, Jun 07, 2006 at 03:58:15AM +0200, > JFC (Jefsey) Morfin <[EMAIL PROTECTED]> wrote > a message of 13 lines which said: > >> - Appendix A - some names seem to be missing. I could quote a small >> score of them? > >I do not know if there are written rules about the "Acknowledgements" >or "Credits" section in a RFC. It seems quite variable between the >RFCs. I am mentioned in draft-ietf-ltru-matching-14 for what I regard >as a very small contribution and not in RFC 4408 where I feel that my >contribution is more substantive. > >Anyway, these appendices are not normative and are only useful for >historical reasons and to brush the ego :-) > > > >___ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 110 messages in the last 7 days. script run at: Fri Jun 16 00:03:01 EDT 2006 Messages | Bytes| Who +--++--+ 9.09% | 10 | 8.88% |61612 | [EMAIL PROTECTED] 6.36% |7 | 10.74% |74511 | [EMAIL PROTECTED] 5.45% |6 | 9.98% |69192 | [EMAIL PROTECTED] 5.45% |6 | 4.96% |34368 | [EMAIL PROTECTED] 5.45% |6 | 4.35% |30167 | [EMAIL PROTECTED] 3.64% |4 | 3.16% |21947 | [EMAIL PROTECTED] 2.73% |3 | 2.92% |20272 | [EMAIL PROTECTED] 2.73% |3 | 2.44% |16903 | [EMAIL PROTECTED] 2.73% |3 | 2.42% |16809 | [EMAIL PROTECTED] 2.73% |3 | 2.40% |16640 | [EMAIL PROTECTED] 2.73% |3 | 2.31% |16011 | [EMAIL PROTECTED] 2.73% |3 | 2.05% |14221 | [EMAIL PROTECTED] 1.82% |2 | 2.19% |15185 | [EMAIL PROTECTED] 1.82% |2 | 1.95% |13503 | [EMAIL PROTECTED] 1.82% |2 | 1.74% |12037 | [EMAIL PROTECTED] 1.82% |2 | 1.70% |11795 | [EMAIL PROTECTED] 1.82% |2 | 1.66% |11526 | [EMAIL PROTECTED] 1.82% |2 | 1.62% |11221 | [EMAIL PROTECTED] 0.91% |1 | 2.43% |16879 | [EMAIL PROTECTED] 1.82% |2 | 1.50% |10423 | [EMAIL PROTECTED] 1.82% |2 | 1.49% |10348 | [EMAIL PROTECTED] 1.82% |2 | 1.45% |10067 | [EMAIL PROTECTED] 1.82% |2 | 1.43% | 9892 | [EMAIL PROTECTED] 1.82% |2 | 1.38% | 9595 | [EMAIL PROTECTED] 1.82% |2 | 1.37% | 9536 | [EMAIL PROTECTED] 0.91% |1 | 1.46% |10144 | [EMAIL PROTECTED] 0.91% |1 | 1.40% | 9744 | [EMAIL PROTECTED] 0.91% |1 | 1.23% | 8541 | [EMAIL PROTECTED] 0.91% |1 | 1.09% | 7529 | [EMAIL PROTECTED] 0.91% |1 | 0.98% | 6808 | [EMAIL PROTECTED] 0.91% |1 | 0.82% | 5664 | [EMAIL PROTECTED] 0.91% |1 | 0.80% | 5532 | moore@cs.utk.edu 0.91% |1 | 0.76% | 5277 | [EMAIL PROTECTED] 0.91% |1 | 0.76% | 5253 | [EMAIL PROTECTED] 0.91% |1 | 0.75% | 5222 | [EMAIL PROTECTED] 0.91% |1 | 0.75% | 5200 | [EMAIL PROTECTED] 0.91% |1 | 0.72% | 5016 | [EMAIL PROTECTED] 0.91% |1 | 0.72% | 5016 | [EMAIL PROTECTED] 0.91% |1 | 0.72% | 5015 | [EMAIL PROTECTED] 0.91% |1 | 0.71% | 4909 | [EMAIL PROTECTED] 0.91% |1 | 0.69% | 4771 | [EMAIL PROTECTED] 0.91% |1 | 0.66% | 4599 | [EMAIL PROTECTED] 0.91% |1 | 0.65% | 4527 | [EMAIL PROTECTED] 0.91% |1 | 0.64% | 4458 | [EMAIL PROTECTED] 0.91% |1 | 0.64% | 4446 | [EMAIL PROTECTED] 0.91% |1 | 0.62% | 4286 | [EMAIL PROTECTED] 0.91% |1 | 0.60% | 4188 | [EMAIL PROTECTED] 0.91% |1 | 0.60% | 4184 | [EMAIL PROTECTED] 0.91% |1 | 0.57% | 3946 | [EMAIL PROTECTED] 0.91% |1 | 0.53% | 3710 | [EMAIL PROTECTED] 0.91% |1 | 0.53% | 3677 | [EMAIL PROTECTED] 0.91% |1 | 0.52% | 3629 | [EMAIL PROTECTED] 0.91% |1 | 0.52% | 3578 | [EMAIL PROTECTED] +--++--+ 100.00% | 110 |100.00% | 693529 | Total ___ 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)
> 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 AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
> In point of fact the above license is exactly the form of license that Sun attempted to sue Microsoft over. This is one of those rare cases (a previous one being Sun vs. Microsoft over Java) where IPR is being used to advance standardization, rather than to hinder it. When an IPR holder party uses its leverage to ensure that a major player does not hijack a popular platform by creating a proprietary variant, it is in our interest, and does not threaten us in any way. Were there to be a party with IPR on ASCII who allowed its unlimited use unless someone insisted on interchanging the codes of several letters, would you insist that we not use ASCII ? Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
On 16-jun-2006, at 10:41, Martin Duerst wrote: But PNG should only be used for raster images, not for graphics. SVG will provide the necessary scaling/positioning information for embedded PNG images, so the device resolution concern is addressed. As far as I know, support for SVG or _any_ vector image format is much, much less common than for bitmap formats such as PNG or GIF. The point here isn't to make the images as pretty as possible, but to convey information as efficiently as possible (including the ability to update it) and in a way that is guaranteed to be decipherable for decades to come. Bitmaps are much better for this because there is a one-to-one translation in both directions between what's on the screen and what's in the file. So editing bitmaps is fairly trivial with well-defined results. With vector formats, there is a very complex one-way relationship between the file and what you see on the screen so the ability to edit them requires much, much more complexity. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
At 02:49 06/06/16, Lyndon Nerenberg wrote: >> * Use of MHTML as the archive packaging. >> * Use of XHTML 1.0 as the document encoding. >> * Use of a standard IETF defined style sheet. >> * Use of PNG encoding for all images. > >I'm in agreement with the first three, but I disagree with using PNG for >graphics. PNG is a device output format that doesn't mesh with the other >three, which are media-neutral input formats. > >Output media properties change (rapidly) over time. PNG doesn't accommodate >changing output device resolution nicely. Do you generate graphics for 72DPI? >100? 300? None of these will scale (literally or figuratively) to the 1600DPI >(and beyond) devices we can expect in the foreseeable future. In this case I >think SVG is a better alternative. It has the attributes of PNG (open >standard, unencumbered IPR) and the added benefit of media independence. As it happens, SVG requires support for PNG, see http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#ImageElement. But PNG should only be used for raster images, not for graphics. SVG will provide the necessary scaling/positioning information for embedded PNG images, so the device resolution concern is addressed. Regards,Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[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)
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). > (XML2RFC is only one; some use troff, and others use Word, among > others) Sure. This is not a problem for me. I just want to see the source, as the author saw it. > Why would inter-source conversion be more useful than cut-and-paste? I don't have experience with MS-Word but (re)generating the RFC 2629 source from the ASCII version is a big pain (while there are automatic converters, for instance from *roff to XML and, of course, from one XML to the other). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
