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

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.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Thursday, September 12, 2002 2:32 AM
> To: [email protected]; [email protected];
> [email protected]; [email protected]
> Cc: [email protected]
> Subject: RE: Communication means in draft-ietf-impp-cpim-pidf-05
> 
> 
> Hi,
> 
> Based on this discussion I have understood that PIDF is not 
> nearly enough as a specification for an interoperable 
> presence format in any real system using e.g. SIMPLE. There 
> is a need for an additional specification how the tuples are 
> used and interpreted for _each_ application domain. For 
> instance if the ordering of tuples should mean something for 
> some application, that must be stated somewhere, so that all 
> implementors do it the same way (garage doors or whatever).
> 
> My question is that what is the process for creating concrete 
> "profiles" for PIDF for some particular use. My guess is that 
> strangely there is none. Is that going to require standards 
> track RFCs, Informational RFCs, or proprietary 
> interpretations that become de facto. If SIMPLE will do 
> something, how is the interoperability between different 
> systems ensured? Is IMPP going to continue doing this? I find 
> this situation and the usefulness of PIDF quite confusing, if 
> no more accuracy is added to the specs.
> 
> Markus
> 
> > -----Original Message-----
> > From: ext Peterson, Jon [mailto:[email protected]]
> > Sent: 11 September, 2002 22:23
> > To: 'Mark Day'; Khartabil Hisham (NMP/Helsinki); [email protected]
> > Cc: [email protected]
> > Subject: RE: Communication means in draft-ietf-impp-cpim-pidf-05
> > 
> > 
> > 
> > Some notes on this below.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > -----Original Message-----
> > > From: Mark Day [mailto:[email protected]]
> > > Sent: Sunday, September 08, 2002 2:27 AM
> > > To: Peterson, Jon; [email protected]; [email protected]
> > > Cc: [email protected]
> > > Subject: RE: Communication means in draft-ietf-impp-cpim-pidf-05
> > > 
> > > 
> > > Tuples were simply intended to be general enough to cover 
> > all the cases of
> > > presence systems that had been identified. Remember that 
> > the original goal
> > > of 2778 was to be able to map consistent terms onto each 
> > presence system,
> > > not to serve as a basis for interoperability. 
> > 
> > Yes - the consensus behind tuples was not forged in an 
> > environment that
> > assumed differing but interoperable protocols that would use 
> > the presence
> > information. For that reason, there was no need in RFC2778 to 
> > specify a
> > determinate way that tuples should be understood. However, if 
> > tuples are
> > going to be used in a multiprotocol environment, then without 
> > some common
> > understanding of how to interpret tuples interoperability 
> > will obviously be
> > limited.
> > 
> > > If I have a Honda and you have
> > > a Ford, we could probably successfully agree on which 
> parts of each
> > other's
> > > engine are a "spark plug", "oil filter", and so on without 
> > expecting that
> > we
> > > will then be able to swap parts.  At the point when 2778 
> > was written,
> > > discussions tended to fall apart because one person would 
> > use "spark plug"
> > > for what someone else called "oil filter." Part of reaching 
> > a point where
> > > everyone could nod and say, yes, 2778 covered *their* 
> > favorite system as
> > > well, was to allow for "bundling" of information in tuples.
> > > 
> > 
> > Yes, that is an apt analogy and I figured something like this 
> > was the case.
> > 
> > > 
> > > I think the relevant point for interoperability is that 
> > implementations
> > > should avoid assuming that another party splits 
> > presentities/tuples in the
> > > same way. 
> > 
> > All right, they can avoid assuming that, but what can they 
> > safely assume?
> > What should a watcher do with a PIDF body when they receive 
> it? If the
> > manner in which a PIDF body is created is essentially implementation
> > specific, then the prospects for interoperability are very 
> > low. I think we
> > need to have at least some baseline, some least common 
> > denominator, for
> > understanding PIDF.
> > 
> > > --Mark
> > > 
> > > 
> > > 
> > > 
> > >   [reminder: [email protected] for non-technical 
> > > discussions, please]
> > > 
> > 
> > 
> > 
> >   [reminder: [email protected] for non-technical 
> > discussions, please]
> > 
> > 
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 



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