RE: Problem reporting PIDs with IDMEF

At 01:33 AM 7/23/2002, Sims, Rayford wrote:
> >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.
>
>If I recall correctly the spec specifically says that an INTEGER may be
>encoded in base10 or base16.  It is not for the DTD to enforce dataypes,
>since XML specifically prevents this, but the full specification does say
>waht the datatypes should mean and every compliant parser should enforce
>this.

You are right. I went back to section 4.4.1 and it does state base16 as 
being OK. I missed that. As long as it states that you can use either, then 
software must be written to expect either. This is fine because it clearly 
states the two formats expected. What isn't fine is that it does not bound 
the values.

>I believe that this is a problem with the IDMEF libraries that you are
>using.

It is a problem in that they used the type "integer" internally (that's 
what the spec said, after all...) and tried to take the numeric string 
inside the <PID> tags and stuff it into the integer. Well... this doesn't 
work too well when the actual number is larger than what can be stored in 
the integer type on that platform.

>To be sure, it would not be a bad idea for the spec to define the
>range of these values, however just because the spec uses the word INTEGER
>it is not necessary that this fit into a 32 bit integer.

Yep. One can always come up with a value that can exceed what the storage 
is capable of representing. Obviously some error checking in the library we 
are using would have been desirable. I'm just trying to point out that the 
spec should be clear on the bounds of what can be expected in fields of 
various types. Then folks can write software that is compliant AND 
interoperable.

>I do agree
>however, that the word INTEGER is misleading.
>
>As David points out, the use of a hex value would avoid this problem and it
>owuld not be a violation of the spec.
>
> >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.
>
>This is a good work around.  Again I think that the long term solution is
>for the JavaIDMEF software to conform to the full letter of the spec and to
>support hex PIDs if it does not already.

It may. We didn't try this.

>I don't mean to send you away to someone else for help with your problem,
>but although the spec is somewhat ambiguous it does state that hex values
>are to be supported.

I'm not looking for help with my problem. I've already found something that 
will work. I am trying to make the authors of the spec recognize and fix 
what I perceive to be a deficiency in IDMEF from the actual use of it in a 
real distributed system as opposed to just reviewing a document. If you 
want IDMEF to get better and be adopted and used by the community, you need 
this kind of feedback.

>If the javaIDMEF software doesn't support this you
>should take it up with the authors of that software.

It is no longer supported. It implements IDMEF 0.3. We are going to have to 
do a rewrite just to move to 0.7.

>But I do think that we should have some talk about bounding these values or
>using only base16 encoding to disambiguate this some or not using the word
>integer.  Let me know what you all think.

My vote would be to not use the word integer as it is very misleading. 
Instead state that it is a numeric value represented in either base10 or 
base16 that falls within some defined range. Alternatively you could state 
that it is a 16-bit (or 32-bit - choose) integer (better - for PIDs to be 
unsigned). Then it is up to the software to be able to handle it 
appropriately based on their platform. At least code developers will be 
told explicitly what to expect and know what to write.

-L
p.s. Hey Mike - here's your mailing list traffic....