Subject: RE: [Simple] Composition and elements

From: [email-masked]
Date: Wed, 13 Oct 2004 11:22:56 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Henning Schulzrinne
> Sent: 13.October.2004 01:52
> To: Paul Kyzivat
> Cc: Simple WG
> Subject: Re: [Simple] Composition and elements

> 
> As an aside: There is a separate reason for that, having to 
> do with the 
> difficulty of defining a unique device identifier discussed earlier. 
> Once you remove the role as an XML element identifier, you could, for 
> example, have *several* (UUID) identifiers which each have 
> the property 
> that they uniquely define the device, but you might not be 
> able to agree 
> on which type of identifier to use in general.
> 
> This greatly increases the chance that a smart composer can recognize 
> that two device tuples actually refer to the same piece of hardware, 
> since one of their identifiers matches. (Trivial example: assume we 
> can't agree whether some hostid-based or MAC-based ID should be used 
> since this will differ for each device type. In my approach, 
> each device 
> publisher would include *all* the unique IDs it can get at, 
> increasing 
> the likelihood that one type will be in common.)

I suggested exactly the same thing in the design team meeting we ha in San Diego. We opted for the approach currently discussed in the data model draft. Can you explain why that doesn't work for you?

Thanks,
Hisham

> 
> This is obviously a separate discussion.
> 
> Henning
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Oct 2004 10:06:21 -0400

> I suggested exactly the same thing in the design team meeting we ha
> in San Diego. We opted for the approach currently discussed in the
> data model draft. Can you explain why that doesn't work for you?

Unfortunately, I wasn't able to be there, so I don't know what led to 
the rejection of your proposal. The current approach has the problem 
that Paul identified: two device elements published by different 
publishers on the same device *have to* have the same identifier. For 
some cases, it is easier if they can have separate identifiers.

In practice, I see far less potential for conflicting or uncertain 
information for devices than for persons, except as a system 
malfunction, so I think both approaches can work here.

Henning