[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: going back to stone axes
Carl,
> For example, there is no simple int32 in ASN.1. To achieve that, you
> have to start with an INTEGER and then add a bell/whistle which limits
> its range -- but you can't just limit its number of bits -- you
> specify its min and max value, and then have to decide what an
> internal 0 really means.
What's the bit about deciding "what an internal 0 really means"?
You lost me.
Anway, the notation is the way it is so that you can specify semantics other
than just the number of bits required to hold the integer value. For
example, an integer type may be defined as "INTEGER (0 | 20..100 | 200)"
which says that the integer value can be 0, 20-100 or 200. This
expresses more about the type than simply saying that it is an
unsigned integer value that fits into two bytes.
Of course you can always state such restrictions in comments, but by
embedding this information in the definition of the type you add no
complexity to the implementor's program if they wish to manually check
the constraints on the integer, and for those implementors who wish to
use ASN.1 tools they can end up writing far few lines of code, for it
is possible for ASN.1 compilers to generate the code to do all such
constraint checking. Fewer lines of code means programs tend to be
more bug-free, easier to maintain and quicker to reach market.
> So, people rarely limit their INTEGERs --
I invite you to look at any of the more recent protocols that use
ASN.1, such as TDP for paging devices, T.120 for teleconferencing,
H.245 for multimedia system control, the FAA's new flight control
protocol, etc.; you will see hardly an INTEGER whose set of values is
not limited. And take note that those that are out of development and
are rapidly being deployed, T.120, for instance, have an extremely
high degree of success in interworking. All this without the gnashing
of teeth that nay sayers would have you believe is inevitable when
ASN.1 is used.
Bancroft Scott