Imported from previous forum
[ original email was from Satoru Mizukami - satoru.mizukami@nssmb.com ]
Is there any reason for setting the BodyLength limitation?
From the 4.1 spec, Tag9:BodyLength format looks like 4-digits, it means 9999 is max size of part of its body.
But I do not see any length limitation for each field such as text fields in the spec.
I know the limitation makes the development easier,
however if there ware no such kind of limitation, nobody makes messages longer than his or her needs.
(Is there any possibility of erasing the limit in further revisions of the spec or
changing to flexible expression like [less than 1000 is preferred] ?)
I explained behind this question.
Now Japan work group is discussing the allocation message in Japan.
In that message , there are some repeating group ,So
we are afraid the total length may be beyond that limitation.
( I guess that over 95% of our alloc-msg will be in 9999-byte,
but less than 5% will may break the limit.)
For the sake of 5%, we do not want to propose new structure of allocation message( like AllocListID ).
But on the other hand,we will get grateful efficiency to use Fix-protocol for the operation of that 5%.
It is possible that messages with repeating groups could exceed 9999 in size. The Technical Committee will consider clarification on this for a future Errata item and the next version of the spec. I will warn you that there are some systems out there which provide leading zeros for this field in messages they send.
> Is there any reason for setting the BodyLength limitation?
>
> From the 4.1 spec, Tag9:BodyLength format looks like 4-digits, it means 9999 is max size of part of its body.
> But I do not see any length limitation for each field such as text fields in the spec.
>
> I know the limitation makes the development easier,
> however if there ware no such kind of limitation, nobody makes messages longer than his or her needs.
>
> (Is there any possibility of erasing the limit in further revisions of the spec or
> changing to flexible expression like [less than 1000 is preferred] ?)
>
>
> I explained behind this question.
> Now Japan work group is discussing the allocation message in Japan.
> In that message , there are some repeating group ,So
> we are afraid the total length may be beyond that limitation.
> ( I guess that over 95% of our alloc-msg will be in 9999-byte,
> but less than 5% will may break the limit.)
>
> For the sake of 5%, we do not want to propose new structure of allocation message( like AllocListID ).
> But on the other hand,we will get grateful efficiency to use Fix-protocol for the operation of that 5%.
>
>
>
>
>
>
>