Re: Why the normative form of IETF Standards is ASCII

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]