[rfc-i] Scanning non-ASCII text
hallam at gmail.com
Fri Sep 28 06:26:48 PDT 2012
What I very much would like to see however is the electronic signatures be
embedded in the document.
At the moment the RFCs are signed and this helps with various court demands
for production (note that I say helps not solves).
But the index of signatures is not nearly so widely distributed as the
On Fri, Sep 28, 2012 at 9:21 AM, Andrew G. Malis <agmalis at gmail.com> wrote:
> +1. Even if we somehow lost the IETF's redundant data stores (both
> datatracker and tools), AND the RFC Editor's redundant data stores,
> AND all of their backups, RFCs are among the most replicated
> electronic documents there are.
> On Wed, Sep 26, 2012 at 1:23 PM, Phillip Hallam-Baker <hallam at gmail.com>
> > I cannot see any relevance or utility in the ability to round trip
> > physical document formats.
> > If we have ever lost the electronic format of documents published from
> > on then we deserve to suffer.
> > This problem is a concern but a very very minor one. I would place it
> > somewhat lower than the impact of an alien invasion on the RFC series and
> > rather higher than dealing with a zombie invasion.
> > The US CDC has a plan for dealing with zombie invasions, I do not think
> > IETF needs to plan for that eventuality,
> > On Wed, Sep 26, 2012 at 12:51 PM, Martin Rex <mrex at sap.com> wrote:
> >> Paul Hoffman wrote:
> >> >
> >> > Greetings again. The -00 draft gives as an argument for keeping
> >> > the all-ASCII requirement:
> >> >
> >> > * In extreme cases of having to retype/scan hard copies of
> >> > documents (it has been required in the past) ASCII is
> >> > significantly easier to work with for rescanning and
> >> > all of the original information. There can be no loss of
> >> > descriptive metadata such as keywords or content tags.
> >> >
> >> While the wording if this paragraph is debatable the content is
> >> acutually quite valid and quite important.
> >> >
> >> > This doesn't hold up for two reasons. First, scanning software has
> >> > handled non-ASCII characters just fine for well over a decade.
> >> The scanning software ("human comprehension") that is involved in
> >> most real-world consumption of I-Ds and RFCs by humans in a an optical
> >> character recognition (OCR) process called "reading" has historically
> >> been coping poorly with glyphs from other languages, is still coping
> >> poorly with this today, and there is currently no indication that
> >> this is going to change in the future. Numerous glyphs from Unicode
> >> are completely indistinguishable when visually rendered on display
> >> devices for processing by the "human eye" OCR system.
> >> >
> >> > Second, and more important: no RFC created in the future will
> >> > exist only in a printed version.
> >> You're mounting the horse from the wrong end.
> >> Changes that are completely unnecessary, but will make printed copies
> >> hard to comprehend, are to be avoided. There better be a very good
> >> reason to break an installed base.
> >> You also have to keep in mind, that there are certain popular tiny
> >> display (i)Devices, where the manufacturer makes it arbitrarily
> >> difficult to share information on them with your PC, and also
> >> arbitrarily difficult for end users to work around these shortcomings
> >> with own software, and there is currently no indication that this
> >> manufacturer is going to change his hostile attitude towards the
> >> end users who buy these devices.
> >> -Martin
> >> _______________________________________________
> >> rfc-interest mailing list
> >> rfc-interest at rfc-editor.org
> >> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> > --
> > Website: http://hallambaker.com/
> > _______________________________________________
> > rfc-interest mailing list
> > rfc-interest at rfc-editor.org
> > https://www.rfc-editor.org/mailman/listinfo/rfc-interest
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rfc-interest