Re: An I-D experiment (Re: HTML better for small PDAs)
Taking the sort of paranoid approach that befits assurances of stability, needed for people doing critical operations, I look for a well-established range of products and for wide-spread use. Because IETF documents are used far beyond the confines of the IETF, the term "wide-spread" needs to work with Internet scaling, not just IETF scaling. dave - i don't know how to say this politely, so i'll just say it: the ietf is one of the least xml-friendly communities out there. i think that colors your thinking. Until then, it is not appropriate to change the massively-stable base that forms the encoding rules for RFCs. XML as an adjunct is fine. As a primary form for RFCs? Not yet. err, i don't recall anyone proposing this. if you're going to argue against something, first make sure that someone proposed it, ok? /mtr
Re: An I-D experiment (Re: HTML better for small PDAs)
From: "Marshall T. Rose" [EMAIL PROTECTED] To: "Dave Crocker" [EMAIL PROTECTED] ... Until then, it is not appropriate to change the massively-stable base that forms the encoding rules for RFCs. XML as an adjunct is fine. As a primary form for RFCs? Not yet. err, i don't recall anyone proposing this. if you're going to argue against something, first make sure that someone proposed it, ok? There have been several proposals recently and many over the years to replace the current encoding rules for RFCs. Check some of the recent threads at http://www.ietf.org/mail-archive/ietf/Current/threads.html As far as I can tell, no one who has ever used an RFC to design or implement anything has made such a proposal, but that does not mean that the proposals are safe to ignore. For one reason, most IETF participants have not and will never use an RFC to design or implement anything, unless your use of those words coincides with those who write about "designing and implementing TCP/IP in the enterprise." I bet that if a vote were held today, and if not only "legacy Internet programmers" but all subscribers to this mailing list voted, ASCII would finish behind HTML, MS Word, XML, UNICODE, and perhaps others. Yes, I realize voting is forbidden and this is a good example why. Vernon Schryver[EMAIL PROTECTED]
Re: An I-D experiment (Re: HTML better for small PDAs)
There have been several proposals recently and many over the years to replace the current encoding rules for RFCs. Check some of the recent threads at http://www.ietf.org/mail-archive/ietf/Current/threads.html blah, blah, blah. i'm familiar with this thread, and the thread that pops up every 6 months or so... but where is the actual "proposal". all i see is the usual "wouldn't it be nice if" and never anything concrete. if someone actually produces a proposal, then we can discuss it or nuke it. perhaps a more useful mode of discussion would be to determine what criteria should be used for the rfc publication process and whether incremental improvements are possible, independent of encoding changes. /mtr
Re: An I-D experiment (Re: HTML better for small PDAs)
A premise behind the formatting rules for IETF documents is that they are easy to create and easy to read. As popular as XML is in the minds of the technical community, there are few tools for creating it and little widespread use of it. So far. dave - i think this is one of those ymmv things. i know a lot of people who do a lot of xml input using wysiwyg editors. rfc 2629 listed a couple of tools from a couple of years ago, there are a lot more out there now. in other words, i politely question the basis for your assertion above. for myself, i use emacs simply because i can use it to edit all kinds of files on all kinds of systems. this is a trade-off from having xml-specific support, but that's okay. finally, for those folks who are using the rfc2629-based tool called xml2rfc: there is a new release available that generates nroff, in addition to txt (rfc 2223) and html. the reason why it generates nroff is that you can give that to the rfc-editor along with your txt file and it gives them a leg up on their editing process - http://xml.resource.org/ /mtr
Re: HTML better for small PDAs
"graham" == graham travers [EMAIL PROTECTED] writes:
graham In my, limited, coding experience, I don't recall finding ASCII diagrams as
graham part of the code. Poor diagrammatic capability is one of the problems I
Perhaps that's why you don't write much code.
Almost all of my code quotes the relevant parts of the RFC. Particularly
the ASCII diagrams. Pretty hard to embed a Visio2000 diagram in the middle of
a comment in C.
graham IMHO, standards are about far more than writing code; first, and most
graham importantly, they are about achieving agreement. ( Otherwise we could all
Yes, you are right. They are about agreeing what is important.
graham just go off and write whatever code we want. ) This requires a common mind
graham set, and a suitable level of understanding to form it. I am in favour of
The mind set that has made the Internet what it is today is the same
mindset that prefers ASCII. The telcos which now claim to dominate the
Internet missed building it in the 1980s, mostly missed in the 1990s (when
Cisco became very well known), and seem to be about to miss the boat again.
Maybe that's because they don't know how to do diagrams in ASCII. Maybe
there are other reasons.
graham making it as easy as possible for common understanding to be reached.
After
graham all, the subjects are complex enough to understand, without being hampered
graham by poor communication tools.
If they are that complicated, then they are too complicated.
ASCII diagrams are a complexity filter.
] Train travel features AC outlets with no take-off restrictions|gigabit is no[
] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[
] [EMAIL PROTECTED] www.solidum.com the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
RE: An I-D experiment (Re: HTML better for small PDAs)
At 12:08 AM 2/28/2001, [EMAIL PROTECTED] wrote: [ It is precisely because we do not operate a "sweat shop" that we do not expect everybody to engage on ALL the IETF lists. We have the quaint idea that the work should be shared out. Oddly enough, we have a company hierarchy, in which some people work for others. Apparently, this concept of organisation is outside your experience. In all likelihood, Vernon has more corporate experience than you. On the other hand, it is in a company with some unusual organizational models that permit senior contributors to work largely outside the classic corporate structure. For that matter, the hierarchical formal model of the IETF is deceptive. In very real and substantial ways, the IETF works in a fashion far different from most organizations. Initiatives are almost always from the bottom. Development is from the bottom. Decisions are almost always from the bottom. How many corporations work that way? The IETF hierarchy provides administrative coherence and does periodic technical sanity enforcement. This latter can get quite authoritarian, but is really a negotiation between management and a working group, and it occurs at very selected milestones only. Abuse is the refuge of the irrational. I note that you would prefer to reserve the right to "Contribute To The Standards Process" for yourself and other high-minded individuals. This is presumably the famed IETF " openness" in action. ] And an experienced technical manager knows better than to take the bait from a typically eccentric techie. They also know better than to react to a comment from a single contributor and assume that it in any way pertains to a group norm. That some people HATE the ASCII format is not evidence about whether ASCII is incomplete. You managed to miss this part of Vernon's response. There is a difference between happiness and productivity. And, for that matter, when have you had a GOOD project where the engineers did not complain? Personally I believe we can do better than ASCII, but there are 30 years of history showing that it is an astonishingly good form and that the forms used in other venues often result in more arcane documents. [ So, from now on all IETF illustrated presentations will consist solely of diagrams of packets, because any red-blooded protocol developer worth his salt is a wimp if he wants to draw anything else to help people understand what his I-D is saying. Oh, and, of course, if anyone dares to use anything but ASCII, then he can't be a protocol developer, can he ] Vernon was talking about specification documents. And here you go on to make comments about presentations. Vernon was talking about requirements for specifications. That is different from what people prefer for presentations. And from the style of your paragraph, here, the comment about managers taking the bait comes to mind again. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com tel: +1.408.246.8253; fax: +1.408.273.6464
RE: HTML better for small PDAs
John, You make some good points; and, unlike some, I never claim to be right all the time. Would you not concede, though, that coders ( should ) write to implement requirements, which are typically not defined by the coders themselves, but by their "customers" ? The IETF publishes lots of I-Ds which give requirements, rather than coding solutions. The people who write these requirements are not necessarily coders themselves. In my, limited, coding experience, I don't recall finding ASCII diagrams as part of the code. Poor diagrammatic capability is one of the problems I have with ASCII. I am not trying to push a particular format, just to explore other possibilities. You previous point about people choosing to use a "copy that's easier for some people to read" is interesting. Doesn't it imply that we should consider other formats ? At the least, it implies to me that ASCII is far from perfect. IMHO, standards are about far more than writing code; first, and most importantly, they are about achieving agreement. ( Otherwise we could all just go off and write whatever code we want. ) This requires a common mind set, and a suitable level of understanding to form it. I am in favour of making it as easy as possible for common understanding to be reached. After all, the subjects are complex enough to understand, without being hampered by poor communication tools. Regards, Graham Travers Applications Standards Strategist * Tel: +44 1359 235086 * Mobile: 0780 8502536 *Fax: +44 1359 235087 * HW B279, P.O. Box 200, London, N18 1ZF * - Email: [EMAIL PROTECTED] -Original Message- From: John Stracke [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 5:06 PM To: [EMAIL PROTECTED] Subject: Re: HTML better for small PDAs [EMAIL PROTECTED] wrote: I have people working for me who write I-Ds, and who HATE the ASCII format that they are forced to use. So much so, that they have threatened never to write another I-D. Do we want to deprive the IETF community of the input of experienced technical people ( and, yes, they ARE ! ), because they are put off by archaic document formats ? Possibly, yes--because code is written in ASCII. A case could be made that someone who isn't comfortable with ASCII can't write code, and someone who can't write code should not be writing standards for how other people should write code. I'm aware that there are holes in this argument; but I think the same can be said of yours. For example, we don't know who these I-D authors you refer to are, so we don't know what I-Ds they've written, or whether their I-Ds have been of value to the IETF community. Unless they speak up for themselves, we don't know what kind of problems they've had, or how valid they are. -- /\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist |===| |eCal Corp. |All I ask is a chance to prove that money can't| |[EMAIL PROTECTED]|make me happy. | \/
Re: HTML better for small PDAs
[EMAIL PROTECTED] wrote: In my, limited, coding experience, I don't recall finding ASCII diagrams as part of the code. Poor diagrammatic capability is one of the problems I have with ASCII. Oh, ASCII art. I dunno; I've never used it. It's often not very useful; it's nice for packet formats, but a lot of the time I think it's done because people believe pictures are better, and ASCII art is the only pictures they can make. If you really can't do without it, check out http://www.sigsoftware.com/emaileffects/ (Mac and Windows) or pbmtoascii (Unix). You previous point about people choosing to use a "copy that's easier for some people to read" is interesting. Doesn't it imply that we should consider other formats ? Argh. My point was *exactly* the opposite: that, when there exist multiple formats, it is likely that some of them will be wrong; therefore, the only safe approach is to have exactly one format. plonk -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |Round up the usual disclaimers. | |[EMAIL PROTECTED]| | \==/
Re: HTML better for small PDAs
John Stracke wrote: [EMAIL PROTECTED] wrote: In my, limited, coding experience, I don't recall finding ASCII diagrams as part of the code. Poor diagrammatic capability is one of the problems I have with ASCII. Oh, ASCII art. I dunno; I've never used it. A clarification (since somebody called me on it): I've never used it in *Drafts*. As was pointed out, my .signature has it, sort of; but that's the most I've ever done...and I don't even do that any more; I wrote a formatter to do it for me. :-) -- /\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist |===| |eCal Corp. |A ship is safe in a harbor, but that's not what| |[EMAIL PROTECTED]|a ship is for. | \/
RE: HTML better for small PDAs
Interestingly, 8.5 x 11 comes about because of writing, not reading. Books are smaller than 8.5 x 11. Tablets are 8.5 x 11, and typewriters copied that. Laser printers copied typewriters. Stenographers used smaller tablets because they had to hold them in their hands rather than put them on a desk. Writing on a PDA is similar. Reading is another story. Turns out that line width is not all that important. No book has 72 characters per line, and no book has fixed pitch fonts. All of that is a technology crutch, and horrible for readability. People who claim 72 character fixed pitch lines is for readers are smokin something funny. It's left-over Hollerith card, with no basis in human value. Display technology has a really annoying reality - people always want more resolution, but they pay close to nothing for it. A great many companies have imploded because they believed people will pay a significant premium for a better display (I imploded one or two myself, including a 300 dpi CRT display in '85). Just isn't so. Display technology also is not subject to Moore's law - it's currently much, much slower, and about 90% of the innovations have not turned into commercial realities. Take every announcement of new display technology with a very large dose of skepticism. The biggest problem with PDAs today is contrast ratio, and that is fixable with more brightness, but has the problem of eating batteries. You will probably see high contrast ratio, probably color, PDAs commonplace soon. They will increase resolution maybe 5% per year on average, but don't hold your breath on much more than that. I can see displays that unfold once, like a book, but the idea that to read something you will unfold, and unfold, and unfold doesn't seem like it will get very far. If you want something to be readable, use a proportional font, don't worry too much about line width, and increase your contrast ratio. With respect to this discussion, it's not ASCII that's the problem, it's the font and the fixed line width. However, if we fix that, then a we Get to fix several less important issues without any additional complexity but We get all the problems of universiality, and archival storage The solution has been obvious, but it has a cost we haven't figured out how to pay. The solution is to separate the functions of "source", "display" and "archive". Source in XML, display in a variety of formats, including fixed width, fixed pitch ASCII. Archive both the XML source and the ASCII. The cost is that to be useful, we need tools to produce nroff markup from XML source, because no one is ready to accept RFCs that can't be displayed the way we display them now, and archive them the way we archive now. Marshall's excellent work is fine for I-Ds, but it isn't enough for RFCs. We need to produce pleasing ASCII, and the tool we use for that is nroff. The tool and the DTD has to allow the overworked, and under appreciated RFC editor staff to produce at least the same quality of ASCII output as they do now, with no more than the current level of effort. New tools mean training, and that is another part of the cost. We also have to create an XML archive from the current archive. Harald's suggestion of allowing ASCII and one other file to be archived for I-Ds is a very reasonable, and very useful step. He has a really good point; if we show that we will use another format, then we can move forward. As soon as someone puts up a pleasing HTML render for the XML source, that will be my preferred way to view I-Ds. The indexing, reference, and other side effects will also be welcome. Brian -Original Message- From: Bora Akyol [mailto:[EMAIL PROTECTED]] Sent: Monday, February 26, 2001 10:27 PM To: Lyndon Nerenberg Cc: Marshall T. Rose; [EMAIL PROTECTED] Subject: Re: HTML better for small PDAs I guess I have to hold up this "letter" sized paper display and try to write on it at the same time. I'll believe it when I see it. I saw the article on this topic in MIT Tech review a few months ago, but they were saying that this technology is years ahead. In the meantime, I will keep on using my Pilot (oops Palm). Bora On Mon, 26 Feb 2001, Lyndon Nerenberg wrote: the hardware problem is the eyes and the hands. i use a pda because i can put it in my hip pocket. that's just not going to happen with a screen that half-size or full-size. You're thinking too traditionally. Displays will decouple from the processor (think Bluetooth). The "CPU" will holster on your belt, and the A4 sized thin-film display will fold up to fit in your pocket. And pixel density will increase to approach that of paper. (At 300 DPI you can shrink the font enough to get the better part of a 60x72 character page onto even todays sized PDA displays if you dis
RE: HTML better for small PDAs
Vernon, I have people working for me who write I-Ds, and who HATE the ASCII format that they are forced to use. So much so, that they have threatened never to write another I-D. Do we want to deprive the IETF community of the input of experienced technical people ( and, yes, they ARE ! ), because they are put off by archaic document formats ? So it is not just "people who neither write RFC's nor implement protocols" who find ASCII "incomplete". Perhaps we ( the IETF ) should have a library of standard, downloadable translation / formatting tools that would help people to write in whatever format they choose, then convert it to the required ASCII. However, this would still not solve the problem os ASCII's poor diagram capability. Graham Travers. -Original Message- From: Vernon Schryver [SMTP:[EMAIL PROTECTED]] Sent: Monday, February 26, 2001 8:54 PM To: [EMAIL PROTECTED] Subject: Re: HTML better for small PDAs snip If the ASCII version of an RFC is complete, then the XML alternate is not needed. If the alternate is needed even only for "illustration", then the ASCII version is incomplete and so wrong. As others have said "incomplete" as seen by people who neither write RFC's nor implement protocols is completely irrelevant and inadmissible. As someone else pointed out, the crux of this recurring thread is the conflict between those who care about the form of RFC's including whether they use "modern technology" and those who care about the contents and function of RFC's as definitions of protocols. snip It seems clear that some of those who are adamant about replacing boring old ASCII are more readers than authors or editors. Worse, I suspect a few have not spent much time reading the ASCII stuff and would read little in any format, not matter how modern. snip Vernon Schryver[EMAIL PROTECTED]
RE: HTML better for small PDAs
Dear everyone, After reading every day about 20 emails about this subject, this is one of the wisest thing I have read (ether in a laptop or PDA). Perhaps we ( the IETF ) should have a library of standard, downloadable translation / formatting tools that would help people to write in whatever format they choose, then convert it to the required ASCII. However, this would still not solve the problem os ASCII's poor diagram capability. I am sure that will help, while the discussion on the standard format goes on, the tools will be helpfull to everyone whatever the final decision should be. Regards, Joaquin Rivera
An I-D experiment (Re: HTML better for small PDAs)
At 18:30 26/02/2001 -0800, Marshall T. Rose wrote: There is a use for XML or nroff versions of I-D's (but not RFC's) that has not been mentioned much (maybe first in your mention of "ASCII memos can't be reformatted"). It saves lots of work to exchange editorial changes as deltas to a mark up language version. i agree. this certainly is of value to the folks who author I-Ds. Perhaps in other words, allow XML in ftp.isi.edu:internet-drafts but not in ftp.isi.edu:in-notes i agree. i'm not asking that we publish RFCs in any new formats. i'm suggesting that we experiment for 9 months in the I-D area. A slight modification (I changed the subject line to concentrate on the constructive thread out of this): Let's say that we accept I-Ds in ASCII format. Let's also say that for each I-D, the secretariat will accept up to 1 file containing "source", where "source" can be NROFF macros, XML (Marshall's DTD) text or Word documents. To be stored in the "internet-drafts/source" subdirectory. (for completeness, there should also be a note saying how to produce the ASCII from the source; my Word stuff differs from the official Word stuff - but this makes the use/submission more complex) After 9 months, we can ask people to evaluate: - Whether they used "source" at all - What formats they found that were useful - What formats they found that caused trouble This thread should go somewhere else -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED]
Re: HTML better for small PDAs
In message [EMAIL PROTECTED], joaquin.riveraro [EMAIL PROTECTED] typed: Perhaps we ( the IETF ) should have a library of standard, downloadable translation / formatting tools that would help people to write in whatever format they choose, then convert it to the required ASCII. However, this would still not solve the problem os ASCII's poor diagram capability. I am sure that will help, while the discussion on the standard format goes on, the tools will be helpfull to everyone whatever the final decision should be. there is no substitute for good graphics design skills/ability - havign said that, some tools WOULD be nice - i think its irrelevant whether the tools render the output as GIFs or PDF or ascii - the problem some people appear to have is focusing. in practice ,there's 3 or 4 diagram types: 1/ packet headers- here the conventions used in rfc791 onwards are EXCELLENT since they are cpu agnostic- since they are also labelled they are no more national language specific than a program is:-) (e.g. C structure or Java ) 2/ state machines - these are not too bad - yo ucan use the same approach as is used in old 60s/70s flow charting/call graphing in general, quite clearlythe most complex state machine (e.g. new PIM SM spec, or TCP) are not too hard 3/ packet exchange examples (e.g. time sequence diagrams) - i think these are trivial (except occasionally in multicast:-) a tool for these would be pretty simple to build... (something could back end off of emacs, powerpoint animations, ns animations and magicpoint etc) 4/ topology based expostion (i.e. routing protocols) - these are generally very hard - ascii makes you think a LOT, as i said before about keeping the examples simple any other? so how about a project to develope some tools for the last trickier case above? (btw, i dont see how XML helps one bit - PDF or PS are the only options for platform independnt rendering, and even then there are problems with portability and fidelity) - and specifying the actual editing/wordprocessing toolset is not on! cheers jon p.s. how mayny people really read a protocol spec on a PDA? i mean the time i do it is when coding, and when coding i want the spec in a window, the code in a window, gdb in another window, tcpdump in 2 more - seriously.
Re: An I-D experiment (Re: HTML better for small PDAs)
From: Harald Alvestrand [EMAIL PROTECTED] ... After 9 months, we can ask people to evaluate: - Whether they used "source" at all - What formats they found that were useful - What formats they found that caused trouble ... No, do not *ASK* people what they used, but instead use the FTP logs and try to filter mirrors. That is because of the very steep slippery slope from allowing mark-up language versions ftp.isi.edu:internet-drafts down to the familiar morass exemplified by the .ps RFC's, and because many of the advocates for non-ASCII RFC's honestly think they use RFC's, but have and will never do more than look at title pages and author address lists. .. ] From: [EMAIL PROTECTED] ] I have people working for me who write I-Ds, and who HATE the ASCII ] format that they are forced to use. So much so, that they have threatened ] never to write another I-D. Do we want to deprive the IETF community of the ] input of experienced technical people ( and, yes, they ARE ! ), because they ] are put off by archaic document formats ? If they cannot speak for themselves but must have their handlers speak for them in IETF mailing lists, then yes, that it would be best if they and their employer find another way to Contribute To The Standards Process. (never mind the image of a sweat shop grinding out the useless chaf that dominates rfc-index.txt that the "I have people working for me" preamble brings to mind). ] So it is not just "people who neither write RFC's nor implement ] protocols" who find ASCII "incomplete". That some people HATE the ASCII format is not evidence about whether ASCII is incomplete. Those who have done it and understand their tools know that making diagrams of packets is easier with ASCII than many other tools. That is because the standard IETF ASCII packet diagram format is well suited to drawing tables of 16 or 32 columns with common groupings of 8 in individual rows. Those who are more familiar with Powerpoint and similar or who don't know how to reach fix-pitch fonts and to switch from insert to overstrike, do have problems diagraming packets in ASCII. In other words, the ASCII format is "complete." ] Perhaps we ( the IETF ) should have a library of standard, ] downloadable translation / formatting tools that would help people to write ] in whatever format they choose, then convert it to the required ASCII. This thread (not to mention others over the years) has had pointers to several such packages. If you're collecting tools, then it would also be handy to get one of the tools commonly used to generate the standard I-D headings. ] However, this would still not solve the problem os ASCII's poor diagram ] capability. The IETF is about protocols. About the only diagrams that you need are state diagrams and packet layouts. For those ASCII art is fine. Those who've spent much time actually using standards from know that while the diagrams outer venues (e.g. ANSI) are prettier but convey little or no additional information. Vernon Schryver[EMAIL PROTECTED]
Re: An I-D experiment (Re: HTML better for small PDAs)
"Harald" == Harald Alvestrand [EMAIL PROTECTED] writes:
Harald Let's also say that for each I-D, the secretariat will accept up to 1 file
Harald containing "source", where "source" can be NROFF macros, XML (Marshall's
Harald DTD) text or Word documents.
As long as every document in the "source" area has an ID, RFC or publically
available web page that explains the format of that document, I think that
this idea is great.
] Train travel features AC outlets with no take-off restrictions|gigabit is no[
] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[
] [EMAIL PROTECTED] www.solidum.com the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
RE: An I-D experiment (Re: HTML better for small PDAs)
-Original Message- From: Vernon Schryver [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, February 27, 2001 3:40 PM To: [EMAIL PROTECTED] Subject: Re: An I-D experiment (Re: HTML better for small PDAs) From: Harald Alvestrand [EMAIL PROTECTED] ... After 9 months, we can ask people to evaluate: - Whether they used "source" at all - What formats they found that were useful - What formats they found that caused trouble ... No, do not *ASK* people what they used, but instead use the FTP logs and try to filter mirrors. That is because of the very steep slippery slope from allowing mark-up language versions ftp.isi.edu:internet-drafts down to the familiar morass exemplified by the .ps RFC's, and because many of the advocates for non-ASCII RFC's honestly think they use RFC's, but have and will never do more than look at title pages and author address lists. .. ] From: [EMAIL PROTECTED] ] I have people working for me who write I-Ds, and who HATE the ASCII ] format that they are forced to use. So much so, that they have threatened ] never to write another I-D. Do we want to deprive the IETF community of the ] input of experienced technical people ( and, yes, they ARE ! ), because they ] are put off by archaic document formats ? If they cannot speak for themselves but must have their handlers speak for them in IETF mailing lists, then yes, that it would be best if they and their employer find another way to Contribute To The Standards Process. (never mind the image of a sweat shop grinding out the useless chaf that dominates rfc-index.txt that the "I have people working for me" preamble brings to mind). [ It is precisely because we do not operate a "sweat shop" that we do not expect everybody to engage on ALL the IETF lists. We have the quaint idea that the work should be shared out. Oddly enough, we have a company hierarchy, in which some people work for others. Apparently, this concept of organisation is outside your experience. Abuse is the refuge of the irrational. I note that you would prefer to reserve the right to "Contribute To The Standards Process" for yourself and other high-minded individuals. This is presumably the famed IETF " openness" in action. ] ] So it is not just "people who neither write RFC's nor implement ] protocols" who find ASCII "incomplete". That some people HATE the ASCII format is not evidence about whether ASCII is incomplete. Those who have done it and understand their tools know that making diagrams of packets is easier with ASCII than many other tools. That is because the standard IETF ASCII packet diagram format is well suited to drawing tables of 16 or 32 columns with common groupings of 8 in individual rows. Those who are more familiar with Powerpoint and similar or who don't know how to reach fix-pitch fonts and to switch from insert to overstrike, do have problems diagraming packets in ASCII. In other words, the ASCII format is "complete." ] Perhaps we ( the IETF ) should have a library of standard, ] downloadable translation / formatting tools that would help people to write ] in whatever format they choose, then convert it to the required ASCII. This thread (not to mention others over the years) has had pointers to several such packages. If you're collecting tools, then it would also be handy to get one of the tools commonly used to generate the standard I-D headings. ] However, this would still not solve the problem os ASCII's poor diagram ] capability. The IETF is about protocols. About the only diagrams that you need are state diagrams and packet layouts. For those ASCII art is fine. Those who've spent much time actually using standards from know that while the diagrams outer venues (e.g. ANSI) are prettier but convey little or no additional information. [ So, from now on all IETF illustrated presentations will consist solely of diagrams of packets, because any red-blooded protocol developer worth his salt is a wimp if he wants to draw anything else to help people understand what his I-D is saying. Oh, and, of course, if anyone dares to use anything but ASCII, then he can't be a protocol developer, can he ] Vernon Schryver[EMAIL PROTECTED]
Re: An I-D experiment (Re: HTML better for small PDAs)
"Vernon" == Vernon Schryver [EMAIL PROTECTED] writes: Vernon No, do not *ASK* people what they used, but instead use the FTP Vernon logs and try to filter mirrors. You have to filter out everyone's personal mirror, and then you don't know if I used the files or not... Vernon familiar morass exemplified by the .ps RFC's, and because many of Vernon the advocates for non-ASCII RFC's honestly think they use RFC's, Vernon but have and will never do more than look at title pages and Vernon author address lists. Who are these people? Headhunters? Managers? Product Marketing people? :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows fastertm Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
RE: HTML better for small PDAs
Vladis, You wrote: Actually, it *is* a valid argument - consider that hieroglyphs were unreadable until they found the Rosetta Stone. The media lasted, but the ability to parse didn't. ASCII has proven to be understandable 40 years after being written. XML has proven to be understandable 5 years after being written. Hieroglyphs have proven to be recognizable but not understandable 2000 years after being written (2000 years placing it just BEFORE the Rosetta Stone was found) -- ASCII is NOT understandable by people who can't read and/or speak languages which use the Latin alphabet. It is not understandable by them now, and it was not understandable 40 years ago. So, I agree with you about the ability to parse and understand. But ASCII doesn't support that ability for most people in the world. Hieroglyphs were perfectly understandable for the whole of their history - to an ancient Egyptian. Just like ASCII is perfectly understandable to someone who understands ASCII [ an ancient IETFer ? 8o) ]. Neither of these facts helps the population of today's world to the extent that they COULD be helped by more suitable formats. ANY storage format relies on its encoding being translated / interpreted before they can be understood. I suspect that none of us would be reading ASCII, if we did not have PCs to do this for us. What we should be pushing for is a format which can be translated / interpreted into as many languages as possible, so as not to disadvantage world citizens who can not deal with ASCII. Regards, Graham Travers * - Email: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 5:28 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: HTML better for small PDAs File: SMIME.txt
RE: HTML better for small PDAs
ASCII is NOT understandable by people who can't read and/or speak languages which use the Latin alphabet. It is not understandable by them now, and it was not understandable 40 years ago. Uh? This is an argument against the english language, not an argument againt the character set. If someone does not speak english, it matters very little whether the document is presented as 55x72 fixed typeset pages, Postscript, HTML, or XML. Indeed, we could also debate whether the documents should be made available in other languages than english, but the experience of organizations who do that , such as the UN, the EU, and to some degree the ITU, teaches us that quite a few lessons. First, this is a very expensive proposition; the IETF does not quite have the resource of maintaining a corps of interpreters. Second, translation is time consuming, and can be the cause of many publication delays, which can be used in standard-process games. Third, as translation is never a perfect bijection, there is a non-zero risk of conflicting interpretations of the various language texts, and thus lack of interoperability. This is not to say that we should make efforts to have the IETF protocols documented in many languages, for people to understand. But I would rather draw a sharp separation between the reference text, for which a single language and a spartan presentation are adequate, and the educational material, which ought to be available in many languages, forms and shapes. -- Christian Huitema
RE: HTML better for small PDAs
Christian, Yes, I have already conceded that we need a "master copy" ( reference text ). My remarks were intended to combat the "ASCII is all things to all people" attitude that seems to pervade these lists. It is not an argument against the English language, as ASCII can be used for other languages, e.g. French ( albeit imperfectly - no accents, etc.) However, ASCII can not be used for languages such as Arabic and Chinese; to say that it is easily understandable by everyone is facile and narrow-minded. Whether we want to do anything about it, is another question. Regards, Graham Travers * - Email: [EMAIL PROTECTED] -Original Message- From: Christian Huitema [SMTP:[EMAIL PROTECTED]] Sent: Monday, February 26, 2001 4:47 PM To: graham.travers; Valdis.Kletnieks Cc: doug; ietf Subject: RE: HTML better for small PDAs ASCII is NOT understandable by people who can't read and/or speak languages which use the Latin alphabet. It is not understandable by them now, and it was not understandable 40 years ago. Uh? This is an argument against the english language, not an argument againt the character set. If someone does not speak english, it matters very little whether the document is presented as 55x72 fixed typeset pages, Postscript, HTML, or XML. Indeed, we could also debate whether the documents should be made available in other languages than english, but the experience of organizations who do that , such as the UN, the EU, and to some degree the ITU, teaches us that quite a few lessons. First, this is a very expensive proposition; the IETF does not quite have the resource of maintaining a corps of interpreters. Second, translation is time consuming, and can be the cause of many publication delays, which can be used in standard-process games. Third, as translation is never a perfect bijection, there is a non-zero risk of conflicting interpretations of the various language texts, and thus lack of interoperability. This is not to say that we should make efforts to have the IETF protocols documented in many languages, for people to understand. But I would rather draw a sharp separation between the reference text, for which a single language and a spartan presentation are adequate, and the educational material, which ought to be available in many languages, forms and shapes. -- Christian Huitema
Re: HTML better for small PDAs
I would like to see the IETF continue to consider the ASCII text to be the master. I would additionally like to see the secretariat accept drafts in some TBD XML markup as well as a corresponding ASCII. The provided ASCII should match that which the secretariat produces, likely by providing the XML-ASCII formatter on a web site, and basing it open some open source implementation. Authors should provide the ASCII because they should have proofread that version as well. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows fastertm Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: HTML better for small PDAs
From: Michael Richardson [EMAIL PROTECTED] I would like to see the IETF continue to consider the ASCII text to be the master. I would additionally like to see the secretariat accept drafts in some TBD XML markup as well as a corresponding ASCII. The provided ASCII should match that which the secretariat produces, likely by providing the XML-ASCII formatter on a web site, and basing it open some open source implementation. Authors should provide the ASCII because they should have proofread that version as well. The dual Postscript and ASCII RFC's show that such a plan is likely to cause more harm than good. That dual track compromise sounded good at the time, but turned out poorly. There are other precedents showing dual languages don't work regardless of good intentions, from the DOD equivalents of the early RFC's to the ITU's labors with natural language translations. There is also the truth that every experienced programmer knows, that two definitions of one thing absolutely never agree. If the ASCII version of an RFC is complete, then the XML alternate is not needed. If the alternate is needed even only for "illustration", then the ASCII version is incomplete and so wrong. As others have said "incomplete" as seen by people who neither write RFC's nor implement protocols is completely irrelevant and inadmissible. As someone else pointed out, the crux of this recurring thread is the conflict between those who care about the form of RFC's including whether they use "modern technology" and those who care about the contents and function of RFC's as definitions of protocols. Absolutely all of us have ideas for improving of the form of RFC's, but it's a lot harder to say something useful about RFC contents. Thus, those who have not yet found an opportunity to Contribute To The Standards Process see opportunities in "implementing modern text preparation in the IETF" (with "implement" as in "implement TCP/IP in a corporate network"). It seems clear that some of those who are adamant about replacing boring old ASCII are more readers than authors or editors. Worse, I suspect a few have not spent much time reading the ASCII stuff and would read little in any format, not matter how modern. I've noticed the resounding silence of some who have made substantive contributions that might facilitate a transition to using XML for ID's. Why do is that? Could it be that they distinguish tools for writing (e.g. XML authoring tools) from the form and utility of an RFC? Vernon Schryver[EMAIL PROTECTED]
Re: HTML better for small PDAs
"Vernon" == Vernon Schryver [EMAIL PROTECTED] writes:
From: Michael Richardson [EMAIL PROTECTED]
I would like to see the IETF continue to consider the ASCII text to be
the master.
I would additionally like to see the secretariat accept drafts in some
TBD XML markup as well as a corresponding ASCII. The provided ASCII
should match that which the secretariat produces, likely by providing
the XML-ASCII formatter on a web site, and basing it open some open
source implementation.
Authors should provide the ASCII because they should have proofread
that version as well.
Vernon The dual Postscript and ASCII RFC's show that such a plan is
Vernon likely to cause more harm than good. That dual track compromise
I agree with your analysis. That is because postscript can do anything
ASCII can do. {Microsoft Word, latex, HTML and DocBook can do anything ASCII
can do}
I'm not certain that this would be the case for a sufficiently constrained
DTD. Something at the level of complexity of the MAN nroff macros in
formatting ability.
Vernon Absolutely all of us have ideas for improving of the form of
Vernon RFC's, but it's a lot harder to say something useful about RFC
Vernon contents. Thus, those who have not yet found an opportunity to
Vernon Contribute To The Standards Process see opportunities in
Vernon "implementing modern text preparation in the IETF" (with
Vernon "implement" as in "implement TCP/IP in a corporate network"). It
Vernon seems clear that some of those who are adamant about replacing
Vernon boring old ASCII are more readers than authors or editors.
Vernon Worse, I suspect a few have not spent much time reading the ASCII
Vernon stuff and would read little in any format, not matter how modern.
I tend to agree with your comments.
Vernon I've noticed the resounding silence of some who have made
Vernon substantive contributions that might facilitate a transition to
Vernon using XML for ID's. Why do is that? Could it be that they
Vernon distinguish tools for writing (e.g. XML authoring tools) from the
Vernon form and utility of an RFC?
I've done all my drafts in DocBook with an "sgml2rfc" translator that
was cooked up. I know others that have done the same. More recently, I've
been using an "rfc.el", but I may go back to sgml2rfc. Given that I already
have something in SGML, the info is already there.
:!mcr!:| Solidum Systems Corporation, http://www.solidum.com
Michael Richardson |For a better connected world,where data flows fastertm
Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: HTML better for small PDAs
vern - i hope we can agree that i don't fall under the categorization of those who have not yet found an opportunity to Contribute To The Standards Process if we disagree on this, then discard this message. i will tell you why i think it is a good idea that the I-D repository accept XML versions of drafts, whilst retaining the .txt versions as the "official" ones (assuming that the term "official internet-draft" isn't oxymoronic). the text format we use for I-Ds and RFCs is final form. it works great for printing. it works pretty well for viewing on a nice screen. it doesn't work well on a small screen. the advantage of using something like XML is that it is an intermediate form. this means that i can write programs that convert it to different final forms, e.g., something that looks nice on a pda. today i flew from sacramento to boston, rather than carrying around 500 pages of recent I-Ds, i loaded them onto my ipaq. although i avoided a trip to the chiropractor for my back, i now have to see him for the rsi i got from having to scroll left-right in addition to up-down. i don't know if html is better for small PDAs, and frankly, i don't care. what i do care about is the fact that ASCII memos can't be reformatted. that is just plain silly. so, i suggest a simple experiment: let the I-D repository store alternative versions of drafts in addition to the .txt versions. try this out for 9 months and see if people find it useful or not. is this really asking so much? /mtr
Re: HTML better for small PDAs
I would very much like to see support for XML+ASCII in IETF. Bora At 2:33 PM -0800 2/26/01, Marshall T. Rose wrote: vern - i hope we can agree that i don't fall under the categorization of those who have not yet found an opportunity to Contribute To The Standards Process if we disagree on this, then discard this message. i will tell you why i think it is a good idea that the I-D repository accept XML versions of drafts, whilst retaining the .txt versions as the "official" ones (assuming that the term "official internet-draft" isn't oxymoronic). the text format we use for I-Ds and RFCs is final form. it works great for printing. it works pretty well for viewing on a nice screen. it doesn't work well on a small screen. the advantage of using something like XML is that it is an intermediate form. this means that i can write programs that convert it to different final forms, e.g., something that looks nice on a pda. today i flew from sacramento to boston, rather than carrying around 500 pages of recent I-Ds, i loaded them onto my ipaq. although i avoided a trip to the chiropractor for my back, i now have to see him for the rsi i got from having to scroll left-right in addition to up-down. i don't know if html is better for small PDAs, and frankly, i don't care. what i do care about is the fact that ASCII memos can't be reformatted. that is just plain silly. so, i suggest a simple experiment: let the I-D repository store alternative versions of drafts in addition to the .txt versions. try this out for 9 months and see if people find it useful or not. is this really asking so much? /mtr
Re: HTML better for small PDAs
From: "Marshall T. Rose" [EMAIL PROTECTED] vern - i hope we can agree that i don't fall under the categorization of those who have not yet found an opportunity to Contribute To The Standards Process if we disagree on this, then discard this message. No, you're one of those others who've written tools that might support a transition to XML and whose silence I found relevant. i will tell you why i think it is a good idea that the I-D repository accept XML versions of drafts, whilst retaining the .txt versions as the "official" ones (assuming that the term "official internet-draft" isn't oxymoronic). ... so, i suggest a simple experiment: let the I-D repository store alternative versions of drafts in addition to the .txt versions. try this out for 9 months and see if people find it useful or not. is this really asking so much? Before the experiment of XML in parallel with .txt for RFC's, please consider this one. Let the .txt file continue to be the only version in the ftp.isi.edu/in-notes directory, but allow the .txt version to contain a "pointer to an XML version that was used during the preparation of the .txt version. " (weasel were words carefully chosen to allow the XML version to be anywhere and the pointer to go stale.) There is a use for XML or nroff versions of I-D's (but not RFC's) that has not been mentioned much (maybe first in your mention of "ASCII memos can't be reformatted"). It saves lots of work to exchange editorial changes as deltas to a mark up language version. Also, if the mark up version of some drafts had been public, a very bitter war or two in a working group or two would have been short circuited, or at least fought on the real grounds instead of stuff about theft of nroff under false pretenses. Perhaps in other words, allow XML in ftp.isi.edu:internet-drafts but not in ftp.isi.edu:in-notes The danger is the slippery slope leading to the full panoply of Microsoft document forms. Within weeks, there'd be demands that since XML is allowed for drafts, full MSWord with animations must be allowed--no--required for RFCs and who needs the crufty old ASCII? (This would not be Microsoft's fault, at least not directly.) Vernon Schryver[EMAIL PROTECTED]
Re: HTML better for small PDAs
From: Michael Richardson [EMAIL PROTECTED] ... I'm not certain that this would be the case for a sufficiently constrained DTD. Something at the level of complexity of the MAN nroff macros in formatting ability. MAN nroff would be overkill, as demonstrated by the restricted nroff that the RFC editor accepts (or used to accept) for I-D's. And apparently generated from pure ASCII submissions. Vernon Schryver[EMAIL PROTECTED]
Re: HTML better for small PDAs
There's more to this than just ID's/RFCs. Pretty damned near everything has to be reformatted to fit on those itty-bitty screens, and that just isn't going to happen. Consumers will demand (and get) readable displays. I really think we're better of fixing this problem in hardware. the hardware problem is the eyes and the hands. i use a pda because i can put it in my hip pocket. that's just not going to happen with a screen that half-size or full-size. yes, most things have to be retrofitted, but that's okay. i don't seem to have any problem with calendaring, contacts, todo lists, and so on. the 8.5x11 format has many fine properties to recommend it, but it also inadequate in some areas, and i don't think it's unreasonable that people want an alternative solution in that case. /mtr
Re: HTML better for small PDAs
At 3:57 PM -0700 2/26/01, Lyndon Nerenberg wrote: what i do care about is the fact that ASCII memos can't be reformatted. that is just plain silly. Marshall, do you think tiny PDA displays will be with us for a substantial amount of time? It seems to me that, with the rate display technology moves forward at, by the time we all finish arguing over this the current crop of postage-stamp size PDA displays will be ancient history. There's more to this than just ID's/RFCs. Pretty damned near everything has to be reformatted to fit on those itty-bitty screens, and that just isn't going to happen. Consumers will demand (and get) readable displays. I really think we're better of fixing this problem in hardware. --lyndon Are your pockets getting any bigger, I don't see anyone carrying a laptop holster on their belts? The reason that PDA screens are small are because PDAs are small. Apple Newton (which I still own) had a larger screen but it wasn't as convenient as a Palm to carry around. I have read reasonable size text docs on both and it is really not that bad. Bora
Re: HTML better for small PDAs
There is a use for XML or nroff versions of I-D's (but not RFC's) that has not been mentioned much (maybe first in your mention of "ASCII memos can't be reformatted"). It saves lots of work to exchange editorial changes as deltas to a mark up language version. i agree. this certainly is of value to the folks who author I-Ds. Perhaps in other words, allow XML in ftp.isi.edu:internet-drafts but not in ftp.isi.edu:in-notes i agree. i'm not asking that we publish RFCs in any new formats. i'm suggesting that we experiment for 9 months in the I-D area. /mtr
Re: HTML better for small PDAs
the hardware problem is the eyes and the hands. i use a pda because i can put it in my hip pocket. that's just not going to happen with a screen that half-size or full-size. You're thinking too traditionally. Displays will decouple from the processor (think Bluetooth). The "CPU" will holster on your belt, and the A4 sized thin-film display will fold up to fit in your pocket. And pixel density will increase to approach that of paper. (At 300 DPI you can shrink the font enough to get the better part of a 60x72 character page onto even todays sized PDA displays if you display in landscape.) Or maybe the technology will be something else. The point is that the display technology _will_ be there, and it will be there soon. (Soon enough that current PDA limitations aren't a good enough justification - IMO - for the sort of changes we're talking about making.) --lyndon
Re: HTML better for small PDAs
On Mon, Feb 26, 2001 at 06:30:56PM -0800, Marshall T. Rose wrote: i agree. i'm not asking that we publish RFCs in any new formats. i'm suggesting that we experiment for 9 months in the I-D area. One of the absolute best reasons to use the XML stuff (beyond the many other stated reasons) is the fact that Marshall has been graciously maintaining a bibliography on xml.resource.org that makes building your references section _much_ easier. If we do experiment with XML in the internet-drafts repository I really do think we should either migrate Marshall's bibliography or help him maintain it. The other thing that would be nice is a way of getting all of the authors current contact info in one place and up to date. -MM -- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Re: HTML better for small PDAs
I guess I have to hold up this "letter" sized paper display and try to write on it at the same time. I'll believe it when I see it. I saw the article on this topic in MIT Tech review a few months ago, but they were saying that this technology is years ahead. In the meantime, I will keep on using my Pilot (oops Palm). Bora On Mon, 26 Feb 2001, Lyndon Nerenberg wrote: the hardware problem is the eyes and the hands. i use a pda because i can put it in my hip pocket. that's just not going to happen with a screen that half-size or full-size. You're thinking too traditionally. Displays will decouple from the processor (think Bluetooth). The "CPU" will holster on your belt, and the A4 sized thin-film display will fold up to fit in your pocket. And pixel density will increase to approach that of paper. (At 300 DPI you can shrink the font enough to get the better part of a 60x72 character page onto even todays sized PDA displays if you display in landscape.) Or maybe the technology will be something else. The point is that the display technology _will_ be there, and it will be there soon. (Soon enough that current PDA limitations aren't a good enough justification - IMO - for the sort of changes we're talking about making.) --lyndon
RE: HTML better for small PDAs
-Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 3:37 AM To: Doug Sauder Cc: [EMAIL PROTECTED] Subject: Re: HTML better for small PDAs 1) Was your millenia-old data *written in XML*, or was it *converted to* XML within the past 5 years? This is not a valid argument. Egyptian Hieroglyphs were not written in ASCII either !
RE: HTML better for small PDAs
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Thu, 22 Feb 2001 21:01:23 EST, you said: I am not sure I agree with the statement that in 10 years XML will be history. One of XML's greatest values is in the fact that it is a good format for long-term archiving of written material. Some very old material (several millenia old) is available in XML format -- that's more than the 32 years for RFC1. ;-) The reason old text has been converted to XML is not so that people can read it on a GameBoy, but so that it can be archived, indexed, converted to other formats, etc. 1) Was your millenia-old data *written in XML*, or was it *converted to* XML within the past 5 years? Duh!? ;-) Obviously, this is a rhetorical question. 2) Will you be able to find the DTD you need in 2035? Well-formed XML documents still have value even without a DTD. It's usually pretty easy to guess at what the elements mean. If the documents are of value to a lot of people at the time, then yes, you probably will be able to find the DTD and one or more style sheets. If it's just a historical document, then maybe or maybe not. I'll bet that you'd be able to find a plain text rendering of the document, though. An alternative point of view is that in 10 years XML will have achieved a critical mass, so that it becomes as entrenched as many other standards: ASCII, TCP/IP, C, etc. OK.. Wake me up in 2011 and I'll be MORE than happy to reconsider. ;) I don't have a crystal ball, and I have been around long enough to have seen fads come and go. XML seems to me to strike the right balance between simplicity and value-add, so that I would consider it a pretty safe bet for the long-term as a document format. Anyway, I don't expect that the IETF will be moving from plain text to any other format for years, if ever. For the most part, this discussion is academic. Here's a proposal though: how about multipart/alternative! ;-) Seriously, storage is incredibly cheap. Why not store documents in several formats? If the plain text rendering is the normative document, I don't think anyone would have a problem with that. Perhaps the RFC editor could accept documents using the DTD from M Rose as well as the normative plain text format. I'm not suggesting that the editor take on a lot of new work, just that XML documents, when submitted by authors, be made available from the Web. BTW, I have always liked the layout of the RFCs -- namely, that they are nicely paginated with page numbers and headers. On the other hand, HTML often doesn't print very well. -- Doug Sauder
RE: HTML better for small PDAs
Just a few final observations, then I'll bug out of the discussion. 1. Some folks scoff at the idea of reading I-Ds and RFCs on a PDA, yet they think it's necessary to accommodate those who would read them on 1950s-style teletypes or other old, outdated equipment. We say that lines should be, what, 76 characters long? Why? What about 40 characters per line? Then I could read the RFCs on my old Commodore 64 in addition to my PDA. ;-) What *is* the lowest common denominator, anyway? 2. RFCs have a limited lifetime. RFC 1 might be 32 years old, but it's probably only relevant to historians. Historians will probably find the tools they need to view old documents. So, if RFCs are maintained in a format that outlives the technology documented in the RFCs, then there's no problem, right? (Speaking from the aspect of archives.) Anyone know how long ASCII will be around? -- Doug Sauder
Re: HTML better for small PDAs
On Fri, 23 Feb 2001 10:52:51 GMT, [EMAIL PROTECTED] said: 1) Was your millenia-old data *written in XML*, or was it *converted to* XML within the past 5 years? This is not a valid argument. Egyptian Hieroglyphs were not written in ASCII either ! Actually, it *is* a valid argument - consider that hieroglyphs were unreadable until they found the Rosetta Stone. The media lasted, but the ability to parse didn't. ASCII has proven to be understandable 40 years after being written. XML has proven to be understandable 5 years after being written. Hieroglyphs have proven to be recognizable but not understandable 2000 years after being written (2000 years placing it just BEFORE the Rosetta Stone was found) Now, who was saying that you didn't need a DTD to understand the XML? ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
RE: HTML better for small PDAs
The way I think about it, the current "ascii" rule makes it hard for the writer, moderately easy for the reader, and very easy for the archivist. It is hard for the writer now, because we are mostly using wysiwig tools that don't produce ascii very naturally. OTOH, it is not too hard -- for example, the extra cost of postprocessing a Microsoft Words formatted document to an internet-draft format is at most a couple of minutes, which seems a reasonable investment when you write for the posterity. As a matter of fact, it does not take longer than the nroff postprocessing that we used when nroff was the norm. Ascii text is moderately easy for the reader. Let's face it, the 72 character per line format has its roots in a time of 24x80 character screens, which itself had its root in the generic 80 columns punch card. That is fine when a screen is large enough to display a full line of text, but that is definitely suboptimal on small screens. A marked-up presentation would allow for better rendition on small PDA screens, and would also allow for a better support of those of us who have a poor eyesight. OTOH, the RFC format is very regular, with fixed size pages, regular indentation, etc. Many people have already written filters that convert this format into their preferred mark-up language, which is a reasonable compromise for viewers. We should note that the "ease of view" argument is an argument for mark-up languages, not for fancy page formatting languages such as Adobe's PDF: if you cannot reformat the page on display, there is no particular benefit for the owners of small screens or weak eyes. But the very benefits that make make marked-up presentation tempting also carry a big risk in a standard world: if the documents you view depend on how you view them, there is a risk that conficting view generate conficting interpretation. That risk is well known in international circles, when for example the translation of various UN resolutions can carry slightly different meanings in different languages. If we want standards, we want a simple reference. Printing an ascii text with a fixed font and a fixed page set-up gives us that. In my opinion, the hardship imposed on the authors and on the present readers is more than compensated by the ease of archival of the text format, the ease of read by future readers, and the adaptation to the job at hand, publishing standards. Mark-up languages have evolved in time, from nroff to tex and latex, from wordperfect to office XP, from sgml to html and xml. Markup languages tend to be highly parametrized, with various nroff or tex macros, various word templates, various html extensions and xml dtds. The macros tend to have an even shorter lifespan that the languages themselves, which make them even poorer candidates for an archival function. Frankly, the energy spent every fice years in questioning the ascii format would be better spent in writing transition tools... -- Christian Huitema
Re: HTML better for small PDAs
Actually, it *is* a valid argument - consider that hieroglyphs were unreadable until they found the Rosetta Stone. The media lasted, but the ability to parse didn't. If we're going to stray onto the treacherous ice of logic here, then I feel constrained to point out that ASCII, XML, and so on are merely ways of formatting characters, not languages in and of themselves. The clay tablet vs paper comparison really isn't applicable either, because the basic storage and display media do not change in our example, regardless of which format we adopt. A more precise analogy would be something along the lines of 'shall we use ink, paint, chisels, or chalk?' I'm afraid that even this construct isn't particularly useful in our context. There are times when analogies can shine a bright light on a dark debate, but they may also be the last refuge of the obfuscator. I say ASCII source documents are fine; if someone wants to convert their personal copies of the docs into XML, PDF, HTML, or Morse Code, they're perfectly welcome to do so. Cheers, RGF Robert G. Ferrell, CISSP Who goeth without humor goeth unarmed.
Re: HTML better for small PDAs
On Fri, 23 Feb 2001 13:22:15 EST, Jeremy Foshee said: Valdis wrote: Now, who was saying that you didn't need a DTD to understand the XML? ;) You don't. XML has the ability to stand on it's own if you desire. Umm.. without a DTD, how do you interpret all the markup that was the POINT of using XML? Yes, a XML document without the DTD can be syntax-checked, but let's think for a moment - if you don't have the (hypothetical) rfc2119 DTD, what is the *semantics* of: pointImplementors of Turbo-Foobar shouldsupport the XYZ extension/should /point Before you say "but we all know what 'should' means", consider that we felt it necessary to publish RFC2119. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: HTML better for small PDAs
On Thu, 22 Feb 2001 15:53:56 EST, Doug Sauder [EMAIL PROTECTED] said: I read the entire XML-SOAP document on my PDA, and that convinced me that reading documents on a small device is doable. I would be happy to put lots of RFCs and I-Ds on my PDA and have them available even when I don't have a laptop around. However, plain ASCII text, like the RFCs, looks pretty bad on a small device, because the paragraphs don't wrap in a pleasing way. HTML looks a lot better on a PDA than plain ASCII. Ironically enough, the previous paragraph arrived as one long string without a 'format=flowed'. As a result, it didn't wrap in a pleasing way. ;) Of course, the concept that we should redo all the RFCs into XML so they are more pleasing on a GameBoy-class display misses the point that rfc1.txt is still readable 32 years after being written, while both the XML and the display you're trying to support will probably be history within a decade. Trivia Question 1: What was the *first* popular word-processing program that used embedded codes, etc, in addition to flat ascii, on a PC/Apple/etc machine? Trivia Question 2: What year was it released? Trivia Question 3: If you were handed a file in that format, could you read it? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: HTML better for small PDAs
On Thu, 22 Feb 2001 21:01:23 EST, you said: I am not sure I agree with the statement that in 10 years XML will be history. One of XML's greatest values is in the fact that it is a good format for long-term archiving of written material. Some very old material (several millenia old) is available in XML format -- that's more than the 32 years for RFC1. ;-) The reason old text has been converted to XML is not so that people can read it on a GameBoy, but so that it can be archived, indexed, converted to other formats, etc. 1) Was your millenia-old data *written in XML*, or was it *converted to* XML within the past 5 years? 2) Will you be able to find the DTD you need in 2035? An alternative point of view is that in 10 years XML will have achieved a critical mass, so that it becomes as entrenched as many other standards: ASCII, TCP/IP, C, etc. OK.. Wake me up in 2011 and I'll be MORE than happy to reconsider. ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech
