Re: Let's fix THE PROBLEM

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

I absolutely agree with you. But then again, SIP is a signalling protocol
and it stays true to its nature - which is not IM.

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

I would say "decoupling" rather than decomposition, but I absolutely agree.
Mind you, SIP is a session-establishment protocol with many more options and
frills than TCP (sometimes I think the authors wanted to write a
better-than-TCP session protocol that could do much more than just
telephony, and forgot the KISS rule) in setting up sessions (over any
transport protocol), provide negotiation of capabilities (do you have an
apple ? So do I!) and so on. It is *much* more than just a signalling sistem
in its capabilities, despite the fact that telephony signalling is the only
thing it is used for.

Now, because SIP was designed with the ability to reach (overreach?) many
more fields than its own home turf, the result is that it has everything and
the kitchen sink in it. Do not be surprised if they are doing the same with
presence. I would not be surprised if someday it turned out that they have
SIP extensions for provisioning services (want an apple ? we can sell you
one) or doing all sorts of non-presence things over the presence channel.

Sip is an Uber-protocol and the way it is designed reflects its telephony
influences. The elegance of being a simple solution to a limited problem
scope is completely alien to it. SIP is designed so that it can do
*anything* and *more*. Result? it is easier to write a TCP stack than a SIP
one -- which is quite funny, given that TCP is the "complicated" thing of
the IP world. So yes, SIP is simpler than an ITU standard, but it is
overkill in its willingness to be able to do anything. Flexibility I love
(and in places where SIP ironically lacks it) but SIP has too much of it
where it not useful -- it is a simple case of rampant featurism.

So a new SIP/* draft says that you can get presence states on whether the
telefon is ringing. Duh. soon you will get ss7 signalling over the presence
channel if that suits them.With all the respect that being able to handle
and design a mess (like C++, to use a non-networking example) brings to the
authors, I value more those FEW people who can define a problem's scope
well, handle it completely and flexibly and do so without having to tear
down a forest to print the resulting standard. SIP has too many features,
can do too many things that it will never be used for *and* has the whole
universe as scope for its problem. So don't be surprised if its authors can
stretch the scope of "presence" to include a toaster's ownen temperature.
After all, for them "IM is just another media type"  --which explains how mu
ch they understand the "presence" concept in the first place.

-FL




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