Subject: Re: [siprec] Format options for unique IDs

From: Leon Portman <[email-masked]>
Date: Sun, 3 Jul 2011 13:50:26 +0300

I am ok with all options. Actually the question is if from SRS point of view, should it even care? It will be just string with identifier. Should it have any assumptions about it expect uniqueness?

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, June 24, 2011 5:38 PM
To: [email-masked]
Subject: [siprec] Format options for unique IDs

On 6/24/2011 5:58 AM, Elwell, John wrote:

> - Options for globally unique IDs, along with pros and cons (Partha to 
> initiate)

I'm not Partha, but I'll comment. Some possibilities:

A) A generic URN, with added constraint that equality is
    based only on lexical equivalence (as defined in rfc 2141)

B) UUID URN (rfc 4122)

C) UUID encoded more densely than the UUID URN
    (e.g. radix64 of the binary uuid form defined in 4122)

Pros/cons of these:

A) Pro: very flexible for the SRC. It has many options for
    how to create and encode IDs.

    Pro: ease of generation, assuming the SRC chooses wisely.

    Con: Difficult for the SRS. It must deal with variable
    unbounded length ID. Doesn't easily fit in databases.

    Con: Somewhat inefficient wire encoding:
    there is minimum length of "URN:" plus NID (namespace identifier).

    Pro/Con: Wire efficiency varies depending on SRC choices.
    Could be very good or very bad, depending on what NID is chosen.

B) Pro: very flexible for the SRC. 4122 provides multiple ways of
    generating the UUID. One of them (the name based one) would
    allow generating a UUID from the same strings you might use
    for (A), so its at least as flexible as (A).

    Pro: easy of generation. Like (A), but then requires an SHA-1
    computation. So not as easy as (A).

    Pro: Simple for SRS. The UUID can be easily extracted from
    the URN and converted to a fixed length (16 bytes) binary value.
    That value then can be stored in databases, compared, etc.

    Con: Somewhat inefficient wire encoding. The urn encoding is
    45 bytes.

    Pro: Flexible to future extension to other sorts of URNs
    (e.g. (A)) due to the use of the URN syntax.

C) Pro: very flexible for the SRC. (Identical to (B))

    Pro: easy of generation. Virtually the same as (B).
    (The final textual formatting is different from (B), but
    similar (insignificant) computationally.)

    Pro: Simple for SRS. Virtually the same as (B).
    (The final textual formatting is different from (B), but
    similar (insignificant) computationally.)

    Pro: Efficient wire encoding.
    (Radix 64 takes 22 bytes to represent the 16 binary bytes.)

For the metadata these would probably all be wrapped in XML in comparable ways, so none has an advantage over another in that respect.

Please feel free to propose other alternatives.

As a specific example, for the UUIDs, one could use the 4122 "name based" approach, where the "name" is just a binary integer counter.

	Thanks,
	Paul

_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 03 Jul 2011 17:57:01 -0400

> I am ok with all options. Actually the question is if from SRS point of view, should it even care? It will be just string with identifier. Should it have any assumptions about it expect uniqueness?

Well, that is part of the discussion.
Not caring implies that it is happy using arbitrarily long strings as 
IDs, which has an impact on DB schema design.

I'm not a DB guy, so I'm perfectly fine with variable length strings.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Mon, 4 Jul 2011 09:42:23 +0300

Paul, Hi

I understand the concern. BTW from DB point of view, anyway SRS usually will create its own key as a primary key (for multiple reasons, specially for data base portioning and multi-tenancy support). And SRC generated ID is only used for external references.

Leon

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, July 04, 2011 12:57 AM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] Format options for unique IDs

Well, that is part of the discussion.
Not caring implies that it is happy using arbitrarily long strings as IDs, which has an impact on DB schema design.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 13 Jul 2011 10:15:07 +0200

Although it was in reply to me, I think this list of possibilities proposed by Paul a few weeks ago should have attracted comment from the rest of the group, but I don't recall seeing anything. Personally, C) looks attractive, but I don't have a strong opinion. Would others please express opinions - it is important to get some sort of closure on this.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 24 June 2011 15:38
> To: [email-masked]
> > - Options for globally unique IDs, along with pros and cons 
> (Partha to initiate)
> 
> For the metadata these would probably all be wrapped in XML in 
> comparable ways, so none has an advantage over another in 
> that respect.
> 
> As a specific example, for the UUIDs, one could use the 4122 "name 
> based" approach, where the "name" is just a binary integer counter.
> 
> 	Thanks,
> 	Paul
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 13 Jul 2011 12:53:02 -0700

I was hoping there would be discussion around additional pros and cons
of each approach. As that has not happened, and I do not have any of my
own to propose, option C looks best to me as well.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Wednesday, July 13, 2011 1:15 AM
> To: Paul Kyzivat (pkyzivat); [email-masked]
> Subject: Re: [siprec] Format options for unique IDs - INPUT REQUIRED
> 
> Although it was in reply to me, I think this list of possibilities
proposed by Paul a few weeks ago
> should have attracted comment from the rest of the group, but I don't
recall seeing anything.
> Personally, C) looks attractive, but I don't have a strong opinion.
Would others please express
> opinions - it is important to get some sort of closure on this.
> 
> John
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jul 2011 16:38:49 -0400

> own to propose, option C looks best to me as well.

After writing them all out, I could find little to dislike about (C).

One additional con for (C): its a unique format created just for siprec, 
rather than being some already recognized format.

If we go that way, we will have to be careful to precisely specify the 
encoding. I found RFC4648, which gives rules for the encoding. And of 
course we must define the byte order for this - network byte order. 
Those with little-endian machines (e.g. x86) will have to be careful 
about the encoding.

Does anybody know if a format such as this has already been defined in xml?

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jul 2011 09:07:03 +0200

Resending with Paul's new address
#################################

John

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 14 Jul 2011 14:30:09 +0530

Paul,

I'm fine with Option (C) which is a network optimization for URN
UUID(RFC 4122). Including Peter & Joe in this mail thread who initially
proposed URN UUID to see any other downside in radix64 format unique-id
from XML perspective apart from the need for defining network byte order
which you have mentioned below.

XML readability will be missing in case radix64 is used because of the
encoding format but I really don't know whether it matters.

Thanks
Partha

> Sent: Thursday, July 14, 2011 2:09 AM
> To: [email-masked]
> > of each approach. As that has not happened, and I do not 
> have any of 
> > my own to propose, option C looks best to me as well.
> 
> One additional con for (C): its a unique format created just 
> for siprec, rather than being some already recognized format.
> 
> If we go that way, we will have to be careful to precisely 
> specify the encoding. I found RFC4648, which gives rules for 
> the encoding. And of course we must define the byte order for 
> this - network byte order. 
> Those with little-endian machines (e.g. x86) will have to be 
> careful about the encoding.
> 
> >>> comparable ways, so none has an advantage over another in that 
> >>> respect.
> >>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jul 2011 17:32:37 -0400

On 6/24/11 10:37 AM, Paul Kyzivat wrote:
> comparable ways, so none has an advantage over another in that respect.
> 

Having talked about this with Paul just now in Quebec City, I suggest
either a bare UUID (no "urn:uuid:") or option (c). I have no preference
between those two.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/