Re: Practical forwarding problem

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

>>    X11 connection forwarding should stop when the session channel is
>>    closed.  However, already opened forwardings should not be
>>    automatically closed when the session channel is closed.

>> To me, that quite clearly says that I *should* shut down the
>> forwarding when the session channel closes.

> I don't read that.  What I read is that new X11 requests should no
> longer be accepted, but that existing (_already opened_) forwardings
> should live on.

I suspect we may be in furious agreement here, just using different
words to describe it.  In particular, a "forwarding" may be different
things to you and to me.

By "new X11 requests" do you mean "x11-req" CHANNEL_REQUESTs, do you
mean new X connections on the server host (and the "x11" CHANNEL_OPENs
that result from them), or what?

By "existing...forwardings" do you mean existing channels opened with
type "x11", do you mean the listen for new X connections that's set up
on the server, or what?

My reading is that the "X11 connection forwarding should stop" means
that the server side should stop listening for new X connections and
"already opened forwardings should not be automatically closed" is
referring to existing X connections, and their associated "x11"
channels.

And when I equate that to "shut down the forwarding when the session
channel closes", I'm talking about the server stopping listening for
new X connections.

>>> Even if I'm off track here, I suggest sending a note to the openssh
>>> list.  It sounds off topic for this list.
>> Really?  OpenSSH is not involved in any way in the cases in which I
>> ran into this.
> No, but they deal with this case.  My suggestion was just that you
> discuss it with an implementor that has addressed it.

Ah, I think I see what you mean.  Not so much "take it to openssh" as
"take it to a implementation list rather than protocol design list"?
Perhaps a parallel list for implementation issues would be appropriate.

> But now that I have a clearer idea of what you're asking, maybe this
> list is more appropriate.

Well, perhaps.  It *is* an implementation issue, not something that has
anything to do with the protocol per se - but the spec is intended to
guide implementations, and if the spec ends up compelling something
that cripples implementations, it needs fixing.  (In this case, I now
think it's not that bad, but it looked at first as though it might be.)

/~\ 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