Subject: RE: [Simple] Invisible and RPIDS

From: Cnaan Oded <[email-masked]>
Date: Thu, 6 Feb 2003 11:00:44 +0200

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> 
> 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.
> -- 

As far as I understand, tuples may represent any object (e.g., device,
service etc.) as long as they are consistent and that there is an agreement
between the PS and the watcher what these tuples represent.

It seems to me that there are clear use cases for having tuples represent
objects other than devices. Following Jonathan's example of an IM app,
consider a case where a certain user is registered to 2 services, IM and
Gaming, and assuming, for sake of the example, that these services are not
interconnected. An IM app may want to receive only the 'IM Service" tuple
that it has been publishing as this is the only information relevant for its
users. Gaming information is not relevant for the IM app as it does not
populate this information to the watchers.

Note that composing a document in a 'service-view' means that the
information is arranged in a different order and that attributes not
relevant to that service are left out. For example, an "IM-service" tuple
may include the devices, from which the user is connected to the IM, their
capabilities, the status and so on.

The question is how should watchers know what kind of object tuples
represent in the document they receive from the PS. You can also argue that
the watcher should be able to request the PS to compose the document using a
given representation scheme. It seems that currently there are no mechanisms
in SIMPLE for doing that.

Oded C.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 6 Feb 2003 09:45:11 -0500

Can you explain why invisible is the desired state?
Is it really only used because the current presence systems
don't have a rich way to make watcher-dependent presence?
Would the actual requirement be that for some watchers you
are open, and for others you are closed?

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'm a little confused by:
> presence server. Thus, the "IM states" might be:
> 
>    open for messages
>    open for high priority only
>    invisible
>    text-only
My confusion is that "invisible" is your state, "open for messages" 
is in conflict with "invisible".  What I think you mean is that you are
differentiating between state published by a presentity to the PS,
from the state a watcher obtains from the PS, and you are trying
to include in the presentity-to-PS exchange, instructions for how
it should interpret invisible.  I think that's a slippery slope
we don't want to go down at the moment - how the principal creates
rulesets for the PS.  

Brian
> Sent: Thursday, February 06, 2003 1:05 AM
> To: [email-masked]
> Subject: [Simple] Invisible and RPIDS
> 
> 
> 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.
> 
> tuple can 
> represent an application, as opposed to a device or media type. The 
> 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
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Feb 2003 10:23:57 -0500

I really think heads us in the wrong direction.
I believe that what your presence state is, and how that 
influences your call behavior could be arbitrarily complex, 
and that it's not something the user makes up on the fly 
- it's a script of some kind (or some GUI that creates the 
same effect however mechanized).

It's not appropriate to send how you want your calls handled
from presentity to PS.  You send your actual state, and your
script/UI/whatever ruleset determines how that should affect
a call, as well as how your state is represented to a given
watcher.  We might need more expressiveness in what your state is,
but we don't need any expressiveness in how calls should
be handled as a result of that state.

If your state is "busy", and you when you are "busy" you
want all but high priority IMs to be refused, that's a
fine ruleset.  If we need to have lots of nuance on "busy",
or we need to have a way to select one ruleset from a collection
of them, fine, but let's not try to make the presentity-to-ps
interface the point at which you describe how you want your
incoming proxy to handle calls.

That's pretty close to Jonathan's #1.  

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, February 07, 2003 9:33 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Simple] Invisible and RPIDS
> 
> 
> > 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.
> 
> 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.
> 
> > 
> > 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: "Brian Stucker" <[email-masked]>
Date: Fri, 7 Feb 2003 09:35:50 -0600

I'd agree with Brian. Otherwise, we're going to be uploading
scripts with our presence state and the interface will just
grow and grow and grow.

Brian

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, February 07, 2003 9:24 AM
To: 'Henning Schulzrinne'; Jonathan Rosenberg
Cc: [email-masked]
Subject: RE: [Simple] Invisible and RPIDS

Brian

---

From: Cnaan Oded <[email-masked]>
Date: Sun, 9 Feb 2003 09:15:45 +0200

Jonathan, the question is where do we put the line between the IM and the
Presence applications. In the scenario you've described below, the Presence
application also takes care of message routing logics where it seems to me
that this should be left to the messaging application. 

IMO, PSs should not accommodate for all the special features and logics
required by enabling applications as we'll never be able to satisfy all
applications. A PS needs to manage and maintain only pure Presence data and
leave applications to handle their internal logics. For example, let's say
that we have also a PTT app. What does 'Invisible' mean now regarding
messaging? Should urgent PTTs be allowed as well?

As long as PSs do not allow setting different Presence state to each
watcher, it seems that the INVISIBLE state is not very useful as the user
will be seen as CLOSED to all his watchers so they will not (instant)
communicate him. To implement this mode, an IM app may have a transformation
policy that an OPEN/BUSY state should be sent to the PS as CLOSED. In any
case, the message should be directed to the IM app that can push it to the
user instead of storing it for later use.
 
Oded Cnaan

> Sent: Friday, February 07, 2003 7:31 AM
> To: Henning Schulzrinne
> Cc: [email-masked]
> Henning Schulzrinne wrote:
> >>> 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. 
> >>
> >>
> >>
> >> 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).
> > 
> > 
> > Why create an application-specific solution when a generic 
> solution works?
> 
> What is the generic solution?
> 
> > 
> >>
> >>> (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'.)
> >>
> >>
> >>
> >> 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.
> > 
> > 
> > Why? Why can't my IM app be part of the same policy transformation 
> > 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 
> or something like that. Then, set a transformation policy which sets 
> 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.
> 
> want to mandate those application behaviors. However, the question is