Hi Thomas.
>> ie. bit 0 is set to say this is the end of the address field -
>> by this means, AX25 (and X25 on which it is based) already
>> support variable length address fields.
>> That most implementations don't support it is another matter
>> entirely!!!
> Well, this is not exactly true. If you read the AX.25
> specification (2.0 or 2.1), you will see that what you assert is
> true, but you overlook the technical hurdle. Bit 0 is 0
> throughout ALL addresses except for the last octet. This is to
> comply with the SDLC addressing style to facilitate hardware
> computation of the CRC FCS. The difficulty lies in sifting out
> the calls.
Nodz...
> The 2.x specification states that the addressing fields must be
> an even multiple of seven octets. This currently rules out
> variable length IDs. Having some sort of flag within each
> address to mark its end, or having a length field as was
> proposed earlier, makes the most sense.
Nodz...
> Unfortunately, it would mean that these stations would be unable
> to connect with stations which do not understand the new
> addressing scheme.
If it was implemented correctly, there would be no problem with such a
system. Basically, the only section of the protocol that needs to
worry about whether to use the current or new addressing system is the
SABM or SABME frames, which start the link up in the first place, as
all other stages of the link use whatever they agree on, as per the
current AX.25 standard.
In fact, the HDLC standard on which it is based already defines how
such a system is to be handled, and precicely what should occur under
all possible scenarios, so there's very little to be agreed on other
than precicely what is meant by "Extended mode" as opposed to
"non-extended mode".
If you have access to the ISO standard for HDLC, look up the diagrams
relating to negotiations between systems supporting both SABM and
SABME modes to see the various possible timing diagrams, together with
when the negotiation should result in SABM being agreed, and when it
should result in SABME being agreed. Also in the same document are the
timing diagrams for when one end is SABM and SABME capable, but the
other only supports SABM, so that is dealt with as well.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
