On 12.03.2010 19:43, Martin Rex wrote:
...
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).
Whether the converted document is long-term cached or converted on
the fly is an insignificant implementation detail. The point is,
Indeed. What's relevant is *that* it was converted to HTML.
that the original document is a plain ASCII text file. And the
existing standardization for I-D and RFC formatting enables a simple
tool to recognize references and anchors and create HTML tags from it.
*Most* references and anchors.
It would be better if we had a text based format that actually marks up
these things, so you don't need heuristics to get them back. Oh, wait...
> ...
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?
Because of the page breaks and the consistent presence of these
headers and footers just before and after the page breaks, an
accessibility tool should be able to recognize them as such.
I agree it would be nice if they did that. Do they?
...
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.
I'm so glad that NroffEdit will happily convert a plain ASCII RFC
or I-D into suitable authoring format. It would be horror if I
would want to suggest changes to a document and had to jump hoops to
get hold of the XML-type authoring format of a document first
and use tools like xml2rfc in order to create an updated version
of the document myself.
"Hoops" as in replacing ".txt" by ".xml" in the URL, and just download it?
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.
"willing to use nroff"?
You have likely never looked at NRoffEdit. It's an all-in-one
wysiwyg tool written in Java, that uses nroff-formatting commands
for authoring, Instant(!) preview and output is formatted ASCII,
spell checker is built-in. You do _NOT_ need any extra tools,
and in particular you do not need to figure out how to combine
a bunch of tools from various different sources somehow into a
productive workflow, as with xml2rfc.
When writing spec text, the *least* I'm interested in is the final
text/plain output by xml2rfc.
What I do is that I press F5 in the browser of my choice. That's my
workflow.
...
"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?
Section headings, page breaks, normative/informative references
to sections of other RFC documents, in-document references to
other sections.
When I wrote my first I-D, I tried to make sure that the conversion
tool on tools.ietf.org correctly recognizes and interprets all my
references. (I was actually surpized that it picked up most of
my references to sections of other documents before I even knew
that it was doing this).
Oh. I thought you meant *named* anchors.
...
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.
If something is difficult to accomplish, maybe it should not be
done in the first place. Personally, I think that the use of
I18N at the protocol level (I18N hostnames, I18N Email addresses,
I18N URIs) is a huge mistake and will result in lots of needless
pain when used.
...
Oh, so the IETF shouldn't care about I18N. Right.
...
A few years ago a support call was forwarded to me from a japanese
customer having problems with Single Sign-On configuration based
on the Windows domain authentication. So I asked the customer
about his current settings in the "Local Security Policy" (the
communication is translated through our support organization).
I got back a screen shot, but all the text that was shown was
completely incomprehensible (I can not read japanese) -- and
because of a different lexical order, counting from the top
didn't work either...
...
I know these kinds of problems (actually, from the same organization you
are in), but not liking the negative effects of localization doesn't
make it go away.
...
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?
The presence of form feeds in text/plain doesn't disturb any
of the text-only environments I use. it's still 1byte=1char character,
it doesn't<FONT FACE="Caibri, Verdana, Helvetica, Arial"><SPAN
STYLE="'font-size:12pt'>completely mess up</SPAN></FONT> the flow of text and neither
extends lines beyond 80 columns. Most HTML floating the internet
is an ecological disaster.
Again: please name a device in use today that *can* display the IETF
spec format properly, but can't display HTML.
...
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.
My NAS, my DLS-router and my Sattelite set-top box don't have lynx,
and neither of them came with a develomement environment.
So are you saying that readability on a *NAS* or a router is of
importance for a specification format? Why, for heaven's sake?
...
If there is any migration to new technology that the IETF should
promote, then it is neither non-ASCII I-Ds/RFCs, nor is it I18N,
but instead it is IPv6. HTML-based or PDF-based RFCs are not
going to make the transition IPv4->IPv6 easier or quicker,
so discussing how close to nil the benefit of new fancy
document formats is for some and just how bad it would be to
others is not a very productive use of IETF resources.
...
I think readable specs would make it easier for the IETF to promote
IPv6. Seriously.
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.
But it only works well for "online" documents. RFCs still work
Define "online" document.
well when printed out or visualized in a constrained text-only
environment.
Again: HTML, when done right, prints *much* better than plain text. And,
when done right, displays properly on text-only devices (using lynx).
Even for the document rfc3987, the use of human-comprehensible
references like "section 3.2" or "[RFC2237]" or
"(section 5.2 of [RFC3986])" work just fine for printouts
_and_ for rfcmarkup input.
Yes, in 99% percent of the cases.
When HTML was originally designed, URLs were designed to link/cross-reference
arbitrary publications stored at arbitrary locations. As we all know,
this never worked out. The useful lifetime of URLs are extremely
low, and cross-organization there is not useful maintenance
strategy to keep them in sync.
???
As a standardizations body, the IETF has a different set of requirements.
The IETF can standardize exactly how documents should reference each
other in a simple, plain-ASCII, human-comprehensible, printable
and in a form that is invariant over time from specific storage
organization on particular web-sites.
It can and it (sort-of) has, but it appears most people outside the IETF
consider the currently used format archaic. And some people inside the
IETF as well.
It's already bad to have the URLs in RFCs to external resources
expire, it would be horror if the references among RFCs within the
RFCs were hardwired by URLs and therefore hardwired to a very
specific storage organization.
Cool URIs do not change. So the problem is not allowing URIs, but
breaking them. There's no reason to break them. If the W3C can do it,
why can't we? Oh, I forgot, we can, and we do.
Anyway, what does this have to do with the documentation format?
And for those that want HTML, they can use http://tools.ietf.org/html
or do what it does themselves by postprocessing the existing
ASCII documents. And it'll work for a large number of the
existing ~5000 RFCs and much higher number of I-Ds--no need for
several different tools nor for re-authoring of those documents.
I don't think anybody proposed re-authoring documents.
I'm at the end of your mail, but you haven't told me how printing the
example document I pointed to worked for you. Did you try? If not, why not?
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf