Ulf Lamping wrote:
Tomas Kukosa wrote:
I think about following new field types:
1) FT_UUID - Universally Unique IDentifier
fixed length 16 bytes
display format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
I would agree. However, as UUID's sometimes can be replaced by some sort
of name resolution, e.g. in DCE-RPC, it might not be helpful in all
situations.
It could be the next step to implement some name resolution into FT_UUID displaying.
2) FT_OID - ASN.1 OBJECT IDENTIFIER
variable length
dotted numeric display format (could be alternated with display
option)
There are a lot of different object identifiers, with lot's of different
formats, so it's maybe not a good idea.
What other object identifiers do you mean?
Nevertheless I think the FT_OID would be helpfull as ASN.1 OBJECT IDENTIFIER type is used
in many protocols (H.323, X.509, Kerberos, SNMP, GSS-API, ...).
Fortunately the BER and PER encoding of OIDs are the same.
Furthemore some "OID name resolution" could be implemented later.
3) FT_PSTRING - conditional printable string
variable length
display format like FT_STRING if all charactes are printable, like
FT_BYTES if not
Could you explain this a bit more detailed?
Some protocol fields are defined as byte stream which can contain arbitrary bytes but they
contain usually (but not always) readable string.
It would be usefull to display such a field as a string if it is possible but as bytes if not.
Regards,
Tomas
Regards, ULFL