Subject: Re: [Sipping] instance-ID for SIP UA

From: "Daniel G. Petrie" <[email-masked]>
Date: Fri, 22 Oct 2004 14:05:10 -0400

Yes the main point is that the instance-ID is unique.  Just like the
call-id, the format is not important, uniqueness is.  I agree with
Pauls suggested approaches for generating instance-Ids.  It is also
desirable that the instance-id be persistant for the lifetime of the
user agent.  However as Paul points out some applications require
short user agent lifetimes.

I would add one other recommendation.  As instance-Ids are likely
to be used by adminstrators (e.g. to associate users, devices and profiles,
etc.). Instance-IDs that are easily recognised and replicated by
human beings will make the administrator's job easier.  The ability
to do things like use a bar code scanner on a hardphone to obtain its
MAC address or instance-Id makes life a little easier.  Implementors
of soft UAs will probably want to consider providing means of obtaining
the instance-id before and/or after install so that it can be provided 
out of band to the adminstrator.

Paul Kyzivat wrote:
> 
> Simonetti Gabrielle wrote:
> > In the "Framework for SIP User Agent Profile Delivery", the subscription URI for the "device" profile is based upon the identity of  the device, for the Profile Delivery Server to identify which "device" profile is associated with a specific instance of a User Agent.
> >
> > Let us consider the case of software UA running on multi-user computers where the MAC address is shared and cannot be used as unique identifier. The Framework suggests that in this case a URN be used as the user portion of the device URI, with a reference to the GRUU draft. Section 6 says:
> > "A GRUU is associated [...] with the combination of an AOR and instance ID. [...] The AOR identifies a resource, such as a user or service within a domain, and the instance ID identifies a specific UA instance servicing requests for that resource."
> >
> > My questions relate to the Instance-ID: to my understanding, in the case of the Profile Delivery Framework, the instance-ID itself may be used in the URI to retrieve the "device" profile, if it identifies a specific UA instance with a SIP URI.
> >
> >    First issue - What is the format of the instance-ID?
> > We would like a standardized instance-ID for all UA. Jennings draft suggests the format "RANID-" followed by a 16 digit representation of a random 64 bit number. Couldn't this number be associated with the local domain to obtain a unique URI identifying the UA instance to be used for the subscription to the "device" profile?
> 
> In the GRUU spec we tried not to be too specific about this - it is only
> important that there be a mechanism for comparing instance IDs and that
> each be unique. For this purpose it is sufficient that the id be a URN.
> 
> However, we did have in mind a particular form of URN as especially
> suitable: the UUID URN as defined in draft-mealling-uuid-urn-03. But we
> didn't want to reference it normatively because it would impose a
> dependency on the order in which they become RFCs.
> 
> >    Second issue - Who creates the instance-ID?
> > Should the UA create the instance-ID itself, by generating a random number and having its uniqueness checked by a local server? Or should the instance-ID be provided directly by a local server to the UA at registration to avoid unecessary messages running on the network (since in the case the instance-ID created by the UA is not unique, the server would have to provide the UA with a new one anyway)?
> 
> I don't think there is any single answer to this. The following are my
> personal opinions:
> 
> - a hardware device that contains only one instance (e.g. a phone)
>    should probably create the id itself from its mac address.
>    For this purpose it would be sufficient to use a timestamp of zero.
> 
> - for a software device on a multi-purpose system, where multiple
>    instances might exist, a new instance id should be created each
>    time a new instance is created.
>    . if each instance is created via some sort of installation
>      process, and has persistent state, then the id should be
>      created as part of the installation process and saved with
>      the state. (The installer that creates the instance could
>      run on the same machine or a different one.)
>    . if instances are created dynamically and have no persistent
>      state (e.g. via a "login") then the id needs to be created
>      each time an instance is created.
> 
> There are other cases, and other possible answers. There is no need for
> a uniform process as long as the result is a unique URN in each case.
> 
> >    Third issue - How should the UA obtain the instance-ID?
> 
> See above.
> 
> > It would be appropriate to use SIP to deliver the instance-ID to a UA, eg with the REGISTER method. Are there any other methods that should be considered to deliver the instance-ID?
> 
> I don't see how you can use SIP to deliver the id, since you would need
> to uniquely identify the recipient first. This is a chicken and egg problem.
> 
> >    Fourth issue - Storing the instance-ID
> > What if the UA "forgets" its instance-ID? Does it need to be delivered the same instance-ID as it had before, since the Profile Delivery Server keeps a correspondance between the device profile and a specific instance-ID? How should this problem be solved?
> 
> It depends on how it was created in the first place. If it was created
> from a mac address that is burned into the device, then it won't be
> forgotten unless the mac interface is replaced. If so, the device
> becomes a new device after that.
> 
> For soft devices that persistently store their id, you can use whatever
> mechanism you like to back it up and recover it. And if you can't do
> that you have to create a new one and start over.
> 
> Note that draft-mealling-uuid-urn-03 also has a "name based" way to
> generate a UUID. If you use that mechanism, and have some way to
> remember the name, then you can reconstruct the UUID from it.
> 
>         Paul
> 
> > Regards,
> >
> > Gabrielle Simonetti
> > Telecom Italia
> >
> >
> >
> >
> >
> > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.
> >
> > ====================================================================
> > CONFIDENTIALITY NOTICE
> > This message and its attachments are addressed solely to the persons
> > above and may contain confidential information. If you have received
> > the message in error, be informed that any use of the content hereof
> > is prohibited. Please return it immediately to the sender and delete
> > the message. Should you have any questions, please send an e_mail to
> > [email-masked]. Thank you
> > ====================================================================
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> >
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

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

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 24 Oct 2004 12:44:26 -0700

