On 18.03.2010 21:25, Iljitsch van Beijnum wrote:
...
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.
I don't believe that the few escape codes (essentially two) are really a
problem.
And how are numbered lists a problem?
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?
No, you don't need a network connection.
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...
"We've done it for 40 years, why not continue that way"? :-)
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.
Aha! So how about:
1) asking the RFC Editor to always archive the XML when present (I
believe this is already the case), and to ensure the XML is actually
valid (to be done).
2) asking the RFC Editor to publish HTML *in addition* to the TXT
version, when available?
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.
I don't buy that. We've got something like 1 billion people on the
planet running web browsers, and I'm pretty confident we can find a few
non-ASCII characters everybody can display which could be used in examples.
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.)
That's an orthogonal problem. I agree it's non-trivial. MHTML would come
to mind, if it had more implementations.
I guess plain ASCII isn't so bad after all. Would be nice if we could get rid of the pagination, though.
As far as I can tell, all RFCs today are published from XML or NROFF
source. I know xml2rfc can produce unpaginated text, and I'm confident
NROFF can as well.
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf