Subject: RE: [Simple] Extending <status> for presence

From: [email-masked]
Date: Thu, 16 Jan 2003 10:40:50 +0200

If a tuple is representing a device, the OPEN and CLOSED means that the device is available for communication (to the extent that I could tell if the device is turned on or it is off). The list of elements that follow tells you which communication means are available and which are not:

Using draft-lonnfors-simple-prescaps-ext-00.txt. It is:

<tuple id="aak988">
   <basic>OPEN</basic>
   <callerprefs-stuff>voice not allowed except high
    priority</>
   <ext:prescaps>
      <ext:feature name="message">
         <ext:value>false</ext:value>
      </ext:feature>
      <ext:feature name="audio">
         <ext:value>true</ext:value>
      </ext:feature>
      <ext:feature name="application">
         <ext:value>true</ext:value>
      </ext:feature>
    </ext:prescaps>
</tuple>

Active/Inactive could mean that even though my device is open, I, as a presentity, am inactive on that device. Where did those active/inactive come from? What was the original need for them?

Regards,
Hisham

> -----Original Message-----
> From: ext Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Wednesday, January 15, 2003 7:08 PM
> To: Paul Kyzivat
> Cc: Jonathan Rosenberg; Henning Schulzrinne; [email-masked]
> Subject: Re: [Simple] Extending <status> for presence
> 
> 
> The more I think through these discussions, the more convinced I get
> that we ought to maintain the presence state of the presentity
> itself distinct from that of any of the devices that can be used to
> communicate with it.  The only first class citizen in the presence
> domain is the presentity itself; without it, all the devices 
> associated
> with it are useless.  My interpretation of rfc2778 yields an implicit
> coupling between presence and IM; the former is used to drive the
> latter.  It has been argued that presence needs to be grounded in a
> purpose in order to scope it.  But the discussions so far appear to
> point that the state of a presentity is far richer then the
> individual state of the devices it commands.
> 
> I think we are doing the same thing in simple -- letting the various
> devices dictate presence/absence of the entity.  Thus we have states
> which are interpreted by different applications in different ways; for
> example, being "out to lunch" and having a basic status of CLOSED is
> equally valid, as is "being out to lunch" and having a basic status of
> OPEN.
> 
> On the other hand, if we posit that "being out to lunch" is a status
> associated with the presentity itself, then the basic status is always
> OPEN.  The next thing to do is to see if the presentity can accept any
> communication sessions while in this state.  That is easy -- 
> go through
> the devices and see which ones are OPEN or CLOSED or have q values or
> priorities associated with them.
> 
> I don't think we have lost any flexibility here, as far as I 
> can see it.
> 
> Paul Kyzivat wrote:
>  > The orthogonality also means that Do Not Disturb shouldn't 
> be enforced
>  > (at least not vigorously) by the UAC. In general it should 
> be up to me
>  > to decide if I want to violate your wishes. If you want it 
> enforced,
>  > you  can couple it with CLOSED.
> 
> If we do NOT infer the state of the presentity from its devices, "Do
> not Disturb" is easily enforcable.  The state of the presentity itself
> is OPEN, but that of all of its devices is CLOSED.  I think that if
> we provide a "Do Not Disturb", it should be enforced.  Otherwise, as
> has been pointed out before, others will learn to distrust 
> ones presence
> status.
> 
> Paul Kyzivat further writes:
> > - I see one status type with values of {ACTIVE, INACTIVE} that is 
> > typically inferred by observing behavio
> > - Another status type is explicitly set, with values of {AVAILABLE, 
> > DO-NOT-DISTURB, AWAY}. This can also carry an estimate of 
> when it is 
> > expected to change.
> 
> All these status values -- ACTIVE, INACTIVE, DO-NOT-DISTURB, AWAY --
> refer to the state of the presentity itself; and furthermore, I will
> go out on a limb and say that these correspond to OPEN.  If 
> this is the
> case, why not actually provide means for this in simple (as in the
> WG) extensions to PIDF?
> 
> Cheers,
> 
> - vijay
> -- 
> Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
> Wireless Networks Group/Internet Software and Services
> Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
> Naperville, Illinois 60566     Voice: +1 630 224 0216
> 
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jan 2003 16:10:19 -0500

Hisham,

I'm not sure who you were addressing, but I will assume it was me.

I didn't originally factor active/inactive into my view, but have been 
convinced that it is distinct and relevant.

Most of the popular IM systems have this in one form or another. It is 
typically used to deal with the case where you are online and present 
for IM, but then wander away from your system without doing anything to 
change your presence. In this case, the IM client on your system notices 
that you seem inactive - often by monitoring your use of the mouse or 
keyboard - and changes your presence status. It may then also change its 
own behavior - perhaps sending an automatic reply to incoming messages.

In general this is tied to a device. If you do IM on your pc but get 
phone calls on your cell phone, then the fact that you became inactive 
on your pc doesn't imply anything about your status relative to your 
cell phone.

	Paul