On 12.03.2010 16:58, Martin Rex wrote:
Julian Reschke wrote:
Actually, the page breaks _are_ useful. Like when referencing specific
parts/paragraph in a document with an URL in a long section, e.g.
http://tools.ietf.org/html/rfc5246#page-36
which contains the message flow of a full TLS handshake.
And that message flow is just perfect in ASCII arts.
That URL points to an HTML document, not a TXT document. There is
(unfortunately) no fragment identifier syntax for text/plain (at least
not one that UAs actually support)
Wrong. It points to a TXT document that is rendered as HTML.
No, it does not. It points to an HTML document that was converted from
the original TXT version (on the server, by Henrik's rfcmarkup script).
If you abide to certain conventions in your plain ASCII text,
then everyone can recognize and use them (RFC/ID -> HTML or -> PDF
converters, accessibility tools like text->speech). And it still
renders just fine on pure text environments and over very low
bandwidth links.
So what do accessibility tools do when they encounter page breaks, with
the header & footer lines? What does a screen reader to with ASCII art?
I-Ds and RFCs are not "publish and forget" documents, but instead
they're vivid snapshots of working group discussions in constant
motion and under discussion, and one of the most important aspects
is that others can easily build a derivative work from an existing
document (especially for expired I-Ds).
Yes. That's an argument to require an easy to re-use *submission*
format. But the submission format doesn't need to be identical to the
publication format.
The submission tool already allows you to supply additional source
files, such as XML. I recommend to use that.
So it is extremely important that the published format is easy to
quote in ASCII-Emails, can be easily quoted in ASCII code comments,
and easily incorporated into new documents.
Yes.
Just try NRoffEdits conversion I-D -> authoring nroff source and
see how easy that is. It's a single all-in-one tool written in Java,
basically wysiwyg with spell checker included and makes I-D editing
extremely easy.
It's probably a nice tool for people willing to use NROFF. There are
other nice tools, based on the RFC2629 XML format.
And guess what: if we go directly to HTML, we'd have anchors as well,
but not only for section numbers, but also figures, tables, or even
individual paragraphs.
"Anchors" in plain-ASCII text that are human-comprehensible can
be automatically converted into real URLs and anchors with simple
tools. These tools exist and work just fine with the existing
plain-ascii text documents.
Example?
...
If you want people to communicate, they need to share a common
language. If they don't happen to already know one common language
(in which case the difficulty/complexity of that language doesn't matter),
then they should probably standardize on a language that is easy
to learn for both of them and has a high likelyhood to be useful
for communication with other people as well.
And it makes perfect sense to not only standardize on that single
language in spoken communication, but also in written communication.
Anyone who enters IETF discussions, which are Email-based for a large
part, should provide a description of his own name with letters
from the US-ASCII alphabet, rather than forcing others to make
guesses how to do it given some kind of gibberish codepoints from
awkward codepages.
...
I don't have any problem with that. But requiring an ASCII transcription
doesn't imply that the real name can't be used in *addition*. (We had a
discussion about this a few years ago, and that's exactly what was
proposed).
However, contact information is just one use case.
Another one are examples for I18N in specs which are incredibly hard to
write unless you can actually use a few example characters. See RFC
3987, for example.
Some people think internationalized domain names are a good idea.
I think they are a pretty stupid idea, because they're a significant
> ..
That's a completely orthogonal discussion.
Using HTML or PDF for RFCs is about the same as moving from
English language RFCs to mandarin language RFCs. There is
a huge number of people who can read it, but there is a
also a large number of current RFC and I-D consumers and
producers which can not and does not want to use mandarin.
Sorry? Are you implying anybody is unable to display HTML?
Yes, of course. The majority of devices and a huge number of
environments is completely unable to display HTML.
And those *can* display text/plain with form feeds in a sane manner?
Example?
...
I do not doubt that there are tools available for heavy graphical
user interfaces and specific platforms that can deal with mandarin
just fine. But I do not understand mandarin, my tools can not cope
with it and a lot of my platforms and my environments can not cope
with it. HTML and pdf are only marginally better than mandarin.
Sorry? With all due respect, but this statement is really ridiculous; at
least in the context of HTML.
Btw. printing out I-Ds and RFCs on paper (even 2-up and double sided)
has always been working just fine for me with tools like a2ps.
Sounds great if you have a Postscript printer.
I'm pretty sure there are similar ascii to pdf converters by now.
I would not be surprised if there even was a web service that will
convert an I-D into PDF in case that you can neither print formatted
ASCII text on your printer nor Postscript. And if not, creating
such a tool is probably trivial, much much simpler than a tool
to make a fancy document format like HTML or PDF viewable on
a pure textual display.
...
I have a hard time remembering when I saw a "pure textual" display the
last time. But anyway, even these devices can display HTML using lynx.
Printing PDF works, but reading PDF on screen is a royal PITA.
Yes.
Even with a 1600x1200 screen, displaying a single page is
The concept of a "page" is part of the problem - for the current format
as well. "Pages" are good when the primary output format is paper, and
the paper size is known in advance. Today, that's the edge case.
The paper sizes Legal, Letter, A4 etc. have been around for many years,
and they will be around in 30 years. I'm not so sure about any current
incarnation of PDF or HTML.
I'm pretty sure for certain subsets of PDF and HTML. YMMV.
difficult to achieve -- and hardly legible with many PDFs that
I've come accross--and if you choose a legible size, then the page
doesn't fit and you have to page down to see the bottom of the page.
Getting 62 lines of pure ascii text with a legible font displayed
on a 1024x768 screen is much easier and much more legible.
And doing a 2-up of an RFC or I-D has a predictable legibility.
...
How is that different for (a properly selected subset of) HTML?
Printing HTML is still a research topic. It just doesn't work.
The common "Tool" to display HTML is called web browser, and
the only influence, if any, that you have on what comes out off
the printer is the "paper size" and potentially "margins".
It would be nice if you could elaborate on what the problem is. Try, for
instance, printing <http://greenbytes.de/tech/webdav/rfc2616.html>.
But more often than not, the screen-oriented formatting in HTML
resuls in the printouts being truncated at the right border
or filled with white spaces. And removing parts of the page
(like a navigation box that becomes useless when printed
before printing it is a feature not currently supported.
The people who are in favor of HTML aren't proposing to use any "screen
oriented formatting", at least as far as I know. They want to use HTML
for the features it was originally designed for, as markup language for
technical documents.
HTML is definitely a nightmare when it comes to printing.
Printing *any* HTML, yes. Printing well-designed HTML, no.
...
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf