Re: Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri Mar 19 10:29:04 2010, Iljitsch van Beijnum wrote:
On 19 mrt 2010, at 5:05, John Levine wrote:

> xml2rfc does a pretty good job of capturing what needs to be in an
> RFC, so that is the strawman I would start from.

The virtues (or lack thereof) of xml2rfc are a separate discussion. The question isn't how we generate the normative output, but what the normative output should be.


Why care about a normative output? You change the subject to talk about using non-normative representations already, why care about a normative output *at all*?

Let's concentrate on a normative format, and ideally making that format editable directly. For display purposes, I don't care if you want HTML, PDF, or RO-33.

> 2. I cannot view them at all on the mobile device

These two issues can easily be solved by using the PDF or HTML versions. Any paginated ASCII can be turned into a PDF easily and automatically. There are different HTMLizations of RFCs, some better some worse. Creating an HTML version is harder than a PDF version without an xml2rfc source but for most RFCs there is a decent HTML version available somewhere.

The PDF versions can be obtained from the RFC Editor if you search specifically for them, but in most places only the text versions show up. It would help a lot if the HTML and PDF versions were easier to find. Maybe the secretariat could put this on their todo list?


Or maybe do as the XSF does, with a normative XML format, but generating HTML and PDF from it. In the IETF, we'd even generate RO-33 format text, too.


> 3. I cannot enter the name of an author correctly if that name
> includes non-ASCII characters.

But even if you could, would you? I can't do anything useful with names written in anything other than latin characters (well, maybe also Greek). I wouldn't even know how to type them if I wanted to search for them. So at the very least all names would still have to appear in latin script and the non-latin form would be extra. Is the tiny benefit of having the "real" name there as a non-normative extra really enough to change what we've been doing for 40 years?


I don't think in itself it's a huge deal. I just think it's crushingly embarrassing.

The IAB made a clear statement that we need i18n support, yet over a decade after RFC 2130 or RFC 2825, the RFCs themselves still have a strict ASCII limitation. Sure, that wasn't mentioned at the time, but does nobody else find this plain shameful?


> 4. I cannot provide an actual illustrative working example of the use
> of non-ASCII text in Internet Protocols.

Correct interpretation of things like UTF-8 is highly dependent on context. On many systems a plain text file with non-7bit-ASCII characters won't be displayed as intended by default. So it would be necessary to go to HTML with &#; encodings of these characters or PDF to be reasonably sure they show up correctly. To me, PDF is unacceptable because it's even harder to display on devices other than computers with large screens or paper and it can't be decoded without complex tools. And switching to HTML just for this purpose isn't worth it to me. But then, I've never written a draft that required non-ASCII characters so that's easy for me to say.

So drop the non-ASCII characters from the text representation, just as we do already. I'm okay with that.

Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]