Re: Problem reporting PIDs with IDMEF

At 03:00 PM 7/22/2002, David A. Curry wrote:
>1. Remember, XML doesn't actually have types.  The only reason we identified
>    types for things at all was just to make it clear, for example, that we
>    expect an integer-ype datum here, as opposed to say, a string.

Yes. But unfortunately if you say "integer", people think that's what you 
mean. It would appear that folks appear to be taking it at face value and 
encoding the internal parsing of their software based on the spec. E.g., we 
use the JHU APL JavaIDMEF software. It throws an exception if you pass in a 
number that won't fit in an integer. Perhaps it would be better to say it's 
a numeric value and don't use well defined types that one might accidently 
interpret as the actual type to be encoded.

>    In hindsight, your point about unsigned is a good one, although since we
>    do not specify minimum or maximum values for those sorts of data, I'm not
>    sure it would ultimately make any difference (you can always find a size
>    it won't fit in).

>2. "Be conservative in what you send, and liberal in what you accept."  :-)

Unfortunately we cannot control what an operating system encodes as a PID, 
so we cannot be conservative in what we send exactly. Basically our 
(hopefully temporary) work-around is to set the PID to -1 (since it IS 
signed) and to use AdditionalData of type string to encode the actual value.

>You could certainly use an unsigned, if you wanted to.  Or, put it out in
>hexadecimal and don't worry about the sign.

Ummm... the spec says integer, not hex. So that's what folks expect. I 
understand that XML natively doesn't actually enforce this stuff, but a DTD 
should. Any software compliant with the DTD must enforce what it says. 
We're developing plug-and-play sensor/alert collector/correlator software 
around IDMEF. That IS the purpose of IDMEF, right??? If we use hex, then 
other software will not expect hex because the spec says integer. That 
means our system is technically not compliant with the spec and won't be 
plug-and-play. The spec needs to clearly define what it expects to see in 
these fields. People must be able to develop software knowing what to 
expect based on what the spec says. Otherwise, IDMEF is useless for the 
purpose of integrating heterogeneous sensors.

>I will point out that "0.3" is a pretty old version of IDMEF.  You might want
>to think about getting a newer one, depending on how far along you are.

Yes. We're well aware and very much want to move to a newer version. 
Unfortunately when we got started on this, 0.3 was the latest. We plan to 
move to 0.7 (or newer if available) but cannot do so until this experiment 
is completed.

-Laura