The IP over ATM Mailing List Archive by date

[Carl Marcinik <carlm@fore.com>]

Hi Uttam,
	I moved this back to the thread that it initially came from since it
really is the same topic. Hope you don't mind.

You said:
>Mark,
>	If i understand this right some of our current implementations
>would not be compatible with new revised RFC1577. If an implementation
>used the length as an offset to get to the next field, but the field
>existed being zero-filled with the length indicating zero, we would get the
>wrong field. Why don't we pad the fields, leave the length to indicate
>the length of the field even if it zero-filled and use the operation to 
>determine which field is relevant?

Well, if this were done in the context of Craig's fixed-length field proposal,
you break the case (perhaps) of support for native E.164 addresses and incur
additional overhead that this proposal tries to avoid. You break the E.164
case because here field length does not necessarily equal address length,
assuming of course you use the corresponding address length field to indicate
the actual length of the E.164 address. The other option would be to use 
trailing f's or something similar to indicate the end of the E.164 address.
You incur additional overhead, in order to determine whether or not an address 
is actually present or (in the E.164 case) the address' length, because you 
need to loop through the field (word-wise, perhaps). You could use a bit 
(e.g., msb) in the corresponding address length field to indicate that the
contents of the field are not present. However, this doesn't address the
E.164 case. The real issue here is that the fixed-length field approach
is incompatible with current implementations that assume address length =
field length.

>i.e if ar$spln is 4 then the corresponding ar$spa has 4 bytes (zero-filled
>or otherwise).  The validity of the values can be determined by the context
>of the ar$op.
>
>Does anybody else see this as an interoperatbility problem?
>
>Thanks
>uttam

Carl