Subject: [Sip] GRUU Issue 3: Format of instance ID

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Mar 2004 19:17:28 -0500

The specification is currently not clear on how ones computes an 
instance ID. It  has this to say:

Summary of the media feature indicated by this tag: This feature tag
       contains a string that indicates a unique identifier associated
       with the UA instance registering the Contact. This identifier is
       globally unique, and remains bound to the UA instance for as long
       as is achievable. For UA instances that are implemented as
       hardware, such as an IP phone, the instance ID would ideally be
       burned into firmware when the device is manufactured. For
       software, the instance ID would generally be randomly created at
       installation time.

Do we need to say something more specific? A point was raised during the 
meeting that its not sufficient to merely say its unique. THe problem is 
that two separate instances may compute an instance which is unique 
within the approach they are using, but conflicts with a value in 
another approach.

As an example, lets say one UA defines uniqueness by encoding its MAC 
address forwards, and the other by encoding it backwards. Two instances 
with unique MAC addresses may end up with the same instance ID.

So, it seemed like we DID need to say something about how to compute 
this. That seemed a difficult thing to do, as we had several different 
proposals on the table that all seemed reasonable. So, we left the 
meeting without consensus.

I'd like to recommend the following solution:

"This feature tag contains a string that is a URN [URN-REF]. This 
specification makes no normative recommendation on the specific URN that 
is to be used. However, the URN namespace and URN value MUST be selected 
such that the instance can be certain that no other instance would 
choose the same URN value for that particular namespace. One URN that 
readily meets this objective is the UUID URN [UUID-REF], which allows 
for non-centralized computation of a URN based on time, unique names 
(such as a MAC address) or a random number generator. An example of a 
URN that would not meet this objective is the national bibliographic 
number [RFC3188]; since there is no clear relationship between an SIP UA 
instance and a URN in this namespace, there is no way a selection of a 
value can be performed that guarantees that another UA instance doesn't 
choose the same value."

UUID-REF corresponds to 
http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-03.txt. This 
seems to really be exactly what we want, since it allows for computation 
of a URN based on MAC address, time, or random number, and all of the 
hard stuff is already worked out. My proposed text, fortunately, makes 
the URN UUID specification only informative. However, in the absence of 
any other viable URNs that are already at RFC, practically speaking this 
would be the only choice, and so completion of that spec will be 
important for us. Its currently under IESG evaluation, but not without 
some controversy.

Do people feel that this is an acceptable solution?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Mar 2004 21:38:18 -0500

> Do people feel that this is an acceptable solution?

YES.

	Paul