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. On 19 mrt 2010, at 2:04, Tim Bray wrote: > On Thu, Mar 18, 2010 at 12:24 PM, Iljitsch van Beijnum > <iljit...@muada.com> wrote: > >> So far the only thing I hear is assertions offered without any foundation >> that the current format is problematic > OK, one more time, let me enumerate the problems with the current > format. I agree that you may not perceive them as problems, but they > are problems for me: > 1. I cannot print them correctly on either Windows or Mac. > 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? > 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? > 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. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
