RE: Improving PIDF

I agree with Jon - we've discussed in the past why <status> should be
mandatory in a tuple. I don't see any reason for splitting the document.

Adrian.

On 02 December 2002 10:44, Peterson, Jon wrote:
> Well, the split of CPIM into IM & Presence documents was motivated, 
> from my perspective, by the fact that a domain could deploy a presence

> gateway without deploying an IM gateway, and that the IM & Presence 
> gateways in a given domain could actually operate on separate machines

> with no interdependencies.
> 
> However, I don't think this is how your proposed split operates. Most 
> significantly, your split does not merely separate presence from IM, 
> because status is not an IM-specific concept - a disposition towards 
> communication is intrinsic to the concept of presence. I am not eager 
> to accept a new definition of presence in which it expresses a form of

> disposition unrelated to communications at this stage in the game.
> 
> Saying that the <status> element should be separate from PIDF suggests

> that a minimal implementation of PIDF is useful without the <status> 
> element. However, it isn't at all clear to me what the semantics of a 
> <tuple> without <status> would be. This introduces an opportunity for 
> modularity - presumably that something other than <status> could be in

> a <tuple> - which remains unmotivated, and of which I am skeptical. 
> Can you help me out with this at all? What do you want to do with 
> status-free tuples? In any event, if support for the <status> element 
> in not mandatory-to-implement (as your draft appears to suggest), this

> separation will significantly diminish the chances for 
> interoperability.





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