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
<iljitsch(_at_)muada(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf