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

I think you're exactly right. We need some kind of default, fallback
understanding of segmented presence information, with an understanding that
particular presence protocols and/or applications may be able to have a more
sophisticated understanding of the same presence information. I think this
matches both the letter and spirit of RFC2779 3.1.4.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email protected]]
> Sent: Friday, September 13, 2002 1:07 PM
> To: Ben Campbell
> Cc: Peterson, Jon; '[email protected]'; [email protected];
> [email protected]; [email protected]; [email protected]
> Subject: 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]
> 



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