Subject: FW: [Moderator Action] RE: WebDAV: UUID/GUID - Please check my math!

From: Jim Whitehead <[email-masked]>
Date: Sun, 15 Aug 1999 16:08:44 -0700

Also caught by the spam filter.

- Jim

P.S. - Dennis -- email I send to [email-masked] is bouncing...

-----Original Message-----
From: Dennis E. Hamilton [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, August 13, 1999 8:06 AM
To: WebDAV Discussion List (E-mail)
Cc: Alan Babich (E-mail); Chuck Fay (E-mail); Jim Green (E-mail); John F.
Greene Jr. (E-mail); Katsumi Kanasaki (E-mail); Mitsuru Akizawa (E-mail);
Richard Sauvain (E-mail); Steve Cousins (E-mail)
Subject: [Moderator Action] RE: WebDAV: UUID/GUID - Please check my math!

In the subject note, please ignore the brain-damaged comment at the end:

>> Can someone please check this for me.
>>And does anyone know where the 3400AD determination came from?
>>(It's true that the timestamp can be smaller for different Variant fields.
>>But the DCE variant field only takes away 2 bits from time-hi.)

I was confusing the DCE variant field with the DCE version field.  The
version field is always 4 bits in a DCE UUID and the timestamp is always 60
bits.  It is the clock-sequence number (a different beast altogether) that
is narrowed as the variant field changes size.

-- Dennis

Dennis E. Hamilton
- - - - - - - - - - - - - - - -
mailto:[email-masked]
tel. +1(650)938.4584
fax. +1(650)567.9846
http://www.infonuovo.com

---

From: Jim Whitehead <[email-masked]>
Date: Sun, 15 Aug 1999 16:08:41 -0700

Caught by the spam filter...

- Jim

-----Original Message-----
From: Dennis E. Hamilton [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Tuesday, August 10, 1999 10:49 PM
To: WebDAV Discussion List (E-mail)
Cc: Alan Babich (E-mail); Chuck Fay (E-mail); Jim Green (E-mail); John F.
Greene Jr. (E-mail); Katsumi Kanasaki (E-mail); Mitsuru Akizawa (E-mail);
Richard Sauvain (E-mail); Steve Cousins (E-mail)
Subject: [Moderator Action] WebDAV: UUID/GUID - Please check my math!

%To:	WebDAV Discussion List
%Cc:	DMA CSDocs Subcommittee
%From:	Dennis E. Hamilton
%Re:	UUID/GUID - Please check my math!

In the DMA work on compound/structured documents, we are using UUID/GUID
values for unambiguously identifying distinguished elements of persistent
material.

I followed the lead in RFC 2518 and did some research into UUID/GUID
schemes.  I wanted to make sure I could describe the conditions where
someone could safely reserve a 32-bit block of Ids for suballocation as part
of some specialized application (e.g., generating UUIDs for locally-unique
elements of a legacy system).

What I came up with is at

	http://www.infonuovo.com/dma/csdocs/sketch/instidid.htm#StandardDmaId

MATH QUESTION

	According to my arithmetic, a timestamp employing a 60-bit 100ns interval
counter will take over 3,653 years to repeat.  Since DCE UUIDs are origined
at 00:00 on October 15, 1582 A.D of the current calendar system, it looks
like we will get FAR beyond 3400AD without a timestamp repetition.

I have repeated this calculation several times and I get the same answer:
2^60 * 0.1 microsecond is over 3,653 years.  (Or (1<<60) * 10E-7 seconds)

I've included the relevant passage below

	(from
http://www.infonuovo.com/dma/csdocs/sketch/instidid.htm#UUIDTimeStamp)

although the formulas aren't as nice as in HTML.

Can someone please check this for me.  And does anyone know where the 3400AD
determination came from?  (It's true that the timestamp can be smaller for
different Variant fields.  But the DCE variant field only takes away 2 bits
from time-hi.)

-- Dennis

Dennis E. Hamilton

UUID TIME STAMP: TIME-LOW, TIME-MID, TIME-HI
------------------------------------------

The time stamp values correspond to the number of 100-nanosecond intervals
that have occurred since the initiation of the current Gregorian calendar on
October 15, 1582 A.D of that calendar.

The 60 bits are expressed in three parts: time-low (32 bits), time-mid (16
bits), and time-hi (12 bits).

The integer value of the time stamp is

(time-hi × 2^16 + time-mid) × 2^32 + time-low

It is not expected that time stamps be accurate to the nearest 100
nanoseconds.  It is expected that time stamps generated with the same node
and clock-seq values be monotonically increasing.  There must be sufficient
accuracy of time-keeping that duplication of identical time stamp and
clock-seq combinations is statistically impossible for a given node
identification.

TIME-LOW

The first group, consisting of 8 hexadecimal digits, specifies the value of
a 32-bit unsigned binary integer, time-low.  As a 100-nanosecond interval
counter, time-low takes  429.4967296 seconds (about 7.16 minutes) before it
repeats.

TIME-MID

The second group, consisting of 4 hexadecimal digits, specifies the value of
a 16-bit unsigned binary integer, time-mid.  The time-mid value advances
each time time-low changes to 0.  So time-mid changes every 429.4967296
seconds.  It will take about

28,147,497.67 seconds, or about

7,818.75 hours, or about

325.78 days

for time-mid to repeat.

TIME-HI

The third group, consisting of 4 hexadecimal digits, specifies the value of
a 16-bit unsigned binary integer.  The high-order nibble of 4 bits is used
for a version field and the remaining 12 bits constitute the time-hi value.
Since time-hi changes every 325.78 days, it will take

1,334,399.89 days, or over

3,653 years (4096 clicks of time-hi)

for time-hi, and hence a value of the entire time stamp, to repeat.

[end of extract]