Tim Bray wrote: > > On Fri, Mar 12, 2010 at 10:43 AM, Martin Rex <mrex@xxxxxxx> wrote: > > Martin describes a planet on which nroff formatting semantics are > considered to have current relevance, in which it's hard to look at 4 > or 5 HTML documents simultaneously, in which people don't care which > characters are used to write their names, in which worrying about i18n > in protocols is a bad idea, in which people worry about viewing RFCs > on DSL routers but not mobile phones, in which printing HTML "just > doesn't work", in which it takes "fancy gadgets with lots of CPU > horsepower" to render HTML... The IETF is not in the publishing business, and if you want to get a scientific paper with pretty diagrams, math formulas, photos in languages other than english and filled with fancy characters from all over unicode, then you probably should go to either one of the commercial publishers (a big one or a small one like books-on-demand), but not to the IETF Editor. Reflowing ASCII-formatted RFCs/I-Ds is really not very difficult, if that is what some people need desperately for their SmartPhones. Considering that NRoffEdit is fairly good at reflowing ASCII-formatted I-Ds back into authoring .nroff source (which is still significantly more readable and comprehensible than any XML and HTML btw.), then providing such a tool for those gadget is probably two magnitudes less work than implementing an HTML rendering engine. Making such a tool accessible online at tools.ietf.org should not be that difficult. It would even be possible to build magic into the tools.ietf.org URL so that the format is chosen based on the User-Agent present in the HTTP request header. It is definitely completely unnecessary to change the authoring, submission and archiving format of RFCs/I-Ds to accomplish this. The ultimate disaster of I18N/L10N is what Microsoft did with Office97 when they localized the VBA keywords (one of the reasons why some companies stopped using localized MS Office versions back then). When I started using and programming computers, none of them had localization (everything in english). But when learning terminology for formerly unknown stuff then one gets accustomed to the new terminology being drawn from a different language rather than mocked up from ones own if there is at least some familarity with that foreign language. Trouble started when I was first faced with "localized" versions of operating systems and application (from Microsoft and IBM), because it was almost incomprehensible to me. It felt strange to read words in a documentation that sound like they're from your own language but don't make any sense to you such as "serielles Zeigeinstrument" (IBM). If air treffic controllers would start using only local/national terminology when talking to pilots, then the number of accidents would increase significantly. I see it as a benefit not having to learn the local language of a country before being able to go there and use a phone, drive a car, go shopping, use some multimedia equipemnt or even a computer. It's less of a problem if you can easily switch the technology between localizations while using it--which, fortunately, is becoming more an more common. The important part is, that internally, the technology should use a single common format, the localization should only affect the output, not the processing. The are OSes that use UTC internally and localtime() in a sane fashion, and unfortunately there is one, that doesn't -- causing lots of interop pain, with others and with other incarnations of itself and even with itself. > > I congratulate SAP for their bold vision in extending their operations > beyond the bounds of planet Earth. In the IETF people participate as indiviuals, unless explicitly state otherwise, and despite many of the participants having corporate sponsors paying for some or all of the expenses and contributions. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf