Re: Why the normative form of IETF Standards is ASCII

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(_at_)cridland(_dot_)net - 
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf