Jargons of Info Tech industry

[Steve]

Just passin' through....

Xah Lee, on Aug 22, 2:43 pm wrote:
Unix, RFC, and Line Truncation
[snippage]

There is no reason for a paragraph encoding to be splattered with end
of line characters, nor the human labor expended. There is reason for
paragraphs to be displayed not too wide, and that is readability. What
the unixer could not get clear of is a distinction of concepts. Because
their fantastically hacked-up operating system operate by the principle
that lines should not be some 80 chars or else it will be truncated and
*silently* too, thus it became _necessarily_ their _habit_ and thought
that line truncation business is natural and a human duty. Unknown of
these setups, the unix geeks go by their presumption that all text
should be hard wrapped, as if parameters should be hard-coded.

I've seen this argument before. There's at least one VERY good reason
to hard-code linebreaks in text: to preserve a covert channel. It's
really easy to structure plain text in such a way to include super
sekret messages that can only be properly decoded when the original
formatting of the text is preserved. Assuming that all of us are
agreed that plain text is the correct lowest-common denominator in
email and Usenet communications, it makes sense to allow for additional
personal expression by way of enabling users to encode additional
information in the formatting of their messages.

So, while Mr. Lee (who is not alone) is apparently of the opinion that
paragraphs should be formatted according to the transient size of the
newsreader window, his preference destroys a channel of expression
available to the putative author -- if free-flow paragraph structure is
mandated by the messaging standards and conventions of the text
messaging community.

Personally, I think the status quo is fine. People who wish to insert
line breaks where they wish in their paragraphs may do so, and others
may rely (or not) on their software to format their messages.

In the long term there are more pressing problems. Sould we, for
instance, extend the plain text 'conventions', which are largely
concerned with 7-bit ASCII messaging, and all the associated software
applications to work with unidcode character sets? Simplicity is good
and all that, but this is a multi-cultural, multi-language world.
Locking out the non-English speaking population from Usenet or (worse)
from manually interoperating with basic Internet protocols (for
instance) seems rather short sighted.

I do not mean to start a flame war here; I am just trying to point out
the obvious. People like Mr. Lee, as well as many, many application
deveolopers are well-meaning but misguided. They would unnecessarily
complexify things that should be simple and simplify things that should
be complex. I, for one, am continuing to think about these issues
because I see no simple solutions and have no magic bullet to offer
that would solve these perennial difficulties of prereference, clarity,
and common sense.

Perhaps one day we will converge on near optimal solutions to these and
like issues; which will be coded and formalised in standards, and which
will stand for the indefinate future.


Regards,

Steve

 

[Xah Lee]

Unix, RFC, and Line Truncation
http://xahlee.org/UnixResource_dir/writ/truncate_line.html

I've seen this argument before. There's at least one VERY good reason
to hard-code linebreaks in text: to preserve a covert channel. It's
really easy to structure plain text in such a way to include super
sekret messages that can only be properly decoded when the original
formatting of the text is preserved. Assuming that all of us are
agreed that plain text is the correct lowest-common denominator in
email and Usenet communications, it makes sense to allow for additional
personal expression by way of enabling users to encode additional
information in the formatting of their messages.

Rethink what you are saying. You'll see that what you propose as
reasons for one, is actually for the other.

Xah
(e-mail address removed)
∑ http://xahlee.org/

 

[David Schwartz]

Rethink what you are saying. You'll see that what you propose as
reasons for one, is actually for the other.

Nonsense. It is plain error to change what someone said and claim they
said it, even if you think that what you are changing isn't important.

DS