On Thu Mar 11 16:54:21 2010, Martin Rex wrote:
Richard Shockey wrote:
>
> I do get the arguments in favour of ASCII, though I think there
are
> some pretty serious countervailing arguments (like, for instance,
that
> we can't spell many contributors' names, to take an easy one).
But
> the RFC format _is not_ plain ASCII. Just ask anyone whose draft
has
> failed the increasingly stringent and lengthy list of IDNits
tests due
> to bad pagination in their I-D.
The difficulty to spell contributors' names is a completely
ridiculous
reason. If there is anyone competent to specify how to spell his
name
in plain ASCII, then it is the authors and contributors themselves
-- and if they are available at all, then it is during the process
of their contribution and the document creation.
Right, so how would one spell, for example, Tronçon in ASCII? Leaving
off the diacritical leaves the suffix "con", which is somewhat less
than polite French. I accept that in some cases, there are generally
recognised ASCIIfications of names, but that's not universal, and
certainly not always acceptable to those people "suffering" from
non-ASCII names.
Really, the year is 2010, and I see absolutely no excuse for the
IETF's inability to support writing author's names properly - this is
plain embarassing.
The existing plaintext ASCII format is easy and univerval. Any more
fancy document formats come with plenty of problems and
infinitesimal
close to zero benefit.
I would argue that the ubiquity of HTML and the comparitive rarity of
text/plain viewers of similar capability actually reverses this
argument at this point in time. I certainly now view the RFCs and
I-Ds *solely* through a translation layer to HTML, strongly suspect
this is the case for the vast majority of people working with RFCs
and I-Ds, and I'd find it very significantly more useful if there
were ways for authors to provide more metadata.
Certainly in the XSF, use of an XML format for the XEPs, complete
with anchors for Examples, Sections, etc in the HTML form, and
metadata sufficient to syntax-highlight in the PDF form, has been a
tangiable benefit on many occasions, speaking personally.
Creating, displaying and printing, processing and updating the I-D
and RFCs
in the current form was possible 30 years ago, is possible and
quite easy
today (just try NRoffEdit once), and will be possible and easy in
30 years from now. All other formats will come with a varying
number
of problems.
Taking an existing formatted ASCII RFC or I-D (which you did not
author
yourself) and putting it back into authoring format is round 1 hour
of
work with Nroffedit.
Having taken quite large, NROFF edited documents and transformed them
into RFC 2629 format, for further editing, I'd comfortably argue that
this can be independent of the authoring format, and moreover, this
is a moot point if the authoring format is the archival format.
This is the case at the XSF, where the http://xmpp.org/extensions/
page points to rendered versions of the archival format. (In two
presentation formats, incidentally).
Diffing various revisions of documents is fairly easy with existing
tools
e.g. http://tools.ietf.org/rfcdiff
Only because those tools are written. Diffing tools have been written
for the much smaller community in the XSF, so again, I dispute your
implicit assertion that this is made possible by the formatting
choice.
The problem with basically all of the fancy format is, that none of
your existing tools can cope with it, the possibility to create that
format is often limited to specific platforms, environments or
tools.
Diffing with previoius versions of documents is difficult,
converting
a "published" document back into authoring format is EXTREMELY
diffcult,
the size of the document often grows by factors, and searching and
displaying such documents may require specific new tools and
platforms
and be therefore impossible for a number of platforms and
environments
where RFCs and I-Ds are currently displayed, searched and processed.
I have no objection whatsoever to maintaining the text format as one
presentation format.
I do think it's time to look at lessons learnt from xml2rfc and the
XSF's XML format, and consider developing a new specification format
from both that then provides a solid base for a new archival format,
which can be used to consistently generate presentation formats that
take full advantage of existing and widely deployed technology.
Both these formats have existed now for a decade or so, and that's
surely long enough that we have some clear ideas about how to proceed.
And searching for and comparing characteristics of graphics or
graphical drawings instead of text is a field that needs another
two decades of reasearch.
I firmly agree that we should prohibit the use of graphical diagrams
at this stage. (It may be that in the future, SVG may provide the
answer, but it's too early to say as yet).
That's no excuse to cling to a 1970's format that prevents us from
drawing a vast amount of benefit from the technology of the past 30
or so years - this is not about jumping on the bandwagon of every
passing fad, but using the technology we profess to have some
expertise in.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
