Re: [OPSAWG] WGLC draft-ietf-opsawg-mib-floats

[Dave Shield <[e-mail]>]

On Thu, 31 Mar 2011 17:15:58 +0200 Juergen wrote:
JQ> I have read the draft and have only one question:
JQ> Would the byte order (endianness) in the octet arrays be obvious to an
JQ> implementor? Or could there be incompatibilities between big-endian and
JQ> little-endian implementations?


On 31 March 2011 17:28, Robert Story <[e-mail]> wrote:
RS> I asked about this back in December


Given that two (more-than-averagely-clueful) readers of the draft
have come up with the same question,  perhaps this is an indication
that the answer could do with being a little clearer.



On Mon, 6 Dec 2010 13:07:18 -0800 Randy wrote:
RP>  I specifically said "interchange format"
RP> for IEEE floats, since that *does* specify that the sign bit comes
RP> first.  For a freely-available secondary reference, see
RP> http://en.wikipedia.org/wiki/IEEE_754-2008#Interchange_formats

I can't help feeling that I'm missing something here,
but I'm not sure whether this actually answers the question.

That wikipedia reference says

    "The encoding scheme for these binary interchange formats
     [of floating point data] is the same as that of IEEE 754-1985:
     a sign bit, followed by w exponent bits that describe the exponent
     offset by a bias, and p-1 bits that describe the significand. "

So the sign bit comes first, followed by the exponent
and finally the significand.
    But are the exponent and significand bits in LSB or MSB
order?   Or is this implementation specific?

As far as I can tell from
   http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness
the IEEE spec is ambiguous here:

      "..the widespread IEEE 754 floating point standard does not specify
      endianness. Theoretically, this means that not even standard IEEE
      floating point data written by one machine may be readable by another."

If the intention is that floating point values should be represented in
network byte order  (which seems the most natural approach), then
shouldn't this document say so explicitly?


Dave