Index: ossp-pkg/uuid/uuid.c
RCS File: /v/ossp/cvs/ossp-pkg/uuid/Attic/uuid.c,v
rcsdiff -q -kk '-r1.28' '-r1.29' -u '/v/ossp/cvs/ossp-pkg/uuid/Attic/uuid.c,v' 2>/dev/null
--- uuid.c	2004/01/15 16:22:09	1.28
+++ uuid.c	2004/01/15 17:24:56	1.29
@@ -444,34 +444,34 @@
  * conflict between UUIDs generated by machines with and without network
  * cards."
  *
- * This clearly explains what the intention is. Unfortunately, it
- * explains it incorrectly how to achieve this. Because (see also
+ * This clearly explains the intention. Unfortunately, it incorrectly
+ * explains how to achieve it. Because (see also
  * http://www.iana.org/assignments/ethernet-numbers and "Understanding
  * Physical Addresses" in "Ethernet -- The Definitive Guide", p.43) it
  * is the "LEAST significant bit of the first octet of the node ID" in a
  * memory representation of a 48-bit MAC address. The reason is that it
  * is the MOST significant bit only in IEEE 802.3 _transmission order_
- * of a MAC address. The memory order of an octet from a MAC address is
- * always with the bits from left/MSB/bit-7 to right/LSB/bit-0!
+ * of a MAC address. The bitwise memory order of a MAC address octet is
+ * always from left/MSB/bit-7 to right/LSB/bit-0!
  *
  * Unfortunately, even the reference code in
  * "draft-leach-uuids-guids-01" incorrectly sets the multicast bit with
  * an "OR 0x80" bit operation. This could be considered "standards
  * compliant" (because the exact wording above is "with the most
- * significant bit"), but from the remaining explanation it becomes 100%
+ * significant bit"). However, from the remaining explanation it becomes 100%
  * clear that the intention was different and the wording and code was
- * incorrect because the authors were unaware of this difference in bit
+ * incorrect. The authors were likely unaware of this difference in bit
  * ordering between memory and wire transmission.
  *
- * So, OSSP uuid does it the intended/correct way and generates a real
- * IEEE 802 multicast address, but with a compile-time option one can
- * nevertheless enforce the generation of incorrect addresses according
- * to the standards. For the decoding we always use the correct way, of
+ * By default, OSSP uuid works the intended/correct way and generates a real
+ * IEEE 802 multicast address. Nevertheless, a compile-time option exists
+ * for the generation of incorrect addresses according
+ * to the standards. For the decoding we always use the correct way of
  * course.
  *
- * Luckily, both DCE 1.1 and ISO/IEC 11578:1996 do not deal with the
- * situation of not available IEEE 802 addresses at all and so have
- * avoided to adopt this bug from the original draft and code ;-)
+ * 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 ;-)
  */
 
 /* encoding */