RE: [Simple] Updated RPID

[hisham.khartabil at nokia.com]

> -----Original Message-----
> From: simple-bounces at ietf.org 
> [mailto:simple-bounces at ietf.org]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 11.October.2004 23:11
> To: Henning Schulzrinne
> Cc: simple at ietf.org; Dag Ekengren
> Subject: Re: [Simple] Updated RPID
> 
> 
> 
> 
> Henning Schulzrinne wrote:
> 
> > My concern is that losing source information is not desirable, as it
> >  makes it rather difficult for any downstream entity to decide which
> >  information might be more credible.
> 
> We discussed this extensively on the design team.
> 
> It was concluded that we could support the reporting of conflicting
> information downstream, in later extensions, by inclusion of multipel
> values for a particular element along with its source. That meant that
> the baseline mode of operation was kept simple. Given the confusion
> we've had all along about interpretation of data in multiple 
> places, the
> tradeoff seemed appropriate.
> 
> I, for one, strongly support this decision. I think, prior to 
> the model,
> we were on a path to failure. We clearly had a lack of agreement or
> understanding on what these attributes meant and what they 
> were saying.
> No small part of that was that any data could appear anywhere. I am
> reluctant to return to that. I think that consistent and coherent
> information should be the baseline mode of operation, with conflicting
> data and source information being an extension, something we 
> can do later.
> 
> To be concise, Dan wrote:
> > So in the presence model draft, the cell phone service would report
> > that you are driving using the <person> tuple, and the PDA would
> > report that you are in a meeting also using the <person> tuple.
> > 
> > This would be the case because the information applies to 
> the person 
> > (although it is reported by various services). It is then up to the 
> > composition policy to decide which information should be displayed.
> > It could merge the information so that potentially conflicting
> > information is displayed to the watcher if that is the composition
> > policy in use.
> 
> Correct up to the last sentence - as above, we are not supporting, in
> this current version, the ability to indicate conflicting data.

I agree. There is no logical way of determining which presence info overrides the other. What if I am actually in a meeting but it just happened that I forgot my mobile phone in the car.

We cannot avoid those conflicts. Conflict avoidance, at this point in time, can be left as an exercise to the user of the presence service.

Indeed if a vendor chooses to implement such conflict resolution in its product, it can, but its gonna have to be a proprietory solution as there is no way we can standardise such conflict resolution now in the timeframe that we have.

Thanks,
Hisham

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple