>>>>> On Thu, 12 Sep 2002 12:04:05 +0200 (CEST),
	Jaromir Dolecek <jdolecek@netbsd.org> said:

> 128-160 are control characters in iso-8859-*, so they are not safe
> to pass without character set protocol extension.

I know. (Didn't I say I know your intention? :-))

But as I said, Because of both the RFC and practical reason, we 
should have an option to support values 128-160.
So, original patch (which is now in our repository) is wrong.

>> Default should be defensive, shoudn't it?

> I'd be interested to know about 'smaller' cases. Surely there
> are 'larger' ones (like windows-1250, koi8, euc-*, etc), which
> have printable characters in 128-160 range, but I'm not aware
> of character set with control characters in range 161-255.
	:
> Yes. Default of passing 33-127, 161-255 (in both finger and fingerd)
> is as defensive, interop-friendly and convenient as we can get.

I guess that is not defensive enough.

Think about the following case:
	- Assume an implementation which supports multibyte codeset.
	- The implementation has some problems. For example, the
	  implementation don't check value range of the second byte
	  of multibyte characters.
	- Assume a server replies the following two Latin-1 characters.
	  (Note that this sequence is completely valid with Latin-1):
		character 161
		character 10 (i.e. newline)
	- The value 161 is a first byte of 2byte character sequence
	  with the above (problematic) multibyte codeset implementation.
	- The implementation should check that the second byte 10 is not
	  a valid code as a second byte, but the reality is that
	  the implementation doesn't check it. Thus, the
	  implementation crashes with the above Latin-1 sequence.

So, your SAFE default may be able to crash some client implementation.
i.e. Your assumption is not safe enough.

Just like 128-160 are not safe enough to pass without character set
protocol extension, 161-255 are also not safe enough to pass.

Do people now understand why itojun said the change is not right at
the first place? :-)
--
soda