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

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