Re: Make HTML and PDF more prominent, was: Re: Why the normative form of

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(_at_)cridland(_dot_)net - 
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf