Tomas Kukosa wrote:
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?
Well, I can't remember if it was DCE-RPC or DCOM that uses an Object ID,
and I would think other object oriented protocols might also have
something like that, but will have a different representation.
I just think that it will be confusing if you have other protocols using
an OID with a very different representation (e.g. the object ID I can
remember has a fixed length).
If you would call it FT_ASN1_OID (or something like this) I would feel
much better.
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.
How do you explain our users, that it's sometimes a readable string and
sometimes a hex dump or such?
However, I know what kind of data you have in mind and I don't have a
better idea to display something like this :-(
And I would agree to have something like this is far better than having
nothing at all, so every protocol uses a separate approach...
Regards, ULFL
