Subject: Re: finger
To: Jun-ichiro itojun Hagino <email@example.com>
From: Johan Danielsson <firstname.lastname@example.org>
Date: 09/10/2002 02:17:28
Jun-ichiro itojun Hagino <email@example.com> writes:
> so kimmo should go ahead and propose it to IETF.
Feel free to do that. But I don't think you really can extend that
protocol, as all inputs seem to be covered.
Actually I think that 1288 explicitly sanctions using LC_CTYPE to get
non-ascii data printed on the terminal. That they confuse ascii with
some generic eight bit character set can probably be ignored, it's a
common mistake and it's quite obvious what they meant.
2.2. Data format
Any data transferred MUST be in ASCII format, with no parity, and
with lines ending in CRLF (ASCII 13 followed by ASCII 10). This
excludes other character formats such as EBCDIC, etc. This also
means that any characters between ASCII 128 and ASCII 255 should
truly be international data, not 7-bit ASCII with the parity bit set.
3.3. Client security
It is expected that there will normally be some client program that
the user runs to query the initial RUIP. By default, this program
SHOULD filter any unprintable data, leaving only printable 7-bit
characters (ASCII 32 through ASCII 126), tabs (ASCII 9), and CRLFs.
This is to protect against people playing with terminal escape codes,
changing other peoples' X window names, or committing other dastardly
or confusing deeds. Two separate user options SHOULD be considered
to modify this behavior, so that users may choose to view
international or control characters:
- one to allow all characters less than ASCII 32
- another to allow all characters greater than ASCII 126
For environments that live and breathe international data, the system
administrator SHOULD be given a mechanism to enable the latter option
by default for all users on a particular system. This can be done
via a global environment variable or similar mechanism.