--- uuid.c 2004/01/19 09:26:55 1.39
+++ uuid.c 2004/01/19 12:08:28 1.40
@@ -79,40 +79,39 @@
never be a conflict between UUIDs generated by machines with and
without network cards."
- This clearly explains that the intention is to use IEEE 802 multicast
+ This passage clearly explains the intention to use IEEE 802 multicast
addresses. Unfortunately, it incorrectly explains how to implement
- this! It actually is the "*LEAST* significant bit of the first octet
- of the node ID" in a memory and hexadecimal string representation of
- a 48-bit IEEE 802 MAC address.
+ this! It should instead specify the "*LEAST* significant bit of the
+ first octet of the node ID" as the multicast bit in a memory and
+ hexadecimal string representation of a 48-bit IEEE 802 MAC address.
Unfortunately, even the reference implementation included in the
expired IETF "draft-leach-uuids-guids-01" incorrectly set the
multicast bit with an OR bit operation and an incorrect mask of
- 0x80. Hence, multiple other UUID implementations can be found on the
- Internet which inherited this bug.
+ 0x80. Hence, several other UUID implementations found on the
+ Internet have inherited this bug.
Luckily, neither DCE 1.1 nor ISO/IEC 11578:1996 are affected by this
problem. They disregard the topic of missing IEEE 802 addresses
entirely, and thus avoid adopting this bug from the original draft
and code ;-)
- The reason for the bug in the standards seems to be that the
- multicast bit actually is the *MOST* significant bit in IEEE 802.3
- (Ethernet) _transmission order_ of an IEEE 802 MAC address. The
- authors seem to be confused by this and especially were not aware
- that the bitwise order of an octet from a MAC address memory and
- hexadecimal string representation is still always from left (MSB, bit
- 7) to right (LSB, bit 0).
-
- For more information on this, see especially "Understanding
- Physical Addresses" in "Ethernet -- The Definitive Guide",
- p.43, and section "ETHERNET MULTICAST ADDRESSES" in
- http://www.iana.org/assignments/ethernet-numbers.
-
- Hence, we do it the intended/correct way and generate a real IEEE 802
- multicast address, but with a brain-dead compile-time option one can
- nevertheless enforce the broken generation of IEEE 802 MAC addresses.
- For the decoding we always use the correct way, of course. */
+ It seems that this standards bug arises from a false interpretation,
+ as the multicast bit is actually is the *MOST* significant bit in
+ IEEE 802.3 (Ethernet) _transmission order_ of an IEEE 802 MAC address.
+ The authors were likely not aware that the bitwise order of an octet
+ from a MAC address memory and hexadecimal string representation is
+ still always from left (MSB, bit 7) to right (LSB, bit 0).
+
+ For more information, see "Understanding Physical Addresses" in
+ "Ethernet -- The Definitive Guide", p.43, and the section "ETHERNET
+ MULTICAST ADDRESSES" in http://www.iana.org/assignments/ethernet-numbers.
+
+ At OSSP, we do it the intended/correct way and generate a real IEEE 802
+ multicast address. Those wanting to encode broken IEEE 802 MAC addresses
+ (as specified) can nevertheless use a brain dead compile-time option
+ to switch off the correct behavior. When decoding we always use the
+ correct behavior of course. */
/* encoding */
#ifdef WITH_RFC2518
|
