Sorry I was thinking about Sequence and Set not sequence_of and set_of
that the question was about.
It is my understanding that SEQUENCE_OF and SET_OF are completely equivalent
in all types of
encodings based on x690 BER/DER etc.
However, SET and SEQUENCE encodings may differ (for pure BER (non-DER)
encodings)
in that in BER a SET may
1, implicitely assumes all fields are optional as compared to a SEQUENCE
where the optionality have to be explicitely specified
2, a SET may encode the individual field "out of order" while a SEQUENCE may
not. (which might not actually exist in the wild)
Anyway, SET adn SET_OF are similar enough to SEQUENCE and SEQUENCE_OF so
that helpers for them would hopefully be trivial to add.
Unless Thomas changes his mind and does not want to add them I can add
them.
some benefits with packet-ber.c compared to asn1.c are that
1, packet-ber.c makes all fields have display filters
2, hides all the asn.1/ber stuff from the dissector, just push a table to
the helper and let it figure everything out.
there are warts. plenty of them. but none that is bad enough that noone will
fix it eventaully.
One bad wart is the handling of named bitfields. It should REALLY have an
interface where one pass also the individual bit hf_fields
in an array or something to it to not have the user do all the boring
encoding and checking of bytes/bits in the actual
dissector itself.
See the dissection of Ticket options etc in packet-kerberos.c
----- Original Message -----
From: "Ronnie Sahlberg"
Sent: Monday, March 08, 2004 8:37 PM
Subject: Re: [Ethereal-dev] Trying to work with packet-ber.c ...
> packet-ber.c currently only implements those parts of x.690 that
dissectors
> actually use.
> today that is kerberos (which actually is DER and not BER but that is not
a
> difference that a decoder only
> implementation need to worry about)
>
> other missing parts of BER should/can be added as is needed.
>
> as for object identifiers, those should be similar to the function in
> packet-per.c
> so some cut-n-paste should work.
>
> SET OF should for most cases be possible to implement as
> dissect_ber_set_of(){
> offset=dissect_ber_sequence_of()
> return offset;
> }
>
> OK. a set of aggregate differs from a sequence of in that the elements
may
> be encoded "out of order" but:
> 1, is that actually used in any known implementations?
>
> perhaps rewrite dissect_ber_sequence_of() to be able to handle out of
order
> element encodings and make set of == sequence of
>
> or just make already today set of == sequence of without changing
anything
> and see if anyone complains?
>
>
> I do recall, but dont hold me to this because it might be wrong, that for
> DER that it is required that set of elements are encoded in the
> same order they are defined in asn1 which for DER would make set of and
> sequence of for all purposes equivalent.
>
>
> ----- Original Message -----
> From: "Tomas Kukosa"
> Sent: Monday, March 08, 2004 8:22 PM
> Subject: Re: [Ethereal-dev] Trying to work with packet-ber.c ...
>
>
> > I have implemented an 'OBJECT IDENTIFIER' and I will think of a 'SET
OF'.
> > I try to make most important packet-ber extensions till Friday.
> >
> >
> > Yaniv Kaul wrote:
> >
> > > 1. How do I dissect a 'SET OF'?
> > > 2. How do I dissect an 'OBJECT IDENTIFIER' ?
> > >
> > > I must say that it *looks* like it's much easier to work with asn1.c
> > > functions than packet-ber.c
> > > Perhaps it takes time to get used to.
> > > The only example is packet-kerberos.c, which is nice, but doesn't
always
> > > give all that's needed.
> > >
> > > _______________________________________________
> > > Ethereal-dev mailing list
> > > Ethereal-dev@xxxxxxxxxxxx
> > > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > >
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
