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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 10 Jan 2003 13:18:44 -0500

Jonathan

Suppose your voicemail greeting depended on your presence status?
Out-to-lunch might then be quite useful.

I actually don't think this particular example is great, but I do
think that there is a use for "On Vacation" vs. "Out of Office".
Here, I would forward (at least some) calls to a cellphone for
the latter, but not the former.  Fine grained presence state is
very useful.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, January 10, 2003 12:42 PM
> To: Paul Kyzivat
> Cc: Vijay K. Gurbani; [email-masked]
> Subject: Re: [Simple] Extending <status> for presence
> 
> 
> 
> 
> Paul Kyzivat wrote:
> 
> > I can tell you right off that one thing I *don't* intend to 
> do is define 
> > xml status values like <out-to-lunch>.
> 
> Some more about this. We've had extensive discussions for 
> quite a while 
> on this. The general conclusion, I think, is that things like "out to 
> lunch" are best done by a note which is consumed by a person. 
> You only 
> need new status types if they are consumed by an automata. 
> Its not clear 
> to anyone that an automata would ever need to know that you 
> are out to 
> lunch, as opposed to simply not available, where CLOSED would suffice.
> 
> One potential usage for these statuses is the display of an 
> icon on the 
> watcher's system. I am intimately familiar with Yahoo, which 
> today has 
> three icons. These indicate available, not-available, and idle. That 
> does beg the question if we need to have an idle status.
> 
> I suppose another way to handle icons is to send a URI as part of the 
> presence which poitns to the icon. However, I can imagine that you'd 
> want to render the icons differently on different devices; a 
> PC might be 
> ok with a 20x20 jpeg, but that is not going to fly on a 
> wireless phone, 
> which needs something smaller. In that case, sending a status with a 
> defined meaning, which each local watcher can map to a 
> device-appropriate icon, would make more sense.
> 
> So, would someone ever want to build a system with an "out-to-lunch" 
> icon? Possibly. Certainly not outside the realm of 
> possibility. Where to 
> draw the line is always the question...
> 
> -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
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 10 Jan 2003 13:27:19 -0500

> Out-to-lunch might then be quite useful.

Well, I could argue for TTS applied to the note, but clearly a set of 
known statuses would work better (you could have recorded audio for each 
of them rather than attempting TTS on arbitrary text). This is actually 
a pretty good example use case.

> the latter, but not the former.  Fine grained presence state is

I think this is a case where you don't really want "on vacation" or 
"out-of-office" per se, but some kind of more general purpose status 
with semantics that imply preferences for one type of communications 
device over another.

That leads to an interesting issue. Right now, statuses are always 
associated with a tuple. Here, I think we are talking about a status 
element that is truly applicable to the presentity, and not any one of 
their devices. You can't have presentity-level statuses in PIDF. We 
could designate a tuple as a "presentity tuple", I suppose, but you'd 
need some way to convay this fact (perhaps a pres contact address).

-Jonathan R.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 10 Jan 2003 12:40:33 -0600

Jonathan Rosenberg wrote:
[...]
> with semantics that imply preferences for one type of communications 

Often times, the need is not necessarily to establish a communication
channel, but just sense presence information.  For instance, it
suffices to know that my wife is out to lunch; I do not necessarily
want to talk to her.

> need some way to convay this fact (perhaps a pres contact address).

Or maybe have a tuple whose contact element URI is the same as the
entity parameter of the <presence> element.  Such a tuple pertains
to the presentity itself, rather than any of the devices used by
that presentity.

- 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Jan 2003 15:43:59 -0500

> a pretty good example use case.

If your really want to do this, then TTS seems like a good solution to 
me. Trying to define distinct status values for every interesting state 
that you might want to advertise seems like a slippery slope to a mess.

Given the definition of PIDF, there is nothing to stop anybody from 
doing this, but I certainly don't want to take the SIMPLE group there.

> with semantics that imply preferences for one type of communications 

My preferred path is similar. Namely to indicate which media I am 
willing to communicate with, and which I am not.

For instance, if you are on the phone you may be unavailable to accept 
voice calls, but available to accept IM. If these are different tuples 
it is easy. If they are part of the same tuple, because your sip device 
does both, then you need more nuanced status. The callerprefs stuff 
already handles this, at least to a degree.

If On Vacation means your office phone won't answer (or will only take 
messages), but you can be reached on your mobile phone, and those are 
represented by different tuples, that is easy to report.

If you choose to represent your office and mobile phones by the same 
tuple, then I'm not sure how you should represent your status. Maybe you 
should simply change your callerprefs "class" attribute to "personal".

> need some way to convay this fact (perhaps a pres contact address).

You only represent your presence with multiple tuples if you want to, or 
if they have incompatible means of communication. As long as we are 
talking about SIMPLE, all the devices can be registered with a single 
Address of Record and represented as a single tuple.

Nevertheless, I can see some value in having global status values that 
serve as defaults for all tuples. But doing that cleanly would require a 
change to PIDF. And it would probably complicate PUBLISH. Is it really 
such a burden to replicate a piece of status in multiple tuples, if that 
is what you mean?

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 11 Jan 2003 10:26:48 -0500

There seem to be two uses for fine-grained status:

- Informing the watchers so that they can adjust their behavior. This is 
not simply expressible by CPL, say, since the callee really has no good 
way of judging the importance of communications. Thus, for my department 
secretary, it is very helpful to know whether I'm in a grad student 
meeting, at lunch, in an oral exam (interruptible only under the most 
dire of circumstances), or in a committee meeting (I can easily duck out 
for a few minutes). I don't know whether I'd want that fine-grained a 
distinction, but why shouldn't I be allowed to do this, in a locally 
semantically meaningful way?

I'm sure that each specific domain has its own set of status indications 
that are meaningful within that domain. In a hospital, it might be 
useful to indicate "doing an operation" vs. "in an administrative 
meeting", etc.

- We've also proposed presence extensions to CPL that take status into 
account. Again, having enumerated values is much better than trying to 
do a regexp on a free-form text field.

Having explicitly enumerated status indications also allows a separation 
  of concerns. My CPL generator can subscribe to my presence and 
generate new CPL that fits the situation. That seems much easier and 
cleaner than having my UA try to update the CPL.

Also, the status provides an informal indication of the duration of 
unavailability. "Out to lunch" makes it likely that the user will return 
within an hour or so. "On vacation" has a very different implication.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 11 Jan 2003 10:31:38 -0500

In a previous incarnation of this discussion, a number of people 
gathered information on what status indications other systems have. I 
had collected this information at

http://www.cs.columbia.edu/sip/drafts/status.txt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 11 Jan 2003 22:42:06 -0500

inline.

Paul Kyzivat wrote:

>> known statuses would work better (you could have recorded audio for 
>> each of them rather than attempting TTS on arbitrary text). This is 
>> actually a pretty good example use case.
> 
> 

Just because the scope of a problem is large, does not mean that one 
cannot attack a small piece of it.

IMHO, the TTS version of this will simply not work suffiently well to be 
deployable. Internationalization issues, spelling issues, presence of 
other characters in the subject, etc.,etc. will make this insufficiently 
robust. As an example:

note="0n vactn. :)"

To a human, it is clear what this means. To a TTS engine its garbage.

> doing this, but I certainly don't want to take the SIMPLE group there.

I guess it really does come down to the scope of the work. As Henning 
pointed out, we don't want to define statuses for things that a hospital 
or a university alone will want. But that doesn't mean we should do 
nothing. If we can enable a set of statuses that is common in existing 
systems, as a start, I think that perhaps that is a worthwhile goal.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 11 Jan 2003 22:57:01 -0500

> or a university alone will want. But that doesn't mean we should do 

The point was that while me shouldn't ask doctors for their favorite 
list of pastimes and whereabouts, there is no reason (that I can see) 
that we should not allow domain-specific status sets, of the 
edu.columbia variety. There's no collision possibility, and it relieves 
pressure on IANA and avoids endless discussions as to who needs it. To 
amplify: I'm not so much concerned about Microsoft and Dynamicsoft 
adding software-specific status codes, but rather the ability of 
end-user affinity groups to do so. This seems no harder than adding MIME 
types.

The cell phone industry survives by selling ring tones; maybe they can 
stay out of Chapter 11 a bit longer by selling cute status icons and 
sounds :-)

> systems, as a start, I think that perhaps that is a worthwhile goal.

I agree. The harm of being inclusive is not obvious to me. Even the 
longest list of status items in existing systems is well short of a dozen.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 13 Jan 2003 12:00:01 -0600

> longest list of status items in existing systems is well short of a dozen.

Okay -- so taking this a little further and distilling the status codes
from Henning's list (http://www.cs.columbia.edu/sip/drafts/status.txt),
we arrive at the following:

    CLOSED
       Offline (invisible, lurking)

    OPEN
       Available
       Away (1)
       Busy-interrupt (2)
       Busy-no-interrupt (3)
       Busy-interrupt-authority (4)
       Custom

(1) "Be right back", "Extended away" can all be subsumed in "Away".
(2) "On the phone" can be subsumed here if the UA alternate comm-
     unication capablities (like IM).
(3) "Do not disturb" and other domain specific semantics that Henning
     hinted at (e.g. "surgeon in a surgery; cannot be disturbed")
     can be subsumed by this sub-status.
(4) Here is where other domain specific semantics that Henning
     mentioned can be subsumed; e.g. "professor in an oral; can be
     distrubed if the need is paramount".  Basically, only those with
     authority (i.e. a secretary) can interrupt the presentity.

Furthermore, I think that for "Busy-no-interrupt" and
"Busy-interrupt-with-authority", the specification has to provide
some guidance to the software designer.  The presentity's UA should
*not* even display IMs for the presentity if it in "Busy-no-interrupt"
mode.  Likewise, if the presentity's UA is in "Busy-interrupt-authority"
status, only those IMs from an authorized user (i.e. department
secretary, hospital administrator, etc.) should be displayed.

Comments?

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 13 Jan 2003 13:19:19 -0500

Based on your summary, there may well be two axes of presence 
information. One identifies my interruptibility ("busy-no-interrupt") or 
reachability ("away"), the other the cause of the interruptibility or 
reachability. In the list quoted, "out to lunch" or "on the phone" are 
examples of such indications.

I think you've covered the first category reasonably well.

There still may be value to conveying the second category as enumerated 
tokens, as they provide useful context. For example, 'extended away' 
will cause very different behavior than 'out to lunch'. For the former, 
I will find a substitute person to deal with the issue, for the latter, 
I'll wait an hour.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Jan 2003 13:30:27 -0500

I have no problem with interest groups defining their own statuses. 
Hopefully they will have the wisdom to define suitable ones for their needs.

In terms of general ones, my concern is that the kinds of status that I 
see bandied about are often not clearly distinguished, and the set of 
them is open ended in nature, so new ones may be invented at any time.

This doesn't lend itself well to configuring the handling of these:

- I may be able to figure out what kind of automated handling to do for 
'Out To Lunch', but then I discover that some people use 'Stepped Out' 
instead. In the end, this just degenerates into something that can only 
be handled by human interpretation, so we might was well just use a text 
message to describe.

- One of the big issues seems to be gatewaying between systems that each 
have their own notion of what set of statuses to offer. We will make the 
problem worse rather than better if we simply accept every status with a 
different name as a unique. And accepting every status with the same 
name as the same is likely wrong too - because often the intended 
semantics are not quite the same.

I believe we are better off sparingly adopting a set of statuses that 
are more fine grained, and that are orthogonal to one another in 
meaning, which can be combined in different ways to express the overall 
status.

So, instead of having a status like "In a Meeting", where the buddy must 
decide the implications, I would prefer to declare the implications. E.g.:
- emergency voice calls will be accepted live
- all other voice calls go to voicemail
- I will accept IM of a business nature, or high priority personal IM
- a text status of "In a Meeting"

It would be quite feasible for the UI of my system to have an "In 
meeting" state for me to select that would set all of this up.

	Paul

Henning Schulzrinne wrote:
>> pointed out, we don't want to define statuses for things that a 
>> hospital or a university alone will want. But that doesn't mean we 
>> should do 
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 13 Jan 2003 13:56:42 -0500

> Hopefully they will have the wisdom to define suitable ones for their 

And if they don't, they get to suffer the consequences themselves...

> be handled by human interpretation, so we might was well just use a text 

That's why it's important to have a somewhat-stable general set, i.e., 
where additions are managed so that new things get introduced only rarely.

> semantics are not quite the same.

I don't see how this makes things worse. Either there is match, or there 
is none. In the latter case, you're no worse off than without having the 
qualification.

