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.

I agree that it is very useful for real interoperation of different presence 
protocols to give a sort of guidance on how PIDF components can be used.  
But, it is not clear to me that which kind of information should be in the 
PIDF specification document.  It might be needed to be in how tuples without 
<contact> should be used, or how tuples with <contact> would correspond 
to communication devices.  But, it seems very subtle how much should be
described.  

If it is the case it lead us into long discussion, I would suggest to complete 
the PIDF document first and publish such a guideline as a supplemental 
document. 

> 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. 

That would be helpful anyway unless it doesn't take too much time. 


-- Hiroyasu Sugano


> 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]
> 
> 




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