Subject: AW: [Simple] Pres Data Model Open Issue #3, UUID URN or something else

From: Boehmer Bernhard ICM Berlin <[email-masked]>
Date: Thu, 28 Oct 2004 16:32:06 +0200

Hi,
does exist already an outcome of this discussion thread?
The last message I saw indicated the need to have the 
generation of a device ID in the OS. This mid- to longterm.
To start with, couldn't
we mandate in RPID that a unique persistent (temporally stable) device id
must be used and it would be up to the device to ensure that?
Or can we do more to enforce a unique device ID than pointing 
to well-defined algorithm for the UUID URN?
		Thanks Bernhard

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]] 
> Gesendet: Samstag, 2. Oktober 2004 04:09
> An: Paul Kyzivat
> Cc: Simple WG
> Betreff: Re: [Simple] Pres Data Model Open Issue #3, UUID URN 
> or something else
> 
> 
> inline.
> 
> 
> Paul Kyzivat wrote:
> 
> > 
> > 
> > Jonathan Rosenberg wrote:
> > 
> >> inline.
> >>
> >> Paul Kyzivat wrote:
> >>
> >>
> >>>> I would propose approach (3). In particular, I think the 
> data model
> >>>>  should revert to being agnostic on the URN scheme, reference the
> >>>> UUID URN as one possibility, document its problems. We should
> >>>> develop a separate specification that defines guidelines for
> >>>> choosing the URN for various devices in order to get the
> >>>> correlation properties we want. I also think we should 
> take a stab
> >>>> at defining a few URN schemes that would be useful - MAC 
> and ESN in
> >>>> particular.
> >>>
> >>>
> >>>
> >>>
> >>> I think it does make sense to leave the particular choice 
> out of this
> >>>  document.
> >>>
> >>> I do think the problem with UUID can be dealt with in a couple of
> >>> ways:
> >>>
> >>> - for some kinds of "devices", like softphones and IM 
> clients, it is 
> >>> probably fine as-is. They can typically have multiple 
> instances per 
> >>> device, so they must construct and instance id and save it 
> >>> persistently as part of the instance configuration.
> >>
> >>
> >>
> >> I think softphones are PC-based devices are a candidate 
> where we want to
> >> be able to correlate service information with device 
> information learned
> >> from network elements like an 802.11 AP. Thus, I do think 
> this problem
> >> applies to things besides phones.
> > 
> > 
> > Yes, I guess you are right. I was still thinking of "instance id", 
> > rather than specifically "device id".
> > 
> >>> - for a dedicated device, like a phone, that can't or 
> doesn't want to
> >>>  use the above technique, a cannonical mac-based uuid can be 
> >>> constructed by using a fixed time (e.g. zero) along with the mac.
> >>
> >>
> >> I thought about that, but wasn't able to convince myself 
> that it was
> >> allowed in the UUID URN spec. Do you find words that allow 
> you to set
> >> the time to zero?
> > 
> > 
> > Well, it probably does require some mental gymnastics to 
> justify it. It 
> > is a matter of saying you are using the UUID generated with 
> this mac at 
> > "the beginning of time".
> > 
> > Would it work? yes.
> > 
> > Is it ideal? Probably not.
> > 
> > Is it a valid usage? Debatable.
> > 
> > Could we recommend it? I don't know.
> > 
> > Could we say "you might be able to find a creative way to 
> use this form 
> > of uuid"? Why not?
> 
> I think at this point the help of one of the authors of the 
> UUID draft 
> is needed. One issue is that, if someone develops a UUID 
> implementation, 
> it may have no way of allowing an app to set the time to 
> zero, since its 
> not really something one would think to do based on that spec 
> alone. I'd 
> hate for folks to be forced to write a UUID URN implementation from 
> scratch just because of this.
> 
> -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
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple