Subject: [Simple] SIP, SIMPLE and general context information

From: Egil Østhus <[email-masked]>
Date: Thu, 09 Jun 2005 15:29:26 +0200

Hi,

I'm looking into ways to distribute general context information, and 
have some questions connected to SIMPLE.

SIMPLE is used to transport presence information to a watcher. In the 
introduction of RFC 3856 it is argued why SIP Events is an appropriate 
way to distribute presence information. I agree in the arguments given 
in the RFC, but there are some details that still is not clear to me. 
Presence status is a special kind of the more general Context 
Information. What I'm uncertain about, is whether SIMPLE should be used 
for distribution of other kinds of context information as well? 
Arguments that support this approach is that it is convenient to have 
only one protocol taking care of distributing all sorts of context 
information (e.g. Temperature, Light level, geographical location and so 
on). Also, the arguements given why SIMPLE is a proper protocol for 
presence info distribution goes for many of the other kinds of context 
information. Technically speaking, it is not any problem using SIMPLE 
for this matter, what I belive is the problem is that this approach is 
in conflict with the "Guidelines for Authors of Extensions to the 
Session Initiation Protocol (SIP)" internet draft 
(http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-09.txt). 
Section 3.1 defines SIPs solution space, and I have a hard time 
convincing myself that distribution of general context information is 
within the solution space of SIP, in other words SIP is not an 
appropriate protocol. Then again, it seems kind of strange to me to 
define one protocol per each kind of context information type. (e.g. one 
for geographical location, one for temperature and so on). Should SIP 
Events (like SIMPLE)  be used to distribute all kinds of context 
information (i.e. breaking the sip guidelines draft)? Should presence be 
distributed by SIMPLE, and other kinds of context information 
distributed by other protocols, i.e. creating a great number of context 
distribution protocols? Or should a general protocol for context 
information be designed, taking care of all sorts of context 
information, i.e.dropping SIMPLE?

Any comments helping to clarify this matter is highly appreciated!

Cheers,
Egil C. Østhus

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 9 Jun 2005 16:11:58 +0200

Egil,

RFC 3856 is an event package built from the SIP Event Notification  
Framework (RFC3265). Please take a look at that RFC and see if it  
suites your needs. Note that this framework is not SIMPLE specific, it  
is a SIP extension.

Regards,
Hisham

On Jun 9, 2005, at 3:29 PM, Egil Østhus wrote:

> Information. What I'm uncertain about, is whether SIMPLE should be  
> used for distribution of other kinds of context information as well?  
> information (e.g. Temperature, Light level, geographical location and  
> so on). Also, the arguements given why SIMPLE is a proper protocol for  
> (http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines 
> -09.txt). Section 3.1 defines SIPs solution space, and I have a hard  
> time convincing myself that distribution of general context  
> information is within the solution space of SIP, in other words SIP is  
> not an appropriate protocol. Then again, it seems kind of strange to  
> me to define one protocol per each kind of context information type.  
> (e.g. one for geographical location, one for temperature and so on).  
> Should SIP Events (like SIMPLE)  be used to distribute all kinds of  
> context information (i.e. breaking the sip guidelines draft)? Should  
> presence be distributed by SIMPLE, and other kinds of context  
> information distributed by other protocols, i.e. creating a great  
> number of context distribution protocols? Or should a general protocol  
> for context information be designed, taking care of all sorts of  
> context information, i.e.dropping SIMPLE?
>

---

From: Egil Østhus <[email-masked]>
Date: Thu, 09 Jun 2005 16:29:28 +0200

Hi,

I'm aware that SIMPLE is build upon the SIP Event Notification Framework 
(RFC3265). I still belive that my arguments apply though, but I realize 
that my questions partly is related to SIP itself, as well as SIMPLE.

Cheers
Egil

Hisham Khartabil wrote:

