ietf
[Top] [All Lists]

Re: Why the normative form of IETF Standards is ASCII

2010-03-18 15:38:37
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>