Ethereal-dev: Re: [Ethereal-dev] New field types proposal

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Ulf Lamping <[email protected]>
Date: Fri, 30 Jul 2004 19:20:06 +0200
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