Subject: [Insipid] Session-ID UUID vs something else

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 3 Jul 2012 22:00:44 -0400

Folks,

We proposed using UUIDs since they are unique in time and space.  The
downside, though, is that they are large.

We could make them smaller, perhaps just assigning random values.

I suppose this is a requirements question.  What is the requirement with
respect to uniqueness in time and space for a Session-ID or the Session-ID
component contributed by one endpoint?  The present proposal we made would
guarantee uniqueness in time and space (depending on the UUID version
employed), but if the requirement is only to have a certain probability of
no collisions, we could use a smaller string of random bits.

Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 4 Jul 2012 03:55:50 +0000

Paul,

The concern of large URN UUID string(RFC 4122)  is raised in SIPREC metadata unique-id as well. The base 64 URN UUID representation reduces the size of the URN UUID and it is mentioned in http://tools.ietf.org/html/draft-ietf-siprec-metadata-07.  The sample base64<http://tools.ietf.org/html/draft-ietf-siprec-metadata-07.%20%20The%20sample%20base64> URN UUID is "hVpd7YQgRW2nD22h7q60JQ==". Here, there is no compromise in uniqueness w.r.t time and space as it is just a different encoding format in the wire.  Please let me know opinion on base64 URN UUID usage.

>From the requirement perspective, the unique id SHOULD meet uniqueness criteria w.r.t time and space as well as the  size of the unique id has to be optimal.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Wednesday, July 04, 2012 7:31 AM
To: [email-masked]
Subject: [Insipid] Session-ID UUID vs something else

Folks,

We proposed using UUIDs since they are unique in time and space.  The downside, though, is that they are large.

I suppose this is a requirements question.  What is the requirement with respect to uniqueness in time and space for a Session-ID or the Session-ID component contributed by one endpoint?  The present proposal we made would guarantee uniqueness in time and space (depending on the UUID version employed), but if the requirement is only to have a certain probability of no collisions, we could use a smaller string of random bits.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 4 Jul 2012 20:15:01 -0400

Partha,

Using Base64 is OK.  No objection.  It saves 8 octets.  We could save 10 if
we toss those last two "==" signs.  They're fairly useless ;-)

Paul

From: Ravindran, Parthasarathi [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2012 11:56 PM
To: Paul E. Jones; [email-masked]
Subject: RE: [Insipid] Session-ID UUID vs something else

Paul,

The concern of large URN UUID string(RFC 4122)  is raised in SIPREC metadata
unique-id as well. The base 64 URN UUID representation reduces the size of
the URN UUID and it is mentioned in
http://tools.ietf.org/html/draft-ietf-siprec-metadata-07.
<http://tools.ietf.org/html/draft-ietf-siprec-metadata-07.%20%20The%20sample
%20base64>  The sample base64 URN UUID is "hVpd7YQgRW2nD22h7q60JQ==". Here,
there is no compromise in uniqueness w.r.t time and space as it is just a
different encoding format in the wire.  Please let me know opinion on base64
URN UUID usage.

>From the requirement perspective, the unique id SHOULD meet uniqueness
criteria w.r.t time and space as well as the  size of the unique id has to
be optimal.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul E. Jones
Sent: Wednesday, July 04, 2012 7:31 AM
To: [email-masked]
Subject: [Insipid] Session-ID UUID vs something else

Folks,

Paul