> You mean the AX.25-PID (Protocol-Identifier) may change during a
> connection? Thats sounds wrong to me.
No its not wrong at all. If the protocol were restricted per AX.25 connection
then they would have put the PID into the SABM instead. It is quite possible (and
I have seen it) to put NET/ROM, ROSE and TCP/IP into one AX.25 connection, there
is never any confusion about what is meant for where. All versions of KA9Q can also
do the same trick (sans ROSE).
> A compression on ax.25-level only make sense for data transmitted with
> no L3-Protocol (PID=0x0f0). Any other protocol is self responsible for
> compression (e.g. VJ for tcp/ip). Otherwise you would e.g. try to
> compress header and data together, which would give unsatisfactionary
> results (e.g. when using NNTP).
Hmmm, and then we have the problem of doing the same trick at each other transport
protocol, with ROSE we could negotiate compression with a new facility, I am not so
sure about TCP/IP or NET/ROM though. BUT there lies a problem by saying that we only
compress on "pure" AX.25, we therefore limit ourselves to not gaining anything on
NET/ROM or other protocols if the *end* stations don't agree to compress, even
though the two participating AX.25 stations can compress, we lose.
I still firmly believe that compression should be on a per application basis,
and should not be built into a transport protocol.
> And you always need another pid for such compressed protocols (eg.
> 0x06 for VJ-TCP/IP or maybe 0xf1 for a compressed NO-Level-3
> connection). So there is no need for quirking around with callsigns or
> ssid's.
I certainly don't like mucking about with callsigns like that. I agree that any
such protocol negotiation should be done by a protocol option rather than by
hard-wired callsign/PID pairs.
> Gruss,
> Walter
Jonathan HB9/G4KLX
> --
> Walter Koch Hochdahl am Neandertal
> [EMAIL PROTECTED] ham:dg9ep@db0iz
> http://home.pages.de/~dg9ep/ qrv:db0iz-9
