RE: Let's fix THE PROBLEM

Hi,

I don't see why SIP wouldn't be excatly the generic PubSub protocol that people are talking about in this thread. RFC 3265 defines a generic SIP SUBSCRIBE-NOTIFY framework not specific to presence related notifications only. On the publishing side SIP PUBLISH (http://www.ietf.org/internet-drafts/draft-ietf-simple-publish-01.txt) is trying to achive the same, i.e. not being defined for just presence. Even the authorization policy management through XCAP can be applied to any type of event and content.

I agree taht draft-rosenberg-peterson-simple-pidf-phone-00.txt is overloading presence, but it can be defined as a separate event package as well.

Don't know enough about XMPP, but I suspect it has similar layering properties. 

So, I don't think the problem is that there wouldn't be generic enough PubSub protocols available for the Internet, even defined by the IETF. There are probably even too many... 

Markus

> -----Original Message-----
> From: ext Bob Wyman [mailto:[email protected]]
> Sent: 17 July, 2003 21:02
> To: 'Bob Wyman'; 'Shane Dempsey'; 'Rob Batchelder'; [email protected]
> Subject: RE: Let's fix THE PROBLEM
> 
> 
> 	Yesterday, I wrote that I was concerned that the Presence
> protocols would soon be overloaded by carrying information that has
> little to do with "presence" per se. I think a good example of this
> overloading can be found in the current ID:
> draft-rosenberg-peterson-simple-pidf-phone-00.txt which defines
> extensions to PIDF for phones. The draft proposes that presence
> information should include elements such as those describing the state
> of a phone rather than the phones' simple availablity or 
> "presence". For
> instance, it supports telling you that a phone is ringing, in the
> process of making a connection, roaming, which radio access 
> network the
> phone is connected to, who the phone's network provider is, 
> etc. This is
> not "Presence" data. It is status and configuration information. 
> 	In an ideal world, we would have a PubSub protocol that allowed
> users to subscribe to, publish, and watch either "presence" 
> information
> or "phone status and configuration" information as well as many other
> kinds of information. We should not be extending "Presence" to take on
> such a broad meaning that it becomes a meaningless tag which only
> vaguely refers to data which is published and subscribed to.
> 	A key rule of thumb when doing design is that when the
> boundaries of components start to become difficult to define, then you
> have probably discovered that the component should be decomposed into
> its elements. When we see people trying to push non-Presence data
> through the Presence slot, we should recognize that the 
> component needs
> decomposition.
> 
> 		bob wyman
> 
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 
> 
> 



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