Are you arguing that Yahoo's "out to lunch" has a subtly different 
meaning from some other system that uses the same dscription?

> meaning, which can be combined in different ways to express the overall 

See my last email on one such division.

> - a text status of "In a Meeting"

This is along Vijay's line of thought, it seems.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Jan 2003 14:22:25 -0500

Henning Schulzrinne wrote:
> 
>> - One of the big issues seems to be gatewaying between systems that 
>> each have their own notion of what set of statuses to offer. We will 
>> make the problem worse rather than better if we simply accept every 
>> status with a different name as a unique. And accepting every status 
>> with the same name as the same is likely wrong too - because often the 
>> intended semantics are not quite the same.
> 

Not that one, because I haven't found an "out to lunch". But while I 
haven't been able to verify this, I have heard that "offline" users in 
Yahoo can still be sent messages that will be displayed later, while 
offline users in MSN can't.

>> meaning, which can be combined in different ways to express the 
>> overall status.
> 

Yes, that is one division that may be helpful - distinguish What from 
Why. The Why can easily be discarded if not understood. Other than 
possibly presenting a pretty icon, its not very likely that much if any 
automated processing will typically be conditioned on it. I prefer to 
put more attention into getting the What part well defined.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 13 Jan 2003 14:30:51 -0500

> offline users in MSN can't.

I agree that we should define terms precisely.

> put more attention into getting the What part well defined.

Agreed; beyond icons and sounds, the major reason is probably 
internationalization and indirect usage by other parties. For example, I 
may automatically change my CPL script to go to a secretary for 
'extended absence', but let it go to voicemail for 'lunch' since the 
secretary is better at judging urgency, but worse at capturing detailed 
messages (and likely out to lunch at roughly the same time...).

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Jan 2003 14:48:08 -0500

>       Offline (invisible, lurking)

Note that while I might want to distinguish my own status as 
really-offline or online-but-invisible, this isn't a distinction that is 
shared with those that receive my status, at least until we start 
distinguishing between what is presented to different people.

Conceivably I might be seen as some variant on OPEN to my secretary 
while I am CLOSED to everybody else. But in that case my secretary might 
also need to know that I am trying to be invisible to others. I don't 
see quite how to fit that into presence status.

>     authority (i.e. a secretary) can interrupt the presentity.

The trouble with these "interrupt" kinds of statuses is that there are 
many nuances.

An important one is that my availability may well vary by medium even 
with a single contact/tuple. Using SIMPLE, I can use the same address 
for voice, IM, video, etc. When I'm in a meeting voice may not be 
available at all, or at least will be perceived as an interruption, 
while IM may be perfectly ok.

This suggests that the availability be describable on a per-media basis.

> secretary, hospital administrator, etc.) should be displayed.

I can go along with "guidance". The presentity is deciding what status 
to publish, and must ultimately decide what to do when requests arrive.

I do think we need to provide some guidance regarding what the 
client/buddy should *assume* will happen depending on the status. It is 
not *required* that the presentity act in accord with that, but if they 
don't, they will eventually annoy their buddies.

So for instance, if I see that you are advertized as offline, I can 
expect that an invitation will fail. I am still free to try of course. 
And you are free to answer my call if I do try. But if I often can 
successfully call you when your presence status is offline, then I will 
simply learn not to trust presence, which is counterproductive.

Some IM clients modify the gui based on the presence status of a buddy. 
For example, I may not be given a simple option to send a message to 
someone who is offline. There ought to be enough of a contract so that 
this makes sense. But I don't think this need be a firm contract.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 13 Jan 2003 14:15:07 -0600

> And if they don't, they get to suffer the consequences themselves...

Agreed.

> intended semantics are not quite the same.

The best gateway is no gateway, of course.  Given that xmpp and simple
work is being done right here in IETF, hopefully we can reach a
consensus for a set of status codes between the two (maybe in impp WG)?
That leaves Yahoo! Messenger, AOL, and Microsoft.  Presumably, Microsoft
supports simple, so that leaves Yahoo! and AOL.  Gateway'ing will then
be needed between IETF standardized sytems and Yahoo! and AOL.  Just
for completion, IETF is not interested in definining gateway procedures
*between* Yahoo! and AOL.

Henning Schulzrinne wrote:
 > Paul Kyzivat wrote:
>> So, instead of having a status like "In a Meeting", where the buddy 
>> must decide the implications, I would prefer to declare the 
>> implications. E.g.:

Yes; if we can do this by having such primitive status codes, we should.
I don't think anyone argues that we should have fine grained status
beyond OPEN and CLOSED.  CLOSED is very simple to deal with; the big
problem is how to (sub)classify  OPEN.  We can take the list I proposed
and Henning's response to that as a start.

Regards,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 13 Jan 2003 14:23:20 -0600

Henning Schulzrinne wrote:
>> possibly presenting a pretty icon, its not very likely that much if 
>> any automated processing will typically be conditioned on it. I prefer 
>> to put more attention into getting the What part well defined.
> 

I have no problems separating the 'What' from 'Why'; however, I think a
tacit assumption we are all making is that the presence information is
to be used for call (or session) routing (maybe because IM and P are so
conjoined to begin with).  While this is definitely an advantage, I
think that in many instances, presence information stands on its own --
just knowing that my spouse/wife/co-worker is out to lunch is enough.

As I have noticed (and Paul, too), Yahoo! Messenger allows one to send
an IM to a presentity that is not even online.  When the presentitiy
comes online, the IM is delivered to it.  It just seems to me that
we should decouple the need to establish sessions from representing
the notion of presence itself.  If we carve out the status codes nicely,
maybe establishing a session will fall automatically into place based
on the primitives we posit.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 13 Jan 2003 14:44:14 -0600

> distinguishing between what is presented to different people.

No; I am not advocating sharing the 'invisible' or 'lurking' state with
other users.  It's good for the system to know; to the users, the
presntitiy is CLOSED (Unavailable, Offline, whatever...)

> see quite how to fit that into presence status.

If my secretary needs to contact me (i.e. I am OPEN to my secretary
and CLOSED to everyone else) then, the presence status is
"Busy-interrupt-authority".

More inline.

> This suggests that the availability be describable on a per-media basis.

As IM, like voice, becomes a dominant communication channel, the nuances
of the "interrupt" kind really boil down to 2 media types -- IM, and
voice/video/gaming communications.  I can accept IM even when I am
"Busy-interrupt", but I cannot accept voice/video sessions in that
state.  Definitely doable, I think.  Even while accepting IM, I can
only accept IMs in "pager" mode, rather than "session" mode.

> simply learn not to trust presence, which is counterproductive.

Hence the need to decouple establishing sessions from representing
the notion of presence itself.  Maybe Yahoo! Messenger has trained
its users to send IM to people who appear offline, but the tacit
understanding there is that the receiver of the IM is offline, so
don't expect an immediate response (I am not sure what the system
does -- i.e. does it deliver the IM to a presentity that is
lurking or invisible?  I think not.)  However, the notion of
voice/video communications is more subtle -- it cannot be queued,
so to speak, while the receiver is offline.  Both parties need to
be present at the same time for an interactive voice/video session to
succeed.

I think that as a first cut, we should focus on representing the
various states of OPEN based simply on the premise of presence itself;
not necessarily on the intent of establishing a session.  Once we
have that list of status codes, we can see if they aid (or hinder) in
if session establishing semantics are applied to them.

> this makes sense. But I don't think this need be a firm contract.

I for one have gotten used to sending an IM to a Yahoo! Buddy who is
offline because I know the system will queue it up and deliver it
later.  However, as used as I am to this behavior, I would not think
of establishing an interactive communication session (be it an IM
"session mode" or voice/video session) with an offline presentity.

The contract maybe as simple as simple as providing some hints on
establishing interactive media sessions based on presence information.
While "pager" mode IMs maybe okay, "session" mode IMs or interactive
voice/video/gaming sessions probably do not make sense if the receipient
is showing an offline status.

Regards,

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 13 Jan 2003 16:23:59 -0500

> "Busy-interrupt-authority".

I guess you'd use the Contact field to provide the secretary name?

> voice/video/gaming communications.  I can accept IM even when I am

Usually, it would be audio or anything-else (one could imagine that 
somebody could write notes on their whiteboard and point a camera at it, 
  or my wife could use sign language since she can talk and sign at the 
same time...). However, we had discussed various sidebar conferences, 
where I can put my main conference in the background.

> only accept IMs in "pager" mode, rather than "session" mode.

Why shouldn't I have two IM sessions going at the same time, at least as 
a multitasking teenager?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Jan 2003 18:36:10 -0500

Vijay K. Gurbani wrote:
>> really-offline or online-but-invisible, this isn't a distinction that 
>> is shared with those that receive my status, at least until we start 

OK - at least we agree it isn't shared with buddies.

But I'm concerned what you mean by "good for the system to know". I 
think its helpful/necessary for the UAC representing the user to know. 
It is not necessarily necessary for anything else to know. In 
particular, the presence server representing the user's presentity may 
not know. Presence servers representing your buddies may be aware that 
you have active subscriptions to their presence, and so are active in 
some sense, but they may or may be be able to infer anything useful from 
that. It certainly isn't an explicit indication of your presence.

> voice/video/gaming communications. 

Why do you split it this way? (IM and Other). Certainly gaming is 
independent of the others. And the coupling between voice and video 
isn't complete. (While video is frequently assumed to require voice, 
voice certainly doesn't require video.)

Suppose I have something to show you, and so only want to call you when 
you are at a video phone. Your presence at an audio phone isn't good 
enough for me.

 > I can accept IM even when I am

But these are not absolute rules. Maybe you can accept video too, just 
not voice. (So your assistant can send you text and a video view of the 
riot happening outside your office while you are in a meeting with the CEO.)

>> successfully call you when your presence status is offline, then I 
>> will simply learn not to trust presence, which is counterproductive.
> 
> the notion of presence itself. 

I'm not convinced we can/should do that. Maybe we don't want to restrict 
it to "establishing sessions", but at least to communicating with the 
presentity via its contacts.

Without grounding ourselves in a purpose for the presence, there is no 
way to scope what we mean by presence. Is it ok for me to describe part 
of my presence state as "traveling the South Seas for a year", or 
"retired in Florida"?

It is especially important to focus in this way when defining SIMPLE 
extensions - there might be a broader scope for PIDF in general.

 > Maybe Yahoo! Messenger has trained
> so to speak, while the receiver is offline. 

Certainly it can. That is what voicemail is for. If I have voicemail, my 
presentity is probably never entirely offline for voice. However 
something should distinguish between being online live and being online 
with voicemail.

 > Both parties need to

Reason I disagree above.

>> Some IM clients modify the gui based on the presence status of a 
>> buddy. For example, I may not be given a simple option to send a 
>> message to someone who is offline. There ought to be enough of a 
>> contract so that this makes sense. But I don't think this need be a 
>> firm contract.
> 

As these "systems" start to interoperate using SIMPLE (I hope), you 
won't know whether you are talking to a Yahoo user or an MSN user. So 
you had better not need to know before deciding to send a message.

What will you do if you see a presence status of Do Not Disturb? Most IM 
systems will at least make it difficult for you to initiate 
communication. But you could still pick up the phone and call, and maybe 
it would ring. It this stuff is all well integrated, Do Not Disturb 
should be correlated with a UA that will actually refuse incoming calls 
of all sorts.

> is showing an offline status.

I think some work is required to sort out how we represent the 
distinction between page and session mode IM. If we aren't careful, page 
mode will be abused to get around restrictions is session mode.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 14 Jan 2003 09:46:03 -0600

[Trimming CC list]

Paul Kyzivat wrote:
> It is not necessarily necessary for anything else to know. 

In an end-to-end system, true.  Only the UAC representing the user needs
to know.  But I have a feeling that systems like Yahoo! Messenger also
store central state -- I just checked.  On Yahoo! Messenger, I can send
an IM to a buddy that appears offline to me but is, in fact, online and
invisible.  The system does deliver the IM to the lurking buddy; but
it will queue it up if the buddy is actually offline.

> Why do you split it this way? (IM and Other). 

Merely on the basis of establishing an interactive communication channel
or not.  Pager mode IM does not need interactive presence of all
participants; voice/video/gaming sessions do.

> you are at a video phone. Your presence at an audio phone isn't good 

That's where presence and routing conflate, IMHO.  While my presence at
an audio phone may not suffice your requirements, it may provide a lot
of value to someone else who is interested in it.  But I am realizing
that de-coupling presence and routing at this point in time is too late.
For instance, <draft-ietf-impp-cpim-pdif-06.txt> itself includes a
"priority" parameter to the <contact> element to aid in routing, not
to mention a Contact URI.  In my naive world, each presentity would be
represented by multiple devices, each such device merely representing
its presence state in richer primitives than "OPEN", "CLOSED".  Then,
when we add routing to the mix, we would do so in a separate namespace
for each device.

> presentity via its contacts.

I had in mind, as a base set, the absolute primitive notion of presence.
No implications on any sort of communications.  These would be overlayed
as separate namespaces.  But, as I said above, it is too late for that
and I will not argue for it.

Regards,

- vijay

---

From: "Thanos Diacakis" <[email-masked]>
Date: Tue, 14 Jan 2003 12:31:17 -0700

Why would "Busy-no-interrupt" and "Away" fall in the OPEN category and not
in the CLOSED?

Perhaps if we go down that thought path, we will discover that my IM inbox
status is orthogonal to my current (personal) status/activity...  For
example, some people want to leave their inbox OPEN while they're away (or
offline), and some want to leave it CLOSED.

What is then the point of mapping those to OPEN or CLOSED?

Thanos
---
Thanos Diacakis
Openwave Systems
[email-masked]
+1-303 385 6705

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jan 2003 14:46:11 -0500

Whether these fall into OPEN or CLOSED depends on the assumptions you make.

At least in the case of Away, I think there is generally the implication 
that you may send a message and it will be available to the user when 
they return. (In the case of voice, this would mean that you could leave 
a voicemail message.)

So the question is how this should be represented. In the case of IM, 
often the same contact is used in this case. So the status should be 
OPEN, indicating that you may indeed communicate with this address.

In the case of voice, the same may also be true as long as the diversion 
of the call to voicemail occurs behind the same contact address. OTOH, 
some may choose to configure things so that a voicemail server has its 
own contact and tuple. In that case, the tuple where the person 
typically is would either go away or be CLOSED, while the one for the 
voicemail would be OPEN.

Some of the same considerations may apply to busy-no-interrupt, but I 
don't feel I understand the intended semantics well enough to suggest 
exactly how it ought to look.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 14 Jan 2003 13:50:32 -0600

[Trimmed CC list]

Thanos Diacakis wrote:
> Why would "Busy-no-interrupt" and "Away" fall in the OPEN category and 
> not in the CLOSED?

Because "Busy-no-interrupt" and "Away" still denote that I am present,
although not available.  This is still very useful for people who
simply want to subscribe to my presence state only, not necessarily
with the intention of actually contacting me.  The CLOSED category
implies that I am not present at all, period.

> What is then the point of mapping those to OPEN or CLOSED?

Unless I grossly misunderstand your question above, the PIDF document
only describes two basic states -- OPEN and CLOSED -- for presence
status.  Everything else has to be added on as an extension.

Cheers,

- vijay

---

From: "Thanos Diacakis" <[email-masked]>
Date: Tue, 14 Jan 2003 13:18:58 -0700

With the excerpts below in mind, see comments inline.

RFC 2778 states:

STATUS is further defined by the model to have at least two states
   that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT
   MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will
   not be accepted.

PIDF states:

4.1.4. The <basic> element

   The <basic> element contains one of the following strings: "open" or
   "closed".  The values "open" and "closed" has the same meaning as
   OPEN and CLOSED defined in RFC 2778 respectively, and stand for
   availability of receiving instant messages if the <tuple> is for an
   instant messaging address.

----- Original Message -----
From: "Vijay K. Gurbani" <[email-masked]>
To: "Thanos Diacakis" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 14, 2003 12:50 PM
Subject: Re: [Simple] Extending <status> for presence

> implies that I am not present at all, period.

CLOSED only means that my IM inbox is closed.  Nothing more, nothing less.
One can define a "user status"/activity, say, "Busy-no-interrupt" and map
that to OPEN, but someone else can map that to CLOSED.  For example, I'd
really prefer my inbox to be CLOSED when I'm away.  I don't like IMs piling
up in my inbox.

> status.  Everything else has to be added on as an extension.

I'm not arguing against extensions.  I'm just trying to see if those can be
mapped to OPEN or CLOSED and it seems they cannot.  As per my previous
email, I think that RFC 2778 status may be orthogonal to the status/activity
element that is being discussed in this thread.  (Well, if this is true,
they're not really "extensions"... they're a different presence information
element).

Thanos
---
Thanos Diacakis
Openwave Systems

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 14 Jan 2003 15:20:20 -0600

Thanos Diacakis wrote:
> really prefer my inbox to be CLOSED when I'm away.  I don't like IMs 
> piling up in my inbox.

Conceivably there could be multiple tuples associated with the
presentity.  The IM tuple could be CLOSED, while a tuple without any
contact (thus representing the presentity itself) could be left
OPEN and fine grained to "Away".  What I am unsure of is if we do
this in PIDF (it is syntactically possible), will it have the
desired effect (i.e. are the semantics of PIDF rich enough so that
a tuple without any Contact element represents the presentity itself?)

> I'm not arguing against extensions.  I'm just trying to see if those can 
> be mapped to OPEN or CLOSED and it seems they cannot.  As per my previou
> email, I think that RFC 2778 status may be orthogonal to the 
> status/activity element that is being discussed in this thread.  (Well, 
> if this is true, they're not really "extensions"... they're a different 
> presence information element).

