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]