RE: Section 4.1 clarifications

["Michael Krueger" <michael.krueger@windriver.com>]

Julo,

> The integer representation was discussed a long time ago on the
> list and it was decided that decimal should be allowed as it might
> be copied from some human readable tables. I would hate to make
> this type of changes this late.

I agree that decimal encoding should be retained for NUMERIC CONSTANTS, for
the reasons you state.  However, I do not believe it makes any sense to
allow decimal representations of BINARY ITEMS.

I think a concrete example might help here.  I am in the process of
implementing CHAP authentication.  Section 10.5 of the spec states that
CHAP_A and CHAP_I are "numbers" and CHAP_C and CHAP_R are "binary items and
their binary length (not the length of the character string that represents
them in encoded form) MUST not exceed 1024 bytes."

When I parse CHAP_A and CHAP_I, which I'm calling "numeric constants," I'll
allow decimal or hexadecimal representations, but I certainly won't be able
to cope with a number whose decoded value is wider than 4 bytes . . . and I
doubt that anyone else will, either.  [Let's face the fact that unless they
are explicitly told to expect decoded values longer than, say, 4 bytes,
implementers will use stroul() or its equivalent in a situation like this.]

When I parse CHAP_C and CHAP_R, which I'm calling "binary items," I expect
numbers whose decoded values could be up to 1024 bytes long.  I can easily
convert hexadecimal or base-64 representations of such values into binary
data; however, I WILL NOT be able to cope with decimal encoding, which in
this case could have up to 2,467 digits . . . and I doubt that anyone else
will, either.  (The "human readable tables" argument goes out the window in
this case as well . . . who will be typing those 2,467 decimal digits?)

As the wording of Section 10.5 already shows, there is a need to make a
distinction between "numeric constants" ("numbers") and "binary items."  I
am only suggesting that this be done consistently throughout the spec, with
a single clear definition for each term.

Michael

--
Michael J. Krueger              mailto:michael.krueger@windriver.com
Wind River Networks                         http://www.windriver.com
500 Wind River Way                               phone: 510-749-2130
Alameda, CA  94501                                 fax: 510-749-2010