> suites your needs. Note that this framework is not SIMPLE specific, 
> it  is a SIP extension.
>
> Regards,
> Hisham
>
>> SIMPLE is used to transport presence information to a watcher. In 
>> the  introduction of RFC 3856 it is argued why SIP Events is an 
>> appropriate  way to distribute presence information. I agree in the 
>> arguments given  in the RFC, but there are some details that still is 
>> not clear to me.  Presence status is a special kind of the more 
>> general Context  Information. What I'm uncertain about, is whether 
>> SIMPLE should be  used for distribution of other kinds of context 
>> information as well?  Arguments that support this approach is that it 
>> is convenient to have  only one protocol taking care of distributing 
>> all sorts of context  information (e.g. Temperature, Light level, 
>> geographical location and  so on). Also, the arguements given why 
>> SIMPLE is a proper protocol for  presence info distribution goes for 
>> many of the other kinds of context  information. Technically 
>> speaking, it is not any problem using SIMPLE  for this matter, what I 
>> belive is the problem is that this approach is  in conflict with the 
>> "Guidelines for Authors of Extensions to the  Session Initiation 
>> Protocol (SIP)" internet draft  
>> information is within the solution space of SIP, in other words SIP 
>> is  not an appropriate protocol. Then again, it seems kind of strange 
>> to  me to define one protocol per each kind of context information 
>> type.  (e.g. one for geographical location, one for temperature and 
>> so on).  Should SIP Events (like SIMPLE)  be used to distribute all 
>> kinds of  context information (i.e. breaking the sip guidelines 
>> draft)? Should  presence be distributed by SIMPLE, and other kinds of 
>> context  information distributed by other protocols, i.e. creating a 
>> great  number of context distribution protocols? Or should a general 
>> protocol  for context information be designed, taking care of all 
>> sorts of  context information, i.e.dropping SIMPLE?
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Jun 2005 12:57:14 -0400

Egil,

I am not sure what you mean by "general context information". Your 
question is essentially one of whether this information you are 
interested in is suitable for inclusion in a PIDF document, presumably 
using some extension TBD.

That is a somewhat subjective decision. The first criterion is whether 
the information pertains to a *presentity*. Perhaps temperature would 
qualify, it it is temperature of a presentity, but probably not if it is 
the temperature of a swimming pool. If you try to claim the swimming 
pool is itself a presentity then I think you have surely gone too far.

	Paul

---

From: Egil Østhus <[email-masked]>
Date: Thu, 09 Jun 2005 20:20:57 +0200

> using some extension TBD.

Yes.

> qualify, it it is temperature of a presentity, but probably not if it 
> is the temperature of a swimming pool. If you try to claim the 
> swimming pool is itself a presentity then I think you have surely gone 
> too far.
>
>    

Certainly, I do not claim that a swimming pool is a presentity. 
Temperature was just an example from the top of my head. Still, I can 
imagine that quite a few context aware applications could benefint from 
knowing the user's temperature, e.g. within medical applications. How to 
transfer this information "the most clever way", is still a bit unclear 
to me, but I starting to suspect that one general context delivery 
protocol might be a bit ambitious. It might be more clever to define 
several application specific context distribution protocols.

Cheers,
Egil

---

From: Dean Willis <[email-masked]>
Date: Fri, 10 Jun 2005 12:40:22 -0500

> swimming pool is itself a presentity then I think you have surely gone 

Robots have presence too, you human-chauvinist!

Seriously. I'll climb way out on a limb here.

People, machines, and anything else that is potentially instrumented 
exhibit changes in state that influence the way other 
entities/objects/systems interact with them. This "state" may include 
levels of business/idleness, location, general demeanor or condition, 
and many other aspects.

The presence model provides a useful framework for encoding, 
distributing, and controlling access to this information in many cases.

For example, I wouldn't mind having location and some physiological 
information for my dog Zena showing up in my presence/IM client. Things 
like "In living room, sleeping" or "In yard, sleeping", or "In food 
bowl, sleeping" would be nice to know. Putting them into the framework 
of the presence application by which I currently know that my friend 
Vaugh is on-line but hasn't played with his computer in the last two 
hours and ten minutes would be useful.

I also wouldn't mind instrumenting a few more things. For example, 
being the obsessive-compulsive but absent-minded sort that I am, I can 
never remember whether I remember to close the garage door, and this 
worries me. I'd be tickled to be able to look at my presence client and 
see "Garage Door: Closed".

And I can't operate my VCR correctly, so it would be nice to look at my 
buddy list at 7:30 and see that my VCR is in fact recording the 
teletubbies show, so I won't have to wonder if I set it wrong (I'll 
KNOW it's wrong!).

Sure, some of this could be done via SNMP, if I had a way to get SNMP 
through all the firewalls involved, collate the data, and display it in 
a useful way in an application. But once we've done that, we've 
invented presence-over-SNMP, which wasn't a design goal.

"SIP for light bulbs" was greatly reviled. After all, who really wants 
to talk to light bulbs, and if they do, why would they need SIP when 
light-bulb-telepathy makes just as much sense? But "SIMPLE for light 
bulbs" might actually be relevant.

--
Dean