Subject: RE: [Simple] Presence data model: <device-id> in <tuple>

From: [email-masked]
Date: Mon, 31 Jan 2005 14:52:52 -0800

Hi Walter,

> -----Original Message-----
> From: ext Goix Walter [mailto:[email-masked]]
> Sent: Sunday, January 30, 2005 4:41 AM
> To: Kiss Krisztian (Nokia-TP/SanDiego); [email-masked]
> Subject: RE: [Simple] Presence data model: <device-id> in <tuple>
> 
> 
> Krisztian,
> 
> The examples in the presence data model draft identify 
> <device-id> as an element under <tuple>, but that's probably 
> what you had in mind. 

Right.

> However, I don't clearly see the rationale for multiple 
> <device-id> within a single <tuple>. Multiple devices for the 
> same presentity may offer exactly the same service, but they 
> probably would need no <contact> element to get the ability 
> to be merged into a single <tuple> at the server. In that 
> case, if one device updates its <tuple> inserting a <contact> 
> element (max 1 in PIDF <tuple>), then both tuples will need 
> to be separated again. Same if another property of a single 
> device <tuple> is updated. I personally see more 
> complications than benefits allowing multiple <device-id> per 
> <tuple>. Is there a real requirement for such an optimization? 

Actually the intention of my previous e-mail was not to debate whether you can have multiple <device-id>s under <tuple> or not, (the current draft allows more than one at the moment, I think) but I agree with your analysis and would restrict the number of <device-id> elements to be one under <tuple>.
 
> I agree that no namespace nor schema is defined for this 
> extension. Maybe the following declaration could be used:
> 
>        <xs:element name="device-id" type="tns:anyURI" minOccurs="0"/>

Looks good.

Thanks,
Krisztian

> 
> Walter
> 
> -----Original Message-----
> From: [email-masked] on behalf of [email-masked]
> Sent: Fri 1/28/2005 10:54 AM
> To: [email-masked]
> Subject: [Simple] Presence data model: <device-id> in <tuple>
>  
> 
> draft-ietf-simple-presence-data-model-01 allows <tuple> to 
> include a <device-id> or a list of <device-id>s serving as 
> correlation identifier(s).
> 
> Section 5.1.2 contains schema definition for <device> 
> including <device-id>, i.e.:
> 
>       <xs:attribute name="device-id" type="xs:anyURI" use="required"/>
> 
> I would assume that if <device-id> appears under <tuple>, 
> another schema definition would be required, something like:
> 
>       <xs:attribute name="device-id" type="xs:anyURI"  
> minOccurs="0" maxOccurs="unbounded"/>
> 
> Should this <tuple> extension be added to the draft?
> 
> Thanks,
> Krisztian
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
> 
> 
> 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
> ====================================================================
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Jan 2005 18:27:41 -0500

> Actually the intention of my previous e-mail was not to debate whether you can have multiple <device-id>s under <tuple> or not, (the current draft allows more than one at the moment, I think) but I…

So, what should a compositor do if it gets multiple tuples, with 
different devices and contacts, but it decides to combine them into a 
single tuple with the AoR as the contact?

E.g. suppose there is a cell phone and a home phone, and they both have 
the same attributes. (Open, voice, ...)

It seems that you would require that either all devices be omitted, or 
else that one be picked. The device isn't terribly useful in this case, 
since you don't have any choice about what to call. But still it might 
be useful for deciding if you want to call.

	Paul