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

"Peterson, Jon" <[email protected]>
Newsgroups gmane.ietf.impp
Message-ID <[email protected]>
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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.