Subject: RE: [Simple] Moving the presence data model work forward

From: [email-masked]
Date: Fri, 7 Jan 2005 18:38:26 +0200

Robert,

I basically agree with your proposal, since as you say, it seems the only way to get things forward. 

I completely agree with the data model with respect to how the presence data is modeled as PERSON, SERVICE and DEVICE, and that a SERVICE is described as a tuple according to PIDF (and vice versa, a tuple always means a SERVICE). So please, let's go ahead with that part.

What has not been agreeable is the current draft was the use of a contact address to uniquely identify a tuple, and thus meaning that several tuples within the same presence document with a common contact address was not allowed. That tied the presence togeher with GRUUs, which in my opinion should not be mandated. There was a proposal to describe a dispatcher as a solution when there are multiple "services" using a single contact, but perhaps that was a step toward too much complexity.

So what we are losing at this point would be the explicit (standardized) override capability, to e.g. deal with false information coming from another source. While I considered that feature important, I think it might be best at this point to leave it out, and say that the _default_ composition algorithm is a simple union. We can define further, client-configurable, algorithms later on.

So, splitting the data model and letting all of the other stuff go forward is the best solution.

Regards,
	Markus 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Paul Kyzivat
> Sent: 07 January, 2005 15:49
> To: Robert Sparks
> Cc: [email-masked]
> Subject: Re: [Simple] Moving the presence data model work forward
> 
> 
> Robert - thanks! I am in agreement that this is the way forward.
> 
> 	Paul
> 
> Robert Sparks wrote:
> > We seem to have ground to a halt again on finishing
> > the Presence Data Model. This is blocking a very large
> > portion of the rest of our work.
> > 
> > The current sticking point is, at its core, about where
> > we are drawing the line for a baseline composition
> > algorithm.
> > 
> > We've looked several times at whether we would
> > try to provide a complete standardized composition
> > system, and have consistently come to the conclusion
> > that the task is vastly difficult. We've agreed to build
> > a minimal system that would not preclude work on
> > more complex standardized composition in the future.
> > 
> > We've achieved consensus around a using  simple
> > union as the baseline mechanism. Anything more
> > would be something done outside a standard. We
> > recognize that this means that different services may
> > do different things with the same inputs, but until we
> > have more deployment experience, doing much more
> > is a "boiling the ocean" class problem.
> > 
> > To hopefully avoid some of the problems that might arise
> > with that compromise, the Presence Data Model work
> > tried to add two important things:
> > 
> >  - It introduced a structure that made it more likely
> >    that elements creating presence documents would
> >    put information in consistent places. This reduces
> >    ambiguity and makes it more likely that the intent
> >    of the document will be rendered accurately across
> >    different implementations.
> > - It tried to take one more step towards a more complex
> >   composition policy by defining what identifies a service
> >   tuple, so that compositors would have a standard
> >   algorithm for choosing to combine information about
> >   the "same service" from different sources.
> > 
> > The effort was very successful on the first point. We have
> > not yet achieved consensus around the second. To reach
> > agreement, we will need either to back up to something
> > closer to our previous consensus point, or go further towards
> > a complete standard composition system.
> > 
> > In order to allow the document suite that is blocked
> > on this conversation to go forward, so that we can get
> > implementation and deployment experience, I believe
> > it will be necessary to step back:
> > 
> >  - We keep the representation model in the PDM work - <person/>
> >    and <device/> have been accepted as useful.
> > 
> >  - We maintain the notion that tuples with contacts are "services",
> >    but don't try to standardize what "same service" means at this
> >    time beyond the basic tools that PIDF gives us.
> > 
> >  - We break out discussion of a more complete standard composition
> >    system into a separate document -> AND TABLE IT <- until the
> >    current document suite is done.
> > 
> > This is a clearly a compromise position - it would be better
> > if we _could_ specify a more fleshed out composition mechanism,
> > but history indicates that this is not likely to happen. Lets get
> > this base mechanism out there so we can get some more
> > real-world data to help guide the later debate.
> > 
> > RjS
> > 
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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