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