I don't believe it is as much orthogonal as it is grounded in the fact
that presence is used as a precursor to communications (IMs, in
rfc2778's case).

- vijay

---

From: "Thanos Diacakis" <[email-masked]>
Date: Tue, 14 Jan 2003 13:10:45 -0700

inline

----- Original Message -----
From: "Paul Kyzivat" <[email-masked]>
To: "Thanos Diacakis" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 14, 2003 12:46 PM
Subject: Re: [Simple] Extending <status> for presence

> Whether these fall into OPEN or CLOSED depends on the assumptions you
make.

Exactly my point.  And given that, we cannot map a particular (RFC 2778)
status to a activity/status, as it depends on what the application is trying
to express.

> they return. (In the case of voice, this would mean that you could leave

As above, yes, that's one way of doing it.  Nothing annoys me more than
coming back and having tons of IMs to sort through, so I'd want mine to be
CLOSED when I'm away.

Thanos

---

From: "Thanos Diacakis" <[email-masked]>
Date: Tue, 14 Jan 2003 15:03:57 -0700

Hi Vijay,

There are at least a couple of ways in expressing what you want in PIDF.

The one is defining a tuple with some extensions inside that make it
presentity specific, i.e. that tuple can only exist once within the presence
document.  The other way is putting that information outside a tuple, again
as an extension.  This is probably not allowed by RFC2778 as a strict
interpretation of that doc would lead us believe that "Other Markup" is only
allowed within tuples.  However, we've violated that in PIDF at least twice:
once in section 4.2.3 by allowing XML elements to appear anywhere in the
presence doc as extension and by having the presentity specific "note"
outside a tuple.

That may solve the "how".  Back to the "what/why":

As I think I have established in my previous mail, RFC2778 status pertains
to IM inboxes being OPEN or CLOSED, and can vary independently (hence the
orthogonality) from a user activity, such as Online, Out To Lunch, Away,
Busy, Offline, etc., depending on the application.

Therefore, assigning a *fixed* mapping, that says "Busy" will be OPEN,
"Offline" will be CLOSED, "Away" will be OPEN, etc. doesn't make sense.

That is not to say that those "activities" are invalid or irrelevant, they
are very much required for, say, an IM service.  However, we need to much
better define what they do mean and what they don't mean, and it seems that
they don't mean RFC2778 OPEN or CLOSED.

Thanos
---
Thanos Diacakis
Openwave Systems

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jan 2003 10:08:18 -0500

Thanos,

A few observations:

- while <basic> is currently only defined for IM, I believe that part of 
defining a profile and extensions for SIMPLE is to extend the definition 
of <basic> beyond IM, to other applications of SIP, such as voice.

- I agree with you that open/closed is orthogonal to whether you as a 
person are busy.

- But the situation of mapping statuses is different when we start 
discussing specific status values of particular IM systems. For 
instance, Sametime has a "Do Not Disturb" status. It also has a specific 
meaning for that - it refuses to establish a new IM session while in 
that state. So, when mapped to PIDF it would correspond to CLOSED. ICQ 
also has a Do Not Disturb state. I don't know how it works, but 
conceivably it could work in a way that corresponds to OPEN.

	Paul

>    instant messaging address.

[snip]

> really prefer my inbox to be CLOSED when I'm away.  I don't like IMs piling

[snip]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Jan 2003 04:56:00 -0500

inline.

> and Henning's response to that as a start.

I still believe we need both the "callerprefs" style PIDF status that 
Paul has been talking about, but ALSO the well-defined base list of 
statuses, such as "away" or "out to lunch". We need both because we 
clearly have several applications that are being driven by presence. One 
application is setting up sessions, and that is ideally addressed by the 
callerprefs stuff. Another is icons, or locally translated text. That is 
ideally handled by this list of statuses.

Based on this, the semantics of these statuses are simple. They are 
nothing more than an indication of "why", suitable for consumption by 
automata which wish to render this information in an access specific 
way. By access, I mean things like PC application, mobile application, 
IVR, and so on.

I further believe that these status types (callerprefs, basic, and the 
enumerated list) are orthogonal to each other. It is perfectly 
reasonable to be "out to lunch" and have a basic status of CLOSED, or be 
"out to lunch" and have a status of OPEN. OPEN/CLOSED refer to whether I 
can receive communications or not, and that is generally orthogonal to a 
descrtive status.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jan 2003 11:22:51 -0500

I agree with Jonathan, as long as these are indeed orthogonal.

In fact, we may need even more dimensions:

- I see one status type with values of {ACTIVE, INACTIVE} that is 
typically inferred by observing behavior

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

It is easy to see why these are orthogonal. I can certainly be either 
active or inactive while not wanting to be disturbed. But I can also 
have indicated that I am AWAY (Out to Lunch is a special case of this), 
but actually be eating at my desk, so that I may appear either active or 
inactive.

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.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jan 2003 11:37:34 -0500

response at the end.

Jonathan Rosenberg wrote:
> a small note inline.
> To me, this suggests that my device is modeled as two separate tuples. 
> One for voice, with a status of CLOSED, and one with IM, with a status 
> of open. This would, perhaps, need some way to allow the watcher to 
> correlate these two so as to know that they represent the same physical 
> device. Indeed, one might envision "device" as another status itself! So:
> 
> <tuple id="99s8">
>   <basic>OPEN</basic>
>   <device>Cell Phone</device>
>   <callerprefs-stuff>IM allowed</>
> </tuple>
> 
> <tuple id="aak988">
>   <basic>CLOSED</basic>
>   <device>Cell Phone</device>
>   <callerprefs-stuff>voice not allowed except high priority</>
> </tuple>
> 
> Device could be an enumerated type, or perhaps even just a textual string.

Well, there are many ways to skin a cat.

Is there any value to <device> beyond <contact>? If I can compare two 
devices for equality I can just as easily compare two contact addresses 
for equality.

It seems to me a lot easier to understand if each tuple with a contact 
represents a distinct communication target, so I can decide whether it 
is useful to me independently of all the others.

Otherwise, things get messy if I potentially want to use multiple media. 
Then I have to look for all tuples representing the same device and 
combine their statuses before deciding if the device is suitable for my 
needs. And then I must still deal with the potential for conflicting 
status values between those tuples. It isn't an unsolvable problem, but 
is it better than simply permitting availablility information for each 
medium? The callerprefs stuff can already do that.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Jan 2003 05:44:31 -0500

a small note inline.

Paul Kyzivat wrote:

<tuple id="99s8">
   <basic>OPEN</basic>

<tuple id="aak988">
   <basic>CLOSED</basic>

-Jonathan R.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 15 Jan 2003 11:07:55 -0600

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:
 > 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:
> typically inferred by observing behavio

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

---

From: "Thanos Diacakis" <[email-masked]>
Date: Wed, 15 Jan 2003 12:27:06 -0700

Paul,

> conceivably it could work in a way that corresponds to OPEN.

Agreed.  Applications can take the two orthogonal variables, combine (map)
them  as they please and create other "status" value that have a specific
assigned meaning...

However, the mapping is an application level problem, not a protocol level
problem.  Of course, if we define a protocol for a particular application,
i.e. one that is narrow enough, that might be appropriate.  But the stuff
that we've been discussing here is way too general for any concrete mappings
to be broadly applicable.

Thanos

---

From: "Thanos Diacakis" <[email-masked]>
Date: Wed, 15 Jan 2003 12:35:46 -0700

Vijay,

> has been pointed out before, others will learn to distrust ones presence

Currently the presentity cannot have a OPEN or CLOSED status, simply because
we haven't defined what that means.  What do you have in mind when you say
that a presentity is OPEN or CLOSED?

> case, why not actually provide means for this in simple (as in the

Again, I'm having trouble with some of those.  "DND" is fairly easy: the
person that the presentity represents does not want to be disturbed.  What
does that status of a *presentity* mean if it is "Away", or
"Active/Inactive"?  Away from what?  Inactive how?  I can understand if the
status of a *device* is "Away", that could be defined to mean that there is
no human using that device at that instant.  Similarly, "Active" could be
defined as the *device* is being used, but not sure what an active
presentity is...  Thoughts?

Thanos
---
Thanos Diacakis
Openwave Systems

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jan 2003 16:20:44 -0500

Thanos,

I think we are in violent agreement.

I agree that mapping of the status values used by particular IM 
applications to/from PIDF status values is an application problem.

The point of talking about it here and now is because those applications 
and their status values exist today, while our new PIDF status values 
are still being defined. I believe it is important to define PIDF status 
values that can reasonably map to/from the common IM systems.

If we can't demonstrate a reasonable mapping then there will probably be 
difficulty in getting PIDF accepted. OR, each vendor may define its own 
mapping, using proprietary elements, and interoperation will be a mess.

I expect we will eventually want to document mappings in the same way 
that mappings have been defined between sip and other telephony protocols.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jan 2003 16:45:37 -0500

Again I am mostly in agreement with Thanos. Comments inline.

	Paul

>>has been pointed out before, others will learn to distrust ones presence

This makes no sense to me. What does it possibly mean to say the state 
of the presentity is OPEN but the state of all the devices is closed? In 
what way would things be changes if we then changed the state of the 
presentity to CLOSED?

The meaning of OPEN and CLOSED is defined in terms of what can be done 
with the devices.

>>case, why not actually provide means for this in simple (as in the

I was my intent that these (or something similar) be part of the 
extensions we are defining. I have now been convinced that they are 
useful in addition to state explicitly defining what kinds of 
communication are permitted.

I think ACTIVE/INACTIVE is an observation about the user of a device. It 
is intended as a predictive indicator of whether the user would respond 
if attempts were made to communicate via the device. In principle it 
could be provided in conjunction with CLOSED, though it might not be 
very useful in that case.

> presentity is...  Thoughts?

I agree with all of this. As soon as it is possible to describe the 
status of two devices, presence can be different at each.

If you want to have a single notion of presence, describe everything in 
terms of one device. It can be a virtual device - a sip AoR with 
multiple contact addresses to different physical devices. As long as you 
describe it as a single tuple referencing the AoR, it has a single set 
of status values. But if you choose to represent it with a separate 
tuple for each contact address then each tuple might have conflicting 
status values. In this latter case I think status for the presentity as 
a whole is simply ambiguous.

---

From: Sean Olson <[email-masked]>
Date: Wed, 15 Jan 2003 13:58:21 -0800 (PST)

> Device could be an enumerated type, or perhaps even

Why should the tuple ID be distinct from device?
The opposite approach is to define a basic status
for the device and sub-status for each media type
that that device supports:

<tuple id="aak988">
  <basic>OPEN</basic>
  <callerprefs-stuff>voice not allowed except high
   priority</>
  <im-status>CLOSED</im-status>
  <av-status>OPEN</av-status>
  <t120-status>OPEN</t120-status>
</tuple>

/sean

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jan 2003 17:23:10 -0500

>   <t120-status>OPEN</t120-status>

We already have proposed a way to do this in 
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>

(I'm not sure what media type to use for T.120 - just guessing.)

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Jan 2003 06:13:21 -0500

inline.

> a whole is simply ambiguous.

A few words are perhaps in order here on rfc2778. It is my recollection 
as it was developed that the idea was that rfc2778 could serve as a 
MODEL for presence systems. That is, it was sufficiently general that 
existing systems could be mapped to it. Thus, the concept of a "tuple" 
is just a way of modeling various things.

So, the issue we are running into here is that there are many things 
which a tuple could potentially represent. So far, we have talked about 
a tuple representing:

* a device
* one of many logical targets of communications on a device
* a presentity

One can imagine a tuple representing other things, like a group of 
presentities, for example (sip:[email-masked]).

So, the questions are: (1) do we need to standardize what these tuples 
represent, and (2) do we need to standardize the relationships between 
them. On (1), I think perhaps no, but on (2), I think maybe yes. Perhaps 
what we need is the ability to represent things in a hierarchy. So, you 
could have a tuple, and within it, some more tuples, and within those, 
more tuples. The meaning of the hierarchy may only be important to a 
user, and thus represented by notes. For example, the top level tuple 
might represent a presentity, and it may have its own basic status, 
which just indicates whether the presentity is willing to be contacted. 
If none is provided, it might be "derived" from the basic status 
elements of its child tuples. While its not clear to me what a basic 
status of OPEN for a presentity means when each of its child tuples (the 
devices) are CLOSED, there are most definitely attributes, such as "out 
to lunch" which make more sense for a tuple that represents a 
presentity, than for a tuple that represents a device.

Just a thought...

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Jan 2003 06:19:25 -0500

> has been pointed out before, others will learn to distrust ones presence

I disagree.

We are just talking about presence. The decision to reject a call (or an 
IM) when someone is "do not disturb" in their presence, is an 
APPLICATION of presence. Indeed, it may be a multiplicity of 
applications - something that blocks IM, as part of a messaging app, 
something that forwards calls to voicemail, as a voice app, and so on. I 
do not know how one can mandate the deployment of certain applications 
of presence.

The most we can do is describe the semantic of what these things mean. 
IMHO, "do not disturb" simply means that the user does not wish to be 
contacted at this time. Thats all it means. Applications can consume 
this, and do things with it, appropriate for its semantic. As an 
example, a PC application could render an icon. An IM app could reject IMs.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Jan 2003 06:29:33 -0500

inline.

Paul Kyzivat wrote:

>> correlate these two so as to know that they represent the same 
>> physical device. Indeed, one might envision "device" as another status 
>> itself! So:
>>
>> <tuple id="99s8">
>>   <basic>OPEN</basic>

Sure, there is a difference. The Contact may very well be different. For 
example, the "IM" piece of my phone could perhaps be addressed as 
sip:[email-masked], and the "voice" piece as sip:[email-masked]. 
These might represent different resources on the same device.

> is useful to me independently of all the others.

See my previous note on this; I think our trouble is that we are unsure 
of what a tuple really is modelling.

> medium? The callerprefs stuff can already do that.

The issue is whether or not I want to provide multiple status values for 
each medium. You are basically saying that, if all I want is to indicate 
OPEN/CLOSED, I can equally do that with the callreprefs stuff by 
indicating false for video or audio, as the case may be. What about 
other statuses we come up with? Perhaps there are no examples, and so 
this point is moot. Not clear to me yet.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Jan 2003 09:01:54 -0500

Stepping back a bit, maybe we should ask what kind of questions presence 
about a person can answer.

(1) Is the person available for communications and, if so, on what media?

Here, in general, we only care about the media that are available, not 
all the media that the user doesn't have right now, since that list is 
unbounded once you add applications ("No, I'm not available for Doom, 
Chess, SimCity, ..."). We might conceivably care about how long a media 
might still be available ("leaving in 15 minutes, better call quickly") 
or when it might be available again ("meeting ends in 20 minutes").

(2) What is the person doing right now?

We might want to know not just the start time (how long already), but 
also how long until anticipated completion.

Note that many calendar systems (such as RFC 2445 or Yahoo calendar) 
allow for categories of activities. Some are free-text (but often 
definable as a list for a particular software), others are pre-defined.

(3) How is the person feeling right now (calm and relaxed, stressed, 
hopping mad) - very useful to know for the calling party and easily 
derived from a real-time blood-pressure input. (:-), if that's needed.)

Obviously, there could be many other pieces of information that might be 
useful to others, such as location, level of distraction ("watching 
TV"), etc., but I suspect we all agree that those are beyond the current 
discussion.

Note that you can easily get to the point where you are effectively 
sending an iCal (or xCal draft-ietf-calsch-many-xcal-02.txt) entry 
describing the activity. This may be a better, more general solution.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Jan 2003 09:09:28 -0500

Another dimension: availability for communication can probably be 
classified into three rough classes:

- available real-time
- available store-and-forward (message store of some sort, e.g., 
voicemail or IMs that are stored somewhere for retrieval)
- not available

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Jan 2003 08:56:01 -0600

Thanos Diacakis wrote:
 > Currently the presentity cannot have a OPEN or CLOSED status,
 > simply because we haven't defined what that means.  What do you have
 > in mind when you say that a presentity is OPEN or CLOSED?

Simply that a presentity itself is online or offline, without any
reference to its devices.  Thus a presentity that is online, but
does not want to be disturbed has *its* status as OPEN while
all the devices it commands are CLOSED.

As I have been saying, many times the notion of presence in and of
itself is sufficient.  I would like to know if my manager is in the
office before I cross the campus to meet him.  If he has not turned on
his cell phone or his started his SIP UA, does that mean that he is not
present?

 >>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?
 >
 >
 > Again, I'm having trouble with some of those.  "DND" is fairly easy:
 > the person that the presentity represents does not want to be
 > disturbed.  What does that status of a *presentity* mean if it is
 > "Away", or "Active/Inactive"?  Away from what?  Inactive how?  I can
 > understand if the status of a *device* is "Away", that could be
 > defined to mean that there is no human using that device at that
 > instant.  Similarly, "Active" could be defined as the *device* is
 > being used, but not sure what an active presentity is...  Thoughts?

We are looking at this through a device-centric lens; hence you argue
that "Away" implies that there is no human using the device.  However,
to me, "Away" implies that the presentity itself is away from all of
its devices; it is still present, per se.  For instance, the status
"Away" qualified by a location extension of "Office" allows one to
deduce that the presentity is in the office, although not near any
of its devices right now.  The main actor in presence should be the
presentity, not the device.

If we take that model, then status strings like "Busy-interrupt" that
I proposed earlier make eminent sense.  We are quantifying the state
of the presentity -- "Busy-interrupt" would imply that the presentity
is currently busy, but try sending an invitation for communication
anyway; if it is important enought, it may get answered.

Cheers,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Jan 2003 09:03:38 -0600

Paul Kyzivat wrote:
> of the presentity is OPEN but the state of all the devices is closed? 

Because it makes it easy to model DND, for instance.  Our model of
presence right now is device-centric; I am arguing for a presentity-
centric model, where the presentity is the main actor.  Thus, a status
of OPEN for the presentity and CLOSED for all the devices
authoritatively implies DND.  We do not leave it to the application to
decide if it should interrup the presentity or not.  The presentity-
centric model also makes it easier to represent "Busy-Interrupt"; it
is the presentity that is busy, but willing to be interrupted.  Not the
device.

> In 

That is simple (no pun intended :-)) -- a state of CLOSED for the
presentity implies that the presentity is offline and not accessible
through any interactive communication means (I would not consider voice-
mail as interactive communications here).

> The meaning of OPEN and CLOSED is defined in terms of what can be done 

I think if we view this from a different angle and apply it to the
presentity as well, the model becomes that much more powerful.

Cheers,

- vijay

---

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 16 Jan 2003 08:16:03 -0700

I think you are proposing that the presentity status be defined as follows:

If one or more devices are OPEN, then the presentity is OPEN, else if all
devices are CLOSED, the presentity is CLOSED.

If this is what you are saying, then it is redundant, as that information
can easily be determine from looking at the tuples.  Having it as a separate
item, doesn't achieve anything.

Your definition of "Busy-interrupt" is a sensible one (though there could be
others). The point here is that the activity variable ("busy-interrupt") and
status (OPEN/CLOSED) variables, are orthogonal to eachother.  However, the
particular value for the activity (busy-interrupt), under your definition,
would only apply though if the status variable has an OPEN value.

Thanos
---
Thanos Diacakis
Openwave Systems

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Jan 2003 09:19:10 -0600

Jonathan Rosenberg wrote:
> something that forwards calls to voicemail, as a voice app, and so on.

Then DND is a misnomer.  DND implies to me that I as a presentity do not
want to be disturbed -- akin to closing my office door and putting a
"Go Away" sign on it during office hours.  If what we want to represent
is that voice calls are blocked but IM can get through, then we should
use some other status value, like "Busy Interrupt".

The problem with leaving interpretation to application is that each
app may choose to inerpret it in a different manner, leading to all
kinds of user expectation problems.  If I am used to presence app A's
behavior of DND, I will be rather upset when I use presence app B and
it's behavior differs from A's.

We are representing status through tokens which have well defined
cultural nuances (irrespective of the language).  When you hang a
card containing "Do Not Disturb" or "Ne dérangez pas, sil vous plait",
or "No disturbe, por favor" on the hotel door, you might be upset if the
maid opened the door and came in anyway, right?  Why then the dichotomy
to the same token when it is applied to an electronic medium?

We do not have a paucity of tokens to choose from to represent status.
I would rather choose something like "Busy but interruptible" to make
clear my intention rather than a "Do Not Disturb".

Regards,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Jan 2003 09:22:28 -0600

Inline.

[...]
> elements of its child tuples. 

Exactly!  That is what I have been arguing for all along.  It is the
presentity that is the main actor in this domain, not the devices.

> While its not clear to me what a basic 
> devices) are CLOSED, 

Easy to represent DND.

> there are most definitely attributes, such as "out 

Exactly.  Thanks!

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Jan 2003 09:39:05 -0600

Thanos Diacakis wrote:
> If one or more devices are OPEN, then the presentity is OPEN, else if 
> all devices are CLOSED, the presentity is CLOSED.
> 
> can easily be determine from looking at the tuples.  Having it as a 
> separate item, doesn't achieve anything.

I think it does.  If I want to unambiguously represent DND from a
presentity-centric view, then the status of the presentity is OPEN, but
that of all its devices is CLOSED.  The presentity status of OPEN,
coupled with a qualifier like "In meeting with CEO" informs all watchers
about the presentity's state in no uncertain terms.

Thus it is important that the presence state of the presentity be
represented in a tuple.  Deducing it can lead to ambiguity.

> Your definition of "Busy-interrupt" is a sensible one (though there could 
> be others). The point here is that the activity variable 
> ("busy-interrupt") and status (OPEN/CLOSED) variables, are orthogonal to 
> eachother.  However, the particular value for the activity 
> (busy-interrupt), under your definition, would only apply though if the 
> status variable has an OPEN value.

Yes, exactly.

Regards,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Jan 2003 09:51:48 -0600

> voicemail or IMs that are stored somewhere for retrieval)

I would like to add one more:

- Busy but interruptible (i.e. try getting in touch with me, I may
   answer if I can).

There is one more, but I am unsure if it is a status in its own right
or something that can be derived by applying filters:

- Busy, but only available to certain people (this will include
   the domain-specific examples you had earlier -- professor in an
   oral, only department secretary can interrupt him, etc.)

Thanks,

- vijay

---

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 16 Jan 2003 11:02:53 -0700

comments inline.

----- Original Message -----
From: "Vijay K. Gurbani" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>
Cc: "Thanos Diacakis" <[email-masked]>; <[email-masked]>
Sent: Thursday, January 16, 2003 8:03 AM
Subject: Re: [Simple] Extending <status> for presence

> is the presentity that is busy, but willing to be interrupted.  Not the

Erm, then I have misunderstood your definition as per my previous email.
Please clarify what that is, because the above paragraph is ambiguous to me.

> mail as interactive communications here).

Again, what does the "presentity" (i.e. the person) being "offline" mean?

Thanos
---
Thanos Diacakis
Openwave Systems

---

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 16 Jan 2003 11:13:36 -0700

> > status of OPEN for a presentity means when each of its child tuples (the

No!  My "activity" (DND in this case) is orthogonal to the OPEN/CLOSED
status of my devices and we cannot represent the one using the other.  We
need a separate variable/tuple/field to do so.

Thanos
---
Thanos Diacakis
Openwave Systems

---

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 16 Jan 2003 11:16:21 -0700

What I'm trying to get to for the past few emails, is what you mean by a
presentity being OPEN or CLOSED.  Can you clarify this item in unambiguous
terms?

Thanks

Thanos
---
Thanos Diacakis
Openwave Systems

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Jan 2003 13:26:21 -0600

> presentity being OPEN or CLOSED.  Can you clarify this item in unambiguous

Sure.  As a basic premise I assume that detecting and imparting the
presence of the presentity itself is sufficient in many cases.  There
isn't any need to establish communication, just knowing if a presentity
is present is all that many users will care about.

Now, if we were to model this, every presentity should have OPEN or
CLOSED status, roughly corresponding to being online and offline,
respectively.  Extensions can specify the exact state of the
presentity if it is OPEN (i.e. "Out to lunch", "In a meeting", ...)

I agree that presence has to be grounded in something, so the need to
establish a communication channel with the presentity comes next.  This
can be modeled by a heirarchy of tuples.  Within the presentity tuple
are other tuples representing devices.

Now, if I as a user behind the presentity does not want to be disturbed,
I simply check a radio button on the UI that has the effect of
publishing my presence as "Presentity is OPEN (Do not disturb), but all
interactive communication devices are CLOSED" (I write "interactive
communication devices" because people should still be able to leave me
voicemail or send me IMs that can be bufferred for later delivery).
Thus no one can contact me in an interactive fashion, but watchers can
still see that I am online; and if we have a  location extension,
watchers can deduce that I am online at my office (vs. at home).

On the other hand, if I (again, as a user behind the presentity) get a
SIP call and answer it with my SIP UA, the presence information can be
published as "Presentity is OPEN (Busy but interruptible), some devices
(SIP phone) are busy but others can accept communications".

I am arguing that the state of the presentity should dictate the state
of the *interactive* devices that the presentity commands, not the other
way around.  Note that I make a distinction between interactive devices
since even if a presentity is CLOSED, people should still be able to
leave a voice mail, for instance.  This maps to two of the three rough

 >   voicemail or IMs that are stored somewhere for retrieval)

I hope this makes sense.

Cheers,

- vijay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Jan 2003 14:38:07 -0500

inline.

> need a separate variable/tuple/field to do so.

I am with Thanos here, in that I am not understanding Vijay's definition 
of DND, or what his interpretation of OPEN/CLOSED for a presentity means.

I REALLY don't understand what it means for a presentity to be online or 
offline. Last I checked, my fist doesn't have an ethernet connector that 
allows me to "log in". Devices are online or offline. People are not 
online/offline.

I think, really, we simply have the case that some statuses make sense 
for tuples that model devices (caller prefs parameters, basic status), 
some statuses make sense for tuples that model presentities (the thing 
Henning called "what is the person doing right now"), and some make 
sense for both (geolocation).

Now, an interesting question is - does a presentity need to be a person? 
I think we have an implicit assumption that the answer was yes. But, 
clearly, it does not. A presentity could, for example, represent a bot, 
in which case one might argue that online/offline for the bot does make 
sense. Bots, unlike people, do have ethernet connections :)

-Jonathan R.

---

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 16 Jan 2003 12:59:05 -0700

Vijay,

I understand the overall concept that you're explaining (though not
necessarily agree with all of it) but I still don't understand certain

> is present is all that many users will care about.

What does a "presentity" being "present" mean?

> presentity if it is OPEN (i.e. "Out to lunch", "In a meeting", ...)

What does a presentity being "online" or "offline" mean?

As Jonathan put it, people don't have Ethernet ports sticking out of
anywhere....

Thanos
---
Thanos Diacakis
Openwave Systems

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jan 2003 15:42:06 -0500

Damn! I go away from my email for half a day and I'm vastly behind on 
this one thread! :-)

I'm trying to read and catch up before replying, but I just have to 
reply to this, and Vijay's earlier discussion on status of the 
presentity independent of a device.

Vijay K. Gurbani wrote:
>> We are just talking about presence. The decision to reject a call (or 
>> an IM) when someone is "do not disturb" in their presence, is an 

I assert that DND is everyday life is always device dependent.

If you close your door and hand a Go Away sign on it, you are expressing 
a desire. There is no enforcement. Indeed you don't want absolute 
enforcement. If the building catches on fire, you don't want the fireman 
that comes in to pass you by.

Also, the sign on your door really only applies to one device (the 
door). It doesn't affect your phone or your pager, or the IM on your PC.

> it's behavior differs from A's.

You want that interpretation. The fireman, your subordinates, your 
assistant, and the CEO of your company probably interpret it different 
ways, and you want them to.

In an earlier note, you said you want to associate a status like "Away" 
to the presentity as a whole, independent of any device. But that 
requires you to define what the presentity is away from. Human being are 
always *somewhere*, so they are never abstractly away.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jan 2003 16:33:51 -0500

> presentities, for example (sip:[email-masked]).

I also looked at 2778 to clarify my thinking. A presentity need not 
represent a person. A single presentity could represent a group. So I 
would be inclined to say that an address like 
sip:[email-masked] (or pres:[email-masked]) 
should be viewed that way. Such a presentity may have many devices, and 
each may have independent status - some OPEN, some CLOSED, some AWAY, 
some DND.

Alternately, it would be possible to represent the same group presentity 
with a single virtual device, and a single set of status values 
representing the aggregate status of the group. In this case, the 
contact address of the device might be an Address of Record serviced by 
a forking proxy, that will route calls, messages, etc. to one of the 
members of the group.

Either approach is valid - two different ways to employ presence.

But neither of these has a tuple representing multiple presentities. 
Tuples by definition all pertain to (parts of) a single presentity. I 
see no reason to change that.

> represent,

Not entirely. But it is only standardized representations that are 
likely to be useful when interoperating between different IM systems.

A given IM system, when examining presence status for a buddy, is at 
best going to look through the tuples, pick out what it understands, and 
ignore the rest.

One level of standardization will be the <contact> element. If a contact 
is present and the system doesn't understand how to use the address, 
then it will probably ignore the tuple. If it does understand the 
address, it will look at the other status elements of the tuple to 
figure out what options to provide its user for interacting with the buddy.

Tuples that don't identify a device are more problematic. Do the status 
values contained merely require display? Do they affect options made 
available to the user? Do they in some way affect the other tuples?

 > and (2) do we need to standardize the relationships between

I'm not sure if you are suggesting an extension that literally permits 
tuples to be nested within tuples, or some sort of tagging and 
referencing notation that defines graphs between the tuples. I guess 
either is technically possible within the scope of the existing PIDF 
definition.

But either way this adds considerable complexity to the model. I am very 
reluctant to do this without stronger evidence that it is needed.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jan 2003 16:44:57 -0500

Jonathan Rosenberg wrote:
> 
>>> To me, this suggests that my device is modeled as two separate 
>>> tuples. One for voice, with a status of CLOSED, and one with IM, with 
>>> a status of open. This would, perhaps, need some way to allow the 
>>> watcher to correlate these two so as to know that they represent the 
>>> same physical device. Indeed, one might envision "device" as another 
>>> status itself! So:
>>>
>>> <tuple id="99s8">
>>>   <basic>OPEN</basic>
...
>> devices for equality I can just as easily compare two contact 
>> addresses for equality.
> 

Well, for one thing it seems stupid to put both capabilities in the same 
device, but give them separate addresses - thereby preventing them from 
being used together in a single call. But just because it is stupid 
doesn't mean it won't be done...

But in this case is there any value in describing it as one device with 
two addresses, rather than simply as two devices each with an address? I 
don't think so.

> of what a tuple really is modelling.

I don't disagree. I think we can start by at least agreeing on what we 
mean by tuples that contain a contact address.

>> Otherwise, things get messy if I potentially want to use multiple 
>> media. Then I have to look for all tuples representing the same device 
>> and combine their statuses before deciding if the device is suitable 
>> for my needs. And then I must still deal with the potential for 
>> conflicting status values between those tuples. It isn't an unsolvable 
>> problem, but is it better than simply permitting availablility 
>> information for each medium? The callerprefs stuff can already do that.
> 

I am slightly troubled by what if any difference there is between a 
device that is closed and one that is open but that has indicated no 
media are available.

I am somewhat comforted by 2778, which says that these status values may 
be implicit. (It gives the example of inferring OPEN or CLOSED by the 
presence or absence of a COMMUNICATION ADDRESS.)

Beyond that I am not sure what you are getting at here.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Jan 2003 16:33:42 -0600

Jonathan Rosenberg wrote:
> I REALLY don't understand what it means for a presentity to be online 
> or offline.

Okay, so let's tackle this first.  Bear in mind the current presence
model espoused by Yahoo! Messenger and MSN Messenger.  In it, *I* am
the presentity.  My presence status is offline if I am not available
(i.e. I have not logged into Yahoo or MSN Messenger), or it is online
(and further qualified) if I am available.  This is the model that I
find powerful and easy to use.  The main actor is the presentity itself
(i.e. me); not the PC, or the IM client or any other device.

In the current generation of presence systems, the status of the
presentity (i.e. the person) can be easily deduced because they
simply command only one device -- the PC.  Cell phones, PDAs, etc.
are distinct communication devices which are currently NOT tied into
the presence infrastructure.  Thus directives like DND do not work
because the cell phone does not know my availability.

I believe that in simple WG things are more complex since many more
devices besides a PC will contribute to presence (and availability).
When the presentity wants to assert its availability (i.e. DND, Busy but
interruptible, Available) it should be able to do so by forcing all the
devices to comply accordingly -- perhaps by simply uploading a CPL
script to a proxy, or actively sending messages to to individual devices
telling the phone to redirect calls to the voice mail server and telling
the IM UA to save IMs for later delivery.  Maybe this is too complex to
achieve in real life, but that was my vision of a presentity-centric
model.

> As Jonathan put it, people don't have Ethernet ports sticking out of

We can easily fix that through chip implants :-)

Cheers,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Jan 2003 16:46:48 -0600

> available to the user? Do they in some way affect the other tuples?

This is what I have been getting at -- a tuple that represents a
person.  The status values contained certainly need to be displayed,
and they should affect other tuples.  How they effect them is
the question.  If I want to represent my status as DND, I would
like to tell all my devices to stop accepting calls/IMs/smoke
signals, etc.  Not sure if we can do this in a standardized manner
today.

> reluctant to do this without stronger evidence that it is needed.

The only evidence we have right now is how comfortable is the average
user (not us in IETF) to systems like Yahoo Messenger and AOL.  The
model in these systems revolves around the person, not the devices.

Regards,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jan 2003 18:17:38 -0500

> or when it might be available again ("meeting ends in 20 minutes").

I generally agree with this, though representing all of this 
information, and making clients that can encode, decode, and utilize it 
in a productive way may be quite an agressive goal.

However I think this category is about the device, not the person. The 
availability of the person is something separate. (more below)

It is definitely necessary to represent media that are not available now 
but that might be available later to get any value out of a status like 
"Out to Lunch". I wrote about this earlier. (What value is there in 
knowing you will be back from lunch soon if I don't know if you are ever 
capable of communicating in the way I require?)

> also how long until anticipated completion.

I guess "Out to Lunch" falls into this category. It doesn't necessarily 
imply unavailability to communicate either. (You may be able to call me 
at my cell phone while I am at lunch if you don't mind listening to me 
chew.)

> definable as a list for a particular software), others are pre-defined.

Going that far scares me. Pretty much a guarantee that we will never 
complete this task.

> derived from a real-time blood-pressure input. (:-), if that's needed.)

Does Do Not Disturb fit in here? I think so.

> TV"), etc., but I suspect we all agree that those are beyond the current 

Another one that seems to be important is Active/Inactive - derived from 
observation of behavior rather than explicitly set. So you can send me a 
message but I may not respond, or you can call me but I might not answer.

Henning Schulzrinne later wrote:
> - not availabl

I'm not sure this is another dimension, or bits and pieces of other 
dimensions. Nor am I sure whether you intend this to describe the device 
or the person.

I think there may be value in describing the person (if any) as 
available/unavailable. This is something like active/inactive but is an 
explicit assertion rather than inferred. (All combinations of the two 
are possible.)

But available-store-and-forward seems different. This can be represented 
many different ways. One way is with a separate tuple representing a 
recorder or voicemail system. This might be a common way to handle it 
for voicemail. It may also be an appropriate solution for IM in some 
cases, such as when you are on vacation, or your normal IM device is 
offline for some other reason. But it may not cover the case where your 
IM device is online but you are away. In this case the device may simply 
accept IM on your behalf - in effect it is acting as the independent 
recording device would, but isn't a separate device.

I don't yet see how to describe this. It is a device that both is and 
isn't an automaton.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jan 2003 18:36:24 -0500

Vijay K. Gurbani wrote:
> Paul Kyzivat wrote:
> 
>> Tuples that don't identify a device are more problematic. Do the 
>> status values contained merely require display? Do they affect options 
>> made available to the user? Do they in some way affect the other tuples?
> 

You are leaping to an unjustified conclusion. Just because a tuple 
doesn't identify a device, that doesn't mean its status applies to the 
presentity as a whole. It might be a tuple that doesn't identify the 
device because its status is CLOSED and the device address is irrelevant.

It is even more of a leap to assume that a tuple without a device should 
affect tuples that do have devices.

We *might* find we need a way to define hierarchical tuples (as Jonathan 
suggested). If so, then the status in a parent tuple may affect, 
supplement, or supercede the status of a child tuple. We have yet to 
conclude that is a good thing. You are the only one strongly advocating 
it, and I don't think you have yet convinced anyone else.

> 
>> But either way this adds considerable complexity to the model. I am 
>> very reluctant to do this without stronger evidence that it is needed.
> 
> 

The reason it isn't complex in any of those systems is because the 
presentity and the only device are unified.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jan 2003 18:46:38 -0500

> (i.e. me); not the PC, or the IM client or any other device.

No. The main actor is indeed also the IM client, since the applications 
are one and the same.

> because the cell phone does not know my availability.

So far you haven't answered the first question that you said you wanted 
to answer.

> achieve in real life, but that was my vision of a presentity-centric

I think you are saying the presentity is online when it is connected to 
a presence controller. This is irrelevant to any presence client - they 
are not affected in any way by this - only by the presence status changes.

Or maybe you are suggesting that the presentity is online with a device 
that can control the behavior (not just the status) of all the devices 
described in the presence of the presentity. As you say, the likelihood 
of this is slim, but if it were true then the status of the presentity 
itself wouldn't be necessary because it could explicitly control the 
presence status of all the devices.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Jan 2003 03:52:45 -0500

> availability of the person is something separate. (more below)

I'm assuming that each person has zero or more devices.

> at my cell phone while I am at lunch if you don't mind listening to me 

That's why I separated it into two categories - the two are not 
orthogonal, but they are not deterministic functions of each other, either.

> Going that far scares me. Pretty much a guarantee that we will never 

I should have a proposal soon. I don't think it is that bad.

> Does Do Not Disturb fit in here? I think so.

On a per-person basis, I agree.

> message but I may not respond, or you can call me but I might not answer.

Agreed; that's another device property, I believe.

> dimensions. Nor am I sure whether you intend this to describe the device 

Device. I may be available in real-time for IM, store-and-forward for voice.

> explicit assertion rather than inferred. (All combinations of the two 

This would seem to override all per-device communication availability.

> recording device would, but isn't a separate device.

This is a device property, orthogonal to the media capability. Thus, 
each device has this property. The whole point of SIP is not to expose 
the low-level addresses of all my devices.

> I don't yet see how to describe this. It is a device that both is and 

Being in s&f mode is a property of the device. This isn't unusual - 
after all, your phone with a built-in answering machine is also both, 
depending on my mood, call screening or physical presence.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 17 Jan 2003 11:38:13 -0600

Paul Kyzivat wrote:
[...]
> presentity as a whole. 

That's because the representation of the tuples is currently not
hierarchical.

> it, and I don't think you have yet convinced anyone else.

Not for the lack of trying :-).  But seriously, clearly there are status
codes like "Out to lunch" (MSN Messenger), "Be Right Back" (MSN
Messegner), "Not at home" (Yahoo!), "Not at my desk" (Yahoo!),
"On vacation" (Yahoo!) that make no sense for a device at all.  They
do, however, make sense for a person.

So why is there such a push to NOT add a tuple representing the person?
And in fact, to make it hierarchical such that the status of the person
over-rides that of the individual devices.

There will be cases where the state of the person can be deduced
from interpolating the state of individual devices ("Busy but
interruptible), and cases where the state of the person can be
authoritatvely enforced on the devices ("Do not disturb").  The
person-centric hierarchical model makes this easy to represent
(admittedly not easy to realize currently).

Ultimately, regardless of all the devices, it is the presence state
and availability of the person that is being sought.  That should
be the crux of the model.

> presentity and the only device are unified.

Isn't that what we are striving for in simple -- a unified view of
the myriad devices that a person commands?

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 17 Jan 2003 11:47:26 -0600

Paul Kyzivat wrote:
[...]
> are not affected in any way by this - only by the presence status changes.

But the *user* using the presence client is affected by the changes.
A presence client serves to provide presence information of others to
someone, most probably a human being, who can be affected by the
fact that another user is online or offline.

> presence status of all the devices.

Sometimes it may NOT want to control the presence status of all the
devices, other times it may.  DND is a good example of when a person
wants explicit control of all devices.  Busy-but-interruptible is
an example of when the status of the person can be interpolated from
the status of the individual devices.

Cheers,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Jan 2003 14:38:15 -0500

OK, after thinking about this I have a proposal that covers many of the 
issues that have emerged. It is influenced by many things, most recently 
Henning's comments in his "Stepping Back" note. (And Vijay *has* 
succeeded in convincing me that there are *some* status attributes that 
aren't associated with any device.)

I see the following categories of status attributes:

* Device specific status - belongs only in a <tuple> that also contains
   a <contact> element:

   - a <prescaps> element as defined in
     draft-lonnfors-simple-prescaps-ext-00, or equivalent.
     This includes, among other things, an indication of what
     media are available at the device to be used right now.

   - an element (<activity>?) indicating activity of the presentity
     in proximity with the device. (active/inactive). This
     is intended as an automated hint of likelihood that
     presentity is attending to the device.

   - an element (<availability>?) indicating explict availability
     and willingness of the presentity to communicate using this
     device (available/unavailable). (Perhaps this should be a
     probability - number between 0-1.)

   - an element (<autoresponse>) indicating ability of device to
     handle communication requests in the absence of the presentity.
     (available/unavailable). (This is voicemail for voice.)

* Status that can go in any tuple:

   - elements indicating current tasks the presentity is involved with,
     and/or general willingness to communicate. Chosen from an
     enumeration (TBD). (This covers "out to lunch", "on vacation",  "Do
     Not Disturb", "On the Phone", etc. These do not imply any particular
     behavior - that is indicated via device specific status.

   - geoloc information (TBD)

   - an element (<future-status>?) specifying expected future status.
     This contains an optional timestamp indicating when it will take
     effect. It also contains other status elements. (If it contains
     device specific status it must go into a device specific tuple.)

The <future-status> element handles a number of things. If you are Out 
to Lunch and unavailable right now, it can specify that at 1:00 you will 
be available. If you are "On the Phone" now, and so are not indicating 
support for voice, it can indicate that you will be available for voice 
later, though you can't say when. And if you are going to be leaving the 
office at 7:00, it can indicate that then you will be unavailable.

There is some overlap between the <autoresponse> element and the 
voicemail callerpref. But callerprefs currently can't specify that a 
single device may handle calls directly or via voicemail. It may be 
better to fix this in callerprefs and then import that via <prescaps>.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 20 Jan 2003 10:49:11 -0600

> aren't associated with any device.)

Paul:

Thanks for the proposal; I think you cover a large part of what has
been discussed during the last week.

More inline.

>     probability - number between 0-1.)

If we make it a probability, how does this interact with the <contact>
attribute 'priority'?  If the intent is to represent the presentity's
(read: person's) explicit availability and willingness to communicate, I
think we should leave it as a binary choice.

>     behavior - that is indicated via device specific status.

This tuple will then represent the status of the person itself, right?
Strict reading of rfc2778 implies that a PRESENTITY is simply a client
that provides presence information to be stored and distribued.  The
status enumerations you mention above (DND, Out to lunch, ...) apply to
what rfc2778 calls a PRINCIPAL.  So, a tuple (there should be only one)
in a <presence> element without any <contact> represents the PRINCIPAL.
Right?

Cheers,

- vijay

---

From: Michael Hammer <[email-masked]>
Date: Mon, 20 Jan 2003 13:25:55 -0500

All,

Very interesting reading this thread from beginning to end.  A couple of 
observations:

There seems to be three main elements here:

1) Devices are OPEN/CLOSED to communications, note that for the user/group 
level, to be open means that at least one device type must be OPEN to 
communicate with, which may infer that a device type of "Face-To-Face" with 
geo-info is needed;

    Note: OPEN means your request will be handled,
    CLOSED means your request will be silently discarded.

2) Devices have ACTIVITY (or lack thereof) associated to them), two 
possible indications are:
    a) time since last activity: can be derived and reported automatically
    b) time when next activity can be expected: can be manually set and 
reported

    Note: Each of these activity indicators can be
    quantitatively detailed as in a timestamp or
    qualitatively on some order of magnitude time-scale of
    minutes, hours, days, or    "soon", "in a while", or "not for a long time"

3) The device user has a PREDISPOSITION to communicate that may be device 
associated and corresponds to three different degrees:

    a) DND is device specific and corresponds to CLOSED, meaning if you 
send the message or INVITE it will get trashed automatically.  That is 
consistent with its use in telephone networks.  DND means my phone won't 
ring.  If you don't want your cell phone going off in church then turn it 
off.  If you set this at presentity level, then that should drive all 
devices (except maybe for FTF geo=CEO office) to CLOSED state.

    b) "Busy/Away/Whatever" corresponds to OPEN and depends on the caller 
or communication purpose.  So, a communication attempt will be alerted to 
the human, but may not result in a positive or immediate response.  Or, it 
will get received and handled according to local policy.  A text status can 
provide for unlimited excuses as to why that presentity/device may not be 
responsive to real-time attempts.

    c) "Available" means that any and all "callers" will get through and 
alert the user, who may or may not be immediately available and may or may 
not choose to answer the communication request.

The above predispositions may be associated with particular devices or to 
the presentity as a whole, in which case it applies to all devices 
associated.  Last, it might be useful to treat the voice-mail, e-mail, and 
any other non-interactive store-and-forward mechanism as a separate 
device.  Thus, setting phone device to CLOSED, but leaving voice-mail 
device OPEN tells any caller what will happen if they call that user.

The above three attributes can be automatically or manually controlled 
through the application.  I have attempted to digest the thread through my 
lenses.  Did I not account for anything?

Mike Hammer

At 10:49 AM 1/20/2003 -0600, Vijay K. Gurbani wrote:
>>The <future-status> element handles a number of things. If you are Out to 
>>Lunch and unavailable right now, it can specify that at 1:00 you will be 
>>available. If you are "On the Phone" now, and so are not indicating

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 20 Jan 2003 12:51:04 -0600

[...]

Michael:

Accurate reading indeed.

> consistent with its use in telephone networks.  
> If you set this at presentity level, then that should drive all 
[...]
> The above predispositions may be associated with particular devices or 
> to the presentity as a whole, in which case it applies to all devices 
> associated.  

That is exactly what I have been arguing in favor of in this thread.
The presentity (read as: PRINCIPAL, user, person, ...) is the center of
the presence/availability hub.  Setting something like DND at the
presentity level and having it percolate down to the devices (in either
some automagic manner or not) is extremely useful.  We may not be able
to do this currently, but we should not preclude it from happening in
the future.

Likewise, providing something like DND-except-dept-secretary is easier
to implement (using filters or whatever) if we allow the presentity
to actively control it's status at times.  Of course, there will be
times when the presentity is perfectly fine with letting the system
dictate the best way of reaching it.

> Last, it might be useful to treat the voice-mail, e-mail, 
> and any other non-interactive store-and-forward mechanism as a separate 
> through the application.  I have attempted to digest the thread through 
> my lenses.  Did I not account for anything?

I think this is an excellent synopsis.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jan 2003 13:59:15 -0500

inline...

> think we should leave it as a binary choice.

The callerprefs use of Priority doesn't work very well at all. It is 
backwards in terms of who is in control. The caller is free to specify 
whatever priority he wants for his request, while the callee gets to 
specify where requests of a particular priority might go. Jonathan has 
been able to come up with a couple of use cases where this might provide 
some untility, but they are pretty contrived, and depend on goodwill of 
all parties.

What I have in mind here isn't like that. It isn't trying to control who 
will be answered, just the likelihood that a request will be answered. I 
may not have this characterized quite right yet.

The extremes of 0/1 (unavailable/available) are pretty easy to 
understand. The points inbetween may only be useful in specialized 
situations. But I have such a specialized situation in mind:

I want to use presence for routing calls to agents in a call center. In 
the case of voice calls, availability in this case is binary - an agent 
on the phone isn't available for another call. But it isn't necesarily 
so when the 'calls' are for IM sessions. A call center agent can usually 
handle more than one IM session at a time. But I would like to be able 
to distinguish between two otherwise equal agents when one is already in 
an IM session and another is not. In some sense the one that is already 
in an IM session may be viewed as less available for another session.

> in a <presence> element without any <contact> represents the PRINCIPAL.

This is a little tricky. If you read 2778 closely you will see that 
there is no guaranteed 1:1 relationship between a PRESENTITY and a 
PRINCIPAL - it may be 1:n. One example of this is a shared 'line' in an 
office - where any of several people may pick up an incoming call. 
Another case is a human and a voicemail system both dealing with the 
same line - both may be considered PRINCIPALS by 2778.

I think the only thing we can say about this is that it is status 
associated with the presentity. I'm not sure we can/should even require 
that there only be one instance of this kind of status. I believe the 
interpretation of this will have to be pretty subjective. Some examples:

- you may have a presentity (ores:[email-masked]) representing you, with 
several devices. You might add a separate tuple specifying Out To Lunch.

- there may be a presentity representing a shared office line 
(pres:[email-masked]) with several devices each representing a sales 
person at acme.com. Several individual salesmen may specify Out To 
Lunch, each in the tuple representing their respective device.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jan 2003 14:23:22 -0500

inline...

	Paul

Vijay K. Gurbani wrote:
>> consistent with its use in telephone networks.  If you set this at 
>> presentity level, then that should drive all devices (except maybe for 
>> FTF geo=CEO office) to CLOSED state.
> 
> [...]
> 

This may indeed be good behavior for an implementation of a 
communication system that includes presence. But it is out of scope for 
the presence spec itself.

Presence is a protocol for *reporting* presence status, and for 
receiving those reports. It is not a protocol for controlling the 
devices described.

When I hang a DND sign on my door, I MAY lock the door, disconnect the 
phone, and put on earplugs so that it is impossible to disturb me. But I 
may equally well just leave the door unlocked and depend on people to 
use their best judgement about whether to ignore my preference and barge 
in. It seems reasonable that the same sorts of options ought to be 
available to users of presence systems.

---

From: Michael Hammer <[email-masked]>
Date: Mon, 20 Jan 2003 14:59:05 -0500

Paul,

Agree that the mechanism for enforcing is out of scope.  But the presence 
indication/report should: say what you mean, and (enforcement) mean what 
you say.  The other party should have some degree of assurance of what will 
happen on your end based on the status they get.  Otherwise such statuses 
might as well be randomly set.

If you report DND, but allow alerting the user who then answers the phone, 
the other parties will soon learn to ignore such an indication.  To me, the 
question is one of whether the device will alert the user or 
not.  Alerting, by its very nature IS disturbing.  This is a contradiction 
in terms.

Thus, if the other party is expecting to be able to initiate a 
communication request, but can expect that there is a slight chance of 
response, then call it something else, e.g. 
Predisposition=policy-based-alerting-only.  (Your call might alert me, but 
might not, depending on my policy.)

Maybe this is mincing definitions.  You probably want something like 
"DND-with-exceptions" that would leave the status as OPEN with some 
requests, but CLOSED to others.

Mike

At 02:23 PM 1/20/2003 -0500, Paul Kyzivat wrote:
>This may indeed be good behavior for an implementation of a communication 
>system that includes presence. But it is out of scope for the presence 
>spec itself.
>
>Presence is a protocol for *reporting* presence status, and for receiving 
>those reports. It is not a protocol for controlling the devices described.
>
>may equally well just leave the door unlocked and depend on people to use 
>their best judgement about whether to ignore my preference and barge in. 
>It seems reasonable that the same sorts of options ought to be available 
>to users of presence systems.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Jan 2003 16:22:20 -0500

This seems like a good capture of much of what is being discussed. It is
definitely hard to follow these threads since we are covering a lot of
really different topics all interspersed.

In addition to what you have below, there has also been a bunch of
discussion on DND, and how that relates. Also, much discussion on the
need for hierarchies of tuples and what they represent.

Really, our first task in SIMPLE here is to scope this work. Hopefully,
some of that will result from distilling concepts into uses of a small
set of status types. Others we will simply need to declare out of scope
for now.

A few comments on selected points:

ON AVAILABILITY

I'd like to first comment on this available status you discuss. I don't
see how it is different from the basic OPEN/CLOSED status. I also don't
see how the probability helps. Paul had given an example use case:

 > I want to use presence for routing calls to agents in a call center.
 > In the case of voice calls, availability in this case is binary - an
 > agent on the phone isn't available for another call. But it isn't
 > necesarily so when the 'calls' are for IM sessions. A call center
 > agent can usually handle more than one IM session at a time. But I
 > would like to be able to distinguish between two otherwise equal
 > agents when one is already in an IM session and another is not. In
 > some sense the one that is already in an IM session may be viewed as
 > less available for another session.

To me, this is not really a probability, so much as an expression that
availability is conditional on some other characteristics of the call.
It is this kind of need which motivated my proposal to support "virtual
devices". The primary purpose of those virtual devices would be to
represent (using the callerprefs attributes) the conditions to which the
OPEN/CLOSED status would apply.

ON ACTIVITY

I'd next like to comment on what you call "activity". I think there is a
need for some type of standardization to support this concept. There are
several different ways in which the concept can be quantified:

   * the amount of TIME since the presentity last interacted with the device
   * the physical DISTANCE of the presentity from the device
   * the PROBABILITY that a communications request to the device will be
answered by the presentity

I think existing IM systems very much rely on the TIME definition.
However, in my experience that definition is heavily tied to the concept
of a PC application. On a cell phone, where the user normally does not
interact with the device continously, this tends to a poor definition.
For cell phones, the DISTANCE is a better measure, but even that is not
neccesarily a good one. The phone may be near me, but its tucked away
into a laptop bag and so I really am idle with respect to it, since I
can't hear it or reach it.

Arguably, one approach is to separate the means for measuring "activity"
or "idleness" from its representation. Using something like a
probability, for example, would allow the metric to work across devices,
and for it to be measured differently for different devices.

Another issue to be factored into the decision about how to represent
idleness is how frequently it needs to be reported to the watcher in
order to be useful. A time-based measure has the nice benefit that the
watcher can continously know how long the presentity has been idle,
simply by conveying the time of last activity in the presence notifications.

One final point on activity. Some have stated that the defining
characteristic of this status is that it is implicitly computed by the
system. I disagree. I think it may be perfectly valid to set it explicitly.

ON DND

DND has received a bit of discussion on this thread. To be honest, I am
at a loss as to why it is not really a combination of two things: (1)
basic status of CLOSED for each device, and (2) a "task" of "do not
disturb". Paul has defined these tasks as things that describe what the
presentity is doing, such as "out-to-lunch". "do not disturb" seems like
another example.

It is the usage of the basic status of CLOSED that really captures the
essence of DND - that attempts to contact with that user across their
devices will fail.

ON STORE_AND_FORWARD

Paul has proposed that store-and-forward (what he calls autoresposne)
become a special status type for a device. An alternative is to use the
caller prefs attribute for this (formerly voicemail, now called
msg-server). THis is not quite the same thing. The voicemail/msg-server
attribute says "this device IS a voicemail server", and not "if you
contact this device, and no one answers, the call will go to voicemail".
The latter is an expression of application logic running in a proyx
which cannot be concretely known by the device itself. Thus, its not
appropriate IMHO as something to represent in caller prefs. It may very
well be useful to represent in PIDF, since it is the type of thing that
a PA might know, as it has a broader view of the presentity across all
devices.

Indeed, "auto-response" is just an expression of an application that is
running on calls to that device. THere are other applications running
that might be of interest. Lets say I have a cell phone and a home
phone. I am running CFNA on my home phone, to my cell phone. Perhaps we
might like to express in PIDF that this will happen. Supporting such
things would argue for representing "voicemail" as another device, and
then defining extensions that indicate that call forwarding logic occurs
from one device to another. Such a capability in PIDF would capture both
the autoresponder semantic and inter-device forwarding rules.

What about other applications, such as voice recorders or call blocking
applicatoins? DO we need to signal those too? As a matter of scope, I am
inclined to treat this whole set (including auto-responder) as out of
scope for this first cut.

ON HIERARCHIES

I have proposed that another axis of extension for PIDF is to allow
hierarchies of tuples. This is a superst of the concept Vijay G has been
advocating, of defining a special type of tuple to represent a person.

On this point, Paul K wrote:
 > sip:[email-masked] (or
 > pres:[email-masked]) should be viewed that way. Such a
 > presentity may have many devices, and each may have independent
 > status - some OPEN, some CLOSED, some AWAY, some DND.

Ultimately the group presentity is represented through multiple devices,
but those devices each "belong" to other, different presentities. The
value in the hierarchy is being able to express the relationships
between these things. I think its valuable to be able to subscribe to
pres:[email-masked], and for notifications to be capable
of indicating any of the following:

    * customer support is available now for calls and IM, here is the
cotnact address.
    * customer support is available, and is made up of bob, judy and
bill. Here are the contact addresses for bob, judy and bill as presentities
    * customer support is available, is made of up of bob, judy and bill.
Bob has a cell phone and IM device. He is available on the IM device,
but not the cell phone.

A "group" presentity differs from a "user" presentity in that it can
have "user" presentity sub-tuples, and that certain status types apply
to it alone. For example, I would like to have a "percentage OPEN"
status, which indicates the percentage of the members of the group which
are available right now. That definition makes sense for a group, but
not a single user presentity.

 > I'm not sure if you are suggesting an extension that literally
 > permits tuples to be nested within tuples, or some sort of tagging
 > and referencing notation that defines graphs between the tuples. I
 > guess either is technically possible within the scope of the existing
 > PIDF definition.

I had in mind literal nesting, as this is natural for XML. Of course 
either would work. Its a detail. It is far more important to determine 
if hierarchical tuples are a useful concept, and if we wish to pursue 
them now or later.

-Jonathan R.

Paul Kyzivat wrote:
 > OK, after thinking about this I have a proposal that covers many of
 > the issues that have emerged. It is influenced by many things, most
 > recently Henning's comments in his "Stepping Back" note. (And Vijay
 > *has* succeeded in convincing me that there are *some* status
 > attributes that aren't associated with any device.)
 >
 > * Device specific status - belongs only in a <tuple> that also
 > contains a <contact> element:
 >
 > draft-lonnfors-simple-prescaps-ext-00, or equivalent. This includes,
 > among other things, an indication of what media are available at the
 > device to be used right now.
 >
 > - an element (<activity>?) indicating activity of the presentity in
 > proximity with the device. (active/inactive). This is intended as an
 > automated hint of likelihood that presentity is attending to the
 > device.
 >
 > - an element (<availability>?) indicating explict availability and
 > willingness of the presentity to communicate using this device
 > (available/unavailable). (Perhaps this should be a probability -
 > number between 0-1.)
 >
 > - an element (<autoresponse>) indicating ability of device to handle
 > communication requests in the absence of the presentity.
 > and/or general willingness to communicate. Chosen from an enumeration
 >  (TBD). (This covers "out to lunch", "on vacation",  "Do Not
 > Disturb", "On the Phone", etc. These do not imply any particular
 > The <future-status> element handles a number of things. If you are
 > Out to Lunch and unavailable right now, it can specify that at 1:00
 > you will be available. If you are "On the Phone" now, and so are not
 > indicating support for voice, it can indicate that you will be
 > available for voice later, though you can't say when. And if you are
 > going to be leaving the office at 7:00, it can indicate that then you
 >  will be unavailable.
 >
 > _______________________________________________ Simple mailing list
 > [email-masked] https://www1.ietf.org/mailman/listinfo/simple
 >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jan 2003 16:24:35 -0500

Michael Hammer wrote:
> 1) Devices are OPEN/CLOSED to communications, note that for the 
> user/group level, to be open means that at least one device type must be 
> OPEN to communicate with, which may infer that a device type of 
> "Face-To-Face" with geo-info is needed;

Hmm. That seems a little odd. OPEN is currently defined relative to 
communication with a <contact>. What kind of communication can you 
specify if you have the geoloc but no functional url?

Interestingly, 2778 suggests that OPEN might be encoded implicitly, such 
as via the presence or absence of a contact. Perhaps geoloc could be be 
represented via a URL that encodes spatial coordinates, and with that 
sort of URL open/closed is dependent solely on presence of the contact.

>    CLOSED means your request will be silently discarded.

I don't think you can be that specific about CLOSED. When you go home at 
night, you may want to report the status of your desk phone as CLOSED, 
but it may well still ring if called.

Or do you think the phone in that state ought to be OPEN & UNAVAILABLE?

>    minutes, hours, days, or    "soon", "in a while", or "not for a long 

I don't think activity has to do with the device itself. It has more to 
do with the PRINCIPAL that controls the device.

(a) and (b) are independent variables. My device may notice I am active, 
yet I may still refuse to communicate. (E.g. I'm eating lunch at my 
desk, and refusing to answer the phone.) However, while they are in 
principle independent, a presence UA may manage them in a way that 
couples them - such as refusing to report current activity when its been 
told that I'm unavailable.

> 3) The device user has a PREDISPOSITION to communicate that may be 
> device associated and corresponds to three different degrees:
> 
> ring.  If you don't want your cell phone going off in church then turn 
> it off.  If you set this at presentity level, then that should drive all 

I agree that a DND button on a phone may both set presence to DND, 
disable the ringer, and possible cause a 486 or 401 to be returned 
automatically. But I'm not convinced we can or should require that behavior.

I might instead want my DND button to disable the ringer but still 
discretely flash a light.

> or communication purpose.  So, a communication attempt will be alerted 
> to the human, but may not result in a positive or immediate response.  
> Or, it will get received and handled according to local policy.  A text 
> status can provide for unlimited excuses as to why that 
> presentity/device may not be responsive to real-time attempts.

I think you are coupling too many things. If DND doesn't imply CLOSED, 
then DND+CLOSED means one thing, while DND+OPEN means something different.

A specific status for DND+OPEN is probably better than simply using 
OPEN+UNAVAILABLE+TEXT because it can be more easily internationalized.

> alert the user, who may or may not be immediately available and may or 
> may not choose to answer the communication request.

It isn't enough to have Available mean "will ring". We need a way to 
distinguish between Will Probably Be Answered and Will Ring But Probably 
Won't Be Ansereed. I believe that AVAILABLE+ACTIVE means Will Probably 
Be Answered, while both UNAVAILABLE and AVAILABLE+INACTIVE mean Will 
Ring But Probably Won't Be Answered.

> to the presentity as a whole, in which case it applies to all devices 

There is currently no way in PIDF to associate statuses with the 
presentity as a whole - every tuple stands on its own.

> device OPEN tells any caller what will happen if they call that user.

If these are in fact distinctly addressable devices then this is already 
possible, and they can be distinguished via callerprefs. This is 
problematic if you reach both through the same device. Using two tuples 
with the same address raises messy issues of how to combine the statuses 
when a device address is repeated.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jan 2003 17:34:19 -0500

Jonathan & others,

I've trimmed and reordered Jonathan't message for clarity of response. 
Comments inline.

	Paul

...
 > if hierarchical tuples are a useful concept, and if we wish to pursue

Of all the points you raise, I think this has the most potential impact, 
because it makes a larger change to the model defined by 2778. (For 
instance, introducing hierarchical tuple structures also affects how 
they might be selectively updated.)

There are a fair number of things that can be accomplished without 
introducing hierarchies, but there are also goodies that are only 
possible with them. We need to decide if the benefits justify the cost 
in added complexity.

On one hand I like the representational power, which would be good for 
complex applications of presence that I am pursuing. But, it may make 
the construction of a simple presence client so complex and obscure that 
SIMPLE isn't adopted by popular presence clients. That would be very bad.

As we have been talking about all the alternatives, I have been trying 
to imagine how one of the existing presence/IM clients could evolve to 
set and display this information.

The setting side is a bit simpler, because it isn't necessary to provide 
a way to set every weird combination of status values that is legal. But 
the displaying of buddies is important, because some of those buddies 
will have their status constructed using features this client doesn't 
set for itself. Just representing a buddy with multiple tuples is 
somewhat of a challenge. But I think it can in general still map to a 
single line per presentity on a display, with multiple icons 
representing status elements from all the tuples, together with some 
simple grouping notation. Of course that will start to break down as the 
number of tuples goes up.

Maybe hierarchical tuples can be handled the same way, but the size will 
start to get out of hand sooner.

Maybe this could be handled with a sort of 'tree control' such as is 
used by file browsers. I'm not sure how good the human factors could be 
made for this. (Do I have to drill down to find something I can actually 
send a message to? It depends on whether my client is or is not willing 
to take on the role of a forking proxy.)

> but those devices each "belong" to other, different presentities.

They are controlled by different PRINCIPALs, but they are only 
represented by different PRESENTITYs if we make the changes to support 
that. You can make a viable system without that, and in some cases you 
really don't want those principals to have independent presence.

 > The

Both of the above are representable with the existing two level 
hierarchy of presentity/tuple. (Except that in the 2nd case it isn't 
their addresses as presentities that you are providing - it is their sip 
address - probably address of record - that you give.)

> Bob has a cell phone and IM device. He is available on the IM device,

This could perhaps be represented by specifying three tuples, each 
containing a pres: url. But that is a bit of a stretch. This is the case 
that seems to cry out for hierarchical tuples.

I guess my personal preference is to go ahead and define hierarchies.

---

From: Michael Hammer <[email-masked]>
Date: Mon, 20 Jan 2003 18:29:44 -0500

Inline.

At 04:24 PM 1/20/2003 -0500, Paul Kyzivat wrote:

>communication with a <contact>. What kind of communication can you specify 
>if you have the geoloc but no functional url?
>
>represented via a URL that encodes spatial coordinates, and with that sort 
>of URL open/closed is dependent solely on presence of the contact.

OK, I confess I was coloring outside the lines.  I was responding to the 
idea that a presentity could be OPEN with all network devices in a CLOSED 
state.  Didn't know if there was some sort of abstract placeholder for 
human communication modes.

>night, you may want to report the status of your desk phone as CLOSED, but 
>it may well still ring if called.
>

If it is able to ring and someone could answer it, then it is OPEN and 
available.  An inactivity indication that a call hasn't been completed in 9 
hours (assuming a last call at 6pm as of 3am) would give the presentity 
viewer the clue that it is unlikely that I will answer.

>I don't think activity has to do with the device itself. It has more to do 
>with the PRINCIPAL that controls the device.

It could be at both levels.  But activity on one of my associated devices 
should trigger an update to my last activity indicator as an overall presence.

>yet I may still refuse to communicate. (E.g. I'm eating lunch at my desk, 
>and refusing to answer the phone.) However, while they are in principle 
>independent, a presence UA may manage them in a way that couples them - 
>such as refusing to report current activity when its been told that I'm 
>unavailable.

I see them as independent.  But, on second thought b) may be more of a 
predisposition type of indication.  I'm not sure what unavailable 
means.  Is that same as CLOSED or an indication of pre-disposition to not 
answer even though the device can accept calls?

>I agree that a DND button on a phone may both set presence to DND, disable 
>the ringer, and possible cause a 486 or 401 to be returned automatically. 
>But I'm not convinced we can or should require that behavior.
>

This begs the question of what constitutes a disturbance.  What about the 
converse?  If my IM is DND, does it ring instead of popping up on a screen? 
:)  Maybe I'm being draconian, but I would hope that a DND would prevent 
any attempts, while a lesser state may allow privileged persons to have a 
hope of getting through.  But as long as the semantic description and the 
expected behavior upon receipt of a subsequent attempt are consistent, then 
OK.  Is it not possible that two different presence recipients might get 
different indications with corresponding treatments upon attempts?

>>status can provide for unlimited excuses as to why that presentity/device 
>>may not be responsive to real-time attempts.
>

I was not agreeing with that premise.

>OPEN+UNAVAILABLE+TEXT because it can be more easily internationalized.

True, but I only suggested text to give vent to the various reason types 
that people have attachment to.

>Won't Be Ansereed. I believe that AVAILABLE+ACTIVE means Will Probably Be 
>Answered, while both UNAVAILABLE and AVAILABLE+INACTIVE mean Will Ring But 
>Probably Won't Be Answered.

This is where I saw the predisposition giving an explicit hint and the 
recent activity indication giving an implicit hint about 
probably.  Otherwise, it seems like a SWAG on the part of the application.

>>the presentity as a whole, in which case it applies to all devices associated.
>

Hmmm, I thought that each tuple would stand on its own and not necessarily 
get combined.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 21 Jan 2003 10:48:08 -0600

Paul Kyzivat wrote:
[...]
> I guess my personal preference is to go ahead and define hierarchies.

I'll second that.

Thanks,

- vijay

---

From: Ben Campbell <[email-masked]>
Date: Fri, 24 Jan 2003 10:52:05 -0600

Paul Kyzivat wrote:
[...]
[...]

I can verify the yahoo case. In fact, some people around my office have 
gotten so used to Yahoo's store and forward capabilities that they have 
forgotten how to use email. Furthermore, if people send you messages 
while you are invisible or even explicitly busy, you still get the 
messages immediately.