Re: X forwarding

[nisse%lysator.liu.se@localhost (Niels Möller)]

der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> writes:

> While it seems silly from an efficiency point of view, I'm now inclined
> to remove that from the CHANNEL_OPEN entirely and put it in the channel
> data stream, probably with zero-length authorization data (that is, the
> ssh protocol as it appears on the wire then knows nothing about the X11
> protocol - only the manipulation of the data stream at each end has any
> knowledge of X).

That is cleaner, at least from a narrow ssh protocol viewpoint. I
think it was something similar I was suggesting the last time X11
forwarding was discussed.

> The R4 protocol document says
> 
>      #x42      MSB first
>      #x6C      LSB first
> 
> Those are ASCII 'B' and 'l'; while this is not coincidence, 'b' and 'L'
> are invalid X protocol, same as 'q' and '&'.

Thanks for the correction. RFC 1013 (UNKNOWN status) agrees with you.
I missed that detail when I read it a long time ago.

[ about representation of connection information ]

> But there's no standard way - as far as I know - to combine a DECnet
> node name and demultiplexing string (I don't know the canonical DECnet
> terminology for them) into a single string.

I don't quite buy this argument.

There ought to be some character that could work as a separator?
Something (to allow the format to be extended to other non-ip
addressing schemes as well) like "decnet!address!demultiplexor". Or if
all else fails, use explicit embedded length
fields,"decnet!7:address13:demultiplexor". Both formats should work as
extensions of the current ssh conventions for representing addresses.
I'd be a little surprised if there's no "standard" way to represent
decnet endpoint addresses as strings, but I don't know decnet at all.

It's preferable to use a standard format, like an text string (in
ascii or utf8)) + an optional port number. This makes it easy for an
implementation to display and/or log the connection information for
any connection type, including types the implementation doesn't
understand.

> > Finally, one alternative to using a special token to identify
> > displays is to just add the id of the associated session to the "x11"
> > CHANNEL_OPEN message,
> 
> Yes.  I considered that, briefly.  The principal reason I didn't do it
> was practical: the way my implementation is layered, that's somewhat
> inconvenient information to get at.

Both ways seem ok to me. (And I think both should be as easy to
implement: using the session channel id to identify a forwarded
display is equivalent to using a separate token, and a token creation
function that by chance happens to always generate a token that equals
the channel id of the associated session channel). Using a separate
token gives the client (which chooses the values) a little more
freedom.

> >   A session can only have a single forwarded x11 display.
> 
> > Both of these make sense to me.
> 
> The former sounds more reasonable to me than the latter.  I'm rather
> uncomfortable wiring the assumption that a session has at most one X
> display into the protocol.

I think I can agree with that, even if I don't think it matters much
in practice.

Regards,
/Niels