Hi,
> So, what's the conclusion? Is this packet correct or not?
Here is my opinion on the subject.
I think the packet is correct - zero length encoding is perfectly fine.
I see zero length SETs every day.
[If you want an example - most X.400 systems use the default ia5 repertoire
for text bodyparts in the ASN.1 below - resulting in a zero length SET. I've
even seen implementations encode it in 6 bytes - which beats a "disgusting"
- but perfectly valid - indefinite length encoding.
IA5TextBodyPart ::= SEQUENCE {
parameters IA5TextParameters,
data IA5TextData
}
IA5TextParameters ::= SET {repertoire [0] Repertoire DEFAULT ia5
}
]
> I think that:
>
> 1. If the packet is incorrect (in terms of BER-encoding), then
> the "BER error" message should be put back, but the dissection
> of the current sequence should not be aborted.
I don't think it is an error.
(If there had been a constraint then it would have been an error - but
asn2wrs doesn't do any bounds checking at the moment.)
> 2. If we don't know whether it is correct or not, probably we should
> give warning instead of error?
I think it is correct.
> 3. Anyway, those 'one item of zero length' lines in the decoded
> packet tree should be changed to '0 items' or removed completely.
If I recall correctly, this issue was when displaying a zero length SEQUENCE
OF?
In which case, I think it should be changed to '0 items' (and not removed)
to be clear and consistent.
Graeme
