Index: ossp-pkg/uuid/uuid.c
RCS File: /v/ossp/cvs/ossp-pkg/uuid/Attic/uuid.c,v
rcsdiff -q -kk '-r1.39' '-r1.40' -u '/v/ossp/cvs/ossp-pkg/uuid/Attic/uuid.c,v' 2>/dev/null
--- 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