Re: latest drafts

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> I'd prefer to see [control character filtering] as a general
>> security consideration, since it applies anywhere where an
>> implementation may try to print a string received from the peer, and
>> that's lots of places.
> [Except for channel data]

Well, yes; I guess I don't think of normal channel data traffic as "a
string received from the peer", though of course there's no reason it
can't be thought of that way.  I agree that control-character filtering
applied to normal data traffic would be Weird and Wrong.  (At least
absent explicit configuration that way, and that's a configuration
option I see no need for an implementation to provide.)

What channel data - or string data, for that matter - is directed to on
the client side should not, I think, matter, but that's a quality of
implementation issue, not something I think the WG should specify.

> One might consider control character filtering on channels that (i)
> are directed to a terminal, and (ii) for which the client haven't
> requested a pty.  But I doubt it's a good idea.

Me too.  "ssh my-home-box cat term-stuff/$TERM/init-it" ought to do
what it looks as though it's doing, just like "ssh my-home-box"
followed once the prompt appears by "cat term-stuff/$TERM/init-it".

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