Richard,
> The first change I want to make is to:
>
> - For filter expressions, add a sub-tree to the dissection tree
> - The filter dissector will adorn the subtree with the
> actual LDAP structure of the filter. The sub-structure
> will include all the pieces defined in the RFC, including
> optional elements (with DEFAULTS where needed).
> - When the filter expression has been collected, add it to
> the sub-tree node as text.
If you go down the asn2eth route, which you really should, then the
basic filter display will be the same as for the DAP (LDAP's big
brother) dissector, which uses asn2eth . See:
http://www.itu.int/ITU-T/asn1/database/itu-t/x/x511/2005/DirectoryAbstractService.html#DirectoryAbstractService.Filter
They are slightly different (e.g. item has been expanded in-line for
LDAP) but certainly comparable.
I am planning to augment the Filter display in the DAP dissector to
similarly provide an LDAP string representation of the filter. Whilst
there may be too many differences to use the same code - we should try
and ensure we display the filter in the same way. For example, do you
plan to display each fragment of the filter expression at the
appropriate point in the subtree?
> - Restructure the dissector so that it displays LDAP request
> structures more in alignment with the RFC.
>
> - Include other structures that are currently not displayed,
> even when they are empty.
I'm not sure what you mean here.
I can see that you could display "DEFAULT" values if the field is not
present (of which I can see only a couple LDAP).
But do you mean to show OPTIONAL elements are empty/not present?
Graeme
