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]