On 9/21/04 5:49 AM, "Simonetti Gabrielle" <[email-masked]>
wrote:

> We would like a standardized instance-ID for all UA. Jennings draft suggests
> the format "RANID-" followed by a 16 digit representation of a random 64 bit
> number. Couldn't this number be associated with the local domain to obtain a
> unique URI identifying the UA instance to be used for the subscription to the
> "device" profile?
>  

I have done a 180 degree turn on my opinion on this. I have become a fan of
UUID. It mixes the best of MAC and RANDID. It works for softphones and
hardphones (whatever those are :-) I don't really believe UUID works better
than RANID but I have become convinced that there are a large group of
people that disagree with me and that we can all agree on UUID.

The UA should create the ID.

The UA should store the ID.

Though we could specify a ton of things and say use any of them, I see no
reason why any of the alternatives are better than UUID (other than for some
esoteric IETF process reasons) so I would be happier to see just one thing
implemented.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Sun, 24 Oct 2004 17:01:44 -0700 (PDT)

Perhaps I am missing a requirement or a discussion
thread on the list.  Can someone point to the reason
this is anything other than an implementation
decision?

Why is this a standards issue?  It seems to me the
only requirement is that it be unique.  Who cares 
how we get there?

--- Cullen Jennings <[email-masked]> wrote:

> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Oct 2004 18:57:07 -0400

> only requirement is that it be unique.  Who cares 

At one level I agree that it doesn't really matter as long as it is 
unique. To guarantee uniqueness, you must say *something* about the 
format. About the minimum you can say is that it is a URI, or a URN.

There is a pragmatic issue of how you compare these things to determine 
if they indeed are unique. Each URI/URN scheme has its own comparison 
rules. So in principle you can't compare two of them if you don't 
understand the format.

I doubt this is a practical problem. Byte-for-byte comparison when you 
don't know any better will probably produce decent results.

	Paul

>>>   First issue - What is the format of the
>>
>>instance-ID?
>>
>>>We would like a standardized instance-ID for all
>>
>>UA. Jennings draft suggests
>>
>>>the format "RANID-" followed by a 16 digit
>>
>>representation of a random 64 bit
>>
>>>number. Couldn't this number be associated with
>>
>>the local domain to obtain a
>>
>>>unique URI identifying the UA instance to be used
>>
>>for the subscription to the
>>
>>>"device" profile?
>>> 
>>

---

From: Dan Petrie <[email-masked]>
Date: Sun, 24 Oct 2004 16:57:30 -0700 (PDT)