Re: Communication means in draft-ietf-impp-cpim-pidf-05

I think it is a good thing if this can be defined in IMPP, but only if the result is good for SIMPLE. If the cost of doing it in IMPP is that we have to compromise away something important for SIMPLE, then I would rather give up the grand unification in favor of something that permits SIMPLE to work well.

For instance, an agreement that said each tuple must designate a different manner of human interaction (e.g. voice, IM, video) would IMHO be a bad outcome for SIMPLE.

Perhaps a fallback position would be to define a common core interpretation that is acceptable to everyone, and extension profiles that can be used if understood.

	Paul

Ben Campbell wrote:
> 
> It is my opinion that this should be defined in IMPP, if we expect to
> have more than rudimentary interop between protocols. I have no opinion
> as to whether that belongs in the pdif doc or somewhere else.
> 
> Peterson, Jon wrote:
> > I agree that the intention behind RFC2778 was apparently that the (One True)
> > presence protocol would eventually define how tuples should be used and
> > interpreted. Now that we have inherited the requirements of CPIM and its
> > consequent multi-protocol environment, we are faced with a decision - should
> > that definition occur in CPIM or in the presence protocols that use CPIM?
> > And what are the prospects for interoperability if we select the latter?
> >
> > Although in my notes on the subject I have been asking questions more than
> > arguing for any particular interpretation, this isn't because I think this
> > is tough issue to settle - there are attractive and simple ways to interpret
> > tuples. I just want to ascertain whether or not there is consensus to define
> > something in CPIM, or if people feel this can be deferred to presence
> > protocols that use CPIM. My preference at the moment is to provide some
> > guidance in the PIDF document on the interpretation of tuples.
> >
> > If necessary, I imagine that SIMPLE would define its own understanding of
> > tuples, but to my knowledge it has not done so in its current deliverables.
> >
> > Jon Peterson
> > NeuStar, Inc.



  [reminder: [email protected] for non-technical discussions, please]