On 18 mrt 2010, at 20:59, Julian Reschke wrote: >> The XML in itself can't be interpreted by a human to the level needed to create a compliant implementation, although it deceptively looks like maybe it could. Of course human readability also doesn't exist for pretty much anything other than text or the simplest of HTML, in itself this isn't a show stopper. > That is simply incorrect, which can easily be checked by looking at the XML source of a spec. People make mistakes implementing today's text. If they have to implement from XML source where they have to interpret things like escape codes and numbered lists (just to mention the first two things that come to mind) in their head this is going to be much worse. >> There is at least one other implementation that can be used by everybody who's got a current browser So now I have to have a working network connection to read an RFC? What if the site that hosts all this goes down? What if someone wants to read a spec 20 years from now? >> it would be impossible to have all RFCs be available in one format if XML is adopted for future RFCs. > Yes. How is that a problem, exactly? Because this doubles the amount of effort needed to be able to read RFCs. And if old RFCs can be in text, why not new ones? And if some RFCs are text, why not derive text versions of the XML ones too, so there are text versions of all of them? And if there are text versions for all RFCs and XML versions of only some, why not make the text version authoritative? Oh wait... >> That's a pretty good result for files which date back as long as 40 years. Good luck finding any other document format of the same age with that property. > That may be true, but that features comes with drawbacks. Drawbacks that we can all agree on? Sure, RFCs don't look too pretty, and their hard line and page endings are very annoying because they never fit the screen or paper that you happen to use. (Aside: PDF is much worse in this regard.) But pretty much all RFCs can be viewed in HTML versions which don't have these problems by anyone who cares. Being able to have names and examples in non-latin characters would be nice, but for names this is just a cosmetic thing with compatibility issues that make it not worth the trouble, and with examples it's dangerous to depend on correct display of anything that isn't 7-bit ASCII because it's still quite easy to end up with something that's incorrect or doesn't show. The ability to use graphics would be helpful but would have severe consequences for the file format, having to use multiple files to make up a single RFC would be problematic (ASCII, HTML with images) and single file formats aren't trivially decoded. Images are also very hard to edit, making collaboration and especially updating RFCs much more difficult. And the inclusion of images reduces the number of devices that can display an RFC significantly. (Line printers, text only displays and remote login sessions are out, hand held devices also to a large degree because the screens probably don't have enough resolution.) I guess plain ASCII isn't so bad after all. Would be nice if we could get rid of the pagination, though. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf