Subject: [Simple] Invisible and RPIDS

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Feb 2003 01:04:43 -0500

I wanted to discuss an interesting feature of existing IM systems, so as 
to explore how it fits in our evolving presence/RPIDS work.

The feature is "invisible". On several systems, you can set your status 
to invisible. To all watchers, your status is offline, but they can 
still send you IM, and you will receive them. One can imagine other 
behaviors, where in invisible mode, I don't receive IM - they are 
archived, and I retrieve them when I return to visible mode.

The concept extends to voice too; one can imagine publishing invisible 
for a phone, which means watchers see it as CLOSED (using pidf 
terminology), but calls to it will actually still succeed.

I would argue that this is an example of a "transformational policy". 
That is, there is some PIDF status extension defined to represent 
invisible. However, there is also a presence policy that says this:

IF the watcher is "IM App"
   don't change anything
IF the watcher is anyone else
   remove all status but basic
   set basic to CLOSED

Its a transformational policy, because its not just restricting who sees 
what, its changing one of the statuses (basic) from OPEN to CLOSED 
depending on the watcher.

Note that I have also modeled the IM app as a watcher. Thats because the 
IM app will use the presence status to determine how to handle an IM 
sent to the user. Here, by IM app, I mean some kind of application 
server that receives IMs targeted to a user, and applies forwarding, 
retry, storage and blocking policies.

As far as pidf is concerned, one might generalize this as a "visibility" 
status which indicates various shades of visibility. "invisible" means 
that I wish for nothing to be revealed to watchers. "partly visible" 
might mean that only basic is revealed, and everything else is stripped.

Another way to view this is that a tuple can represent an application, 
such as an IM app, a chess game app, or something. There are specific 
statuses defined for each app, meant for the consumption of an 
application server in the network, but also visible to watchers, 
possibly after the application of a transformational policy at the 
presence server. Thus, the "IM states" might be:

   open for messages
   open for high priority only
   invisible
   text-only

These have a particular interpretation by an IM app server - they would 
be used to guide its blocking and archiving policy.

Note that we have not yet, afaik, discussed the notion that a tuple can 
represent an application, as opposed to a device or media type. The 
lines are blurry, no doubt....

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Feb 2003 09:09:51 -0500

I believe this can be done already in RPIDS. I could label certain 
states with keywords that are recognized by my policy script, which then 
transforms them into the appropriate tuples before delivery to watchers. 
(Or, the transformation could depend on the presence data itself, e.g., 
on time of day or other clues. For example, I could automatically 
declare myself selectively invisible when my <category> says 'meeting'.)

This doesn't seem fundamentally different from other selection or 
filtering requirements. Thus, I'm not sure we want to create a custom 
mechanism for this.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Feb 2003 10:32:50 -0500

> transforms them into the appropriate tuples before delivery to watchers. 

I am less worried about the transformations, as I am about the notion of 
certain presence states being designed specifically for interpretation 
by an application (IM in this case).

> declare myself selectively invisible when my <category> says 'meeting'.)

Right. As I said, the transformation part is just part of the policy, 
letting certain watchers see certain things, and others see different 
things. The issue really is that I have one watcher in particular, the 
IM app, for which I want it to do something very specific when my 
presence state has a particular value. This would seem to require some 
kind of standardization of states.

Brian writes:
> I do agree this is transformation state.  I think
> there is no need to actually standardize invisible;
> your presence state is closed to a watcher.  If your
> IM system still accepts messages, that's a local decision
> it makes.  

I think thats the big question. Existing systems area using presence to 
allow the presentity to CONTROL the behavior of the application by 
specifically setting the state. Thus, for the behavior to be predictable 
by the client, you would need to somehow standardize the states and the 
behavior they are supposed to imply.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Feb 2003 10:56:34 -0500

>> states with keywords that are recognized by my policy script, which 
>> then transforms them into the appropriate tuples before delivery to 
>> watchers. 
> 
> 

Why create an application-specific solution when a generic solution works?

> 
>> (Or, the transformation could depend on the presence data itself, 
>> e.g., on time of day or other clues. For example, I could 
>> automatically declare myself selectively invisible when my <category> 
>> says 'meeting'.)
> 
> 

Why? Why can't my IM app be part of the same policy transformation 
machinery that generates handling instructions for, say, SIP INVITEs?

> behavior they are supposed to imply.

Why can't this be done by each implementation, given that the details 
may differ significantly? We already have the ability to indicate, via 
callerprefs, "closed to IM" (maybe - that may require a discussion on 
the expressiveness of our current media types; I had raised this issue 
earlier) or "closed to MESSAGE".

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Feb 2003 00:31:13 -0500

Henning Schulzrinne wrote:
>> I am less worried about the transformations, as I am about the notion 
>> of certain presence states being designed specifically for 
>> interpretation by an application (IM in this case).
> 
> 

What is the generic solution?

> machinery that generates handling instructions for, say, SIP INVITEs?

I don't follow your analogy, but let me provide a specific case. Lets 
say I want to set my presence status to something which tells an IM app 
to block IMs to me except high priority ones. There are two approaches 
to that:

  1. set my basic presence status to OPEN, and set my activity to "busy" 
or something like that. Then, set a transformation policy which sets 
this to CLOSED for everyone but the IM app. The IM app is then 
configured to know that busy/OPEN means block all but high priority IM. 
Perhaps this is what you mean by the generic solution.

2. set my basic status to OPEN, set my activity to "busy", and also set 
my IM-app status to "block-all-but-high-priority". The same 
transformation policy sets this to CLOSED for everyone but the IM app. 
However, the IM app looks at the IM-app status which gives it an 
explicit directive. If we want these to be interoperable across 
clients/IM applications, they would need to be standardized.

The main issue with case 1 is that my client, on my providers IM app, 
may do the right thing, but if my client connects to a different 
provider with a different IM app, the IM app behavior might be different.

Now, that said, there are cases where an application does something on 
my behalf as a side-effect of a presence change. In those cases, I dont 
want to mandate those application behaviors. However, the question is 
whether people think there is a need to provide EXPLICIT directives to 
applications through presence.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Feb 2003 09:33:00 -0500

> clients/IM applications, they would need to be standardized.

Different solution: create a tuple that has the following properties:
<tuple>
basic status: open
priority: urgent
media: IM
category: busy
</tuple>
<tuple>
basic status: closed
priority: -
media: !IM
category: busy
</tuple>

Then, my proxy uses this to create a policy that says

"unless the IM is marked urgent, block; block all other SIP requests"

This seems pretty predictable; clearly, any of this relies on my IM 
service being aware of my presence.