> I'm not proposing a protocol change to finger.  My modification did
> not change the protocol at all.

I started to write "if it involves non-ASCII octets on the wire,
there's a protocol change", which matches some things I've seen others
say.  But then I went and checked.

It is not clear.  The RFC (1288 is the latest finger RFC I find) is
confused.  It says that "Any data transferred MUST be in ASCII format,
with no parity", but then it goes on to talk about "characters between
ASCII 128 and ASCII 255", apparently unaware that ASCII codes outside
the range 0-127 simply _do not exist_.  This throws the whole "must be
ASCII" statement into doubt, since the author was apparently unclear on
what ASCII was.

> My change was to make finger behave more like vi and less, where
> setting the locale will have the expected result of displaying
> characters that are valid in that locale.

Except finger gets octets, not characters, from the remote host; it has
no way of knowing what the intended mapping between octets and
characters is, except for the ASCII range, on which the spec is clear.

> I haven't noticed any interoperability issues with the Linux systems
> that have a finger client passing 8bit characters.

I would guess you've never tried fingering between systems that use
other than 8859-1, then. :-)

I would say that any attempt to use octets outside 0-127 on the wire is
ill-advised at best.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B