Subject: RE: Status discussion again RE: [Simple] Test message

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 13 Jun 2002 10:03:35 -0400

Your admin screening for a boss is one example of forwarding
decisions based on presence.   There are others:
	Voicemail diversion based on presence
	Forward to cellphone when I'm not in the office
	...

There are other things a remote party might do depending on my
presence.  One really rich vein is a group call (call out
ad-hoc conference).  How about:
	Don't call a person marked >="busy" on a group call-out
	Display who might not be able to respond to a group call
		before you place it
	Prompt for an IM when you try to call someone who is "on the phone",
		but put up an alert when you try to call someone who is DND.
	
Also consider an IM system on a PC and a SIP Phone on the same desk.
Presumably, there is one presence system shared among them which could
be three independent implementations (two watchers and one presentity).  
Thus "local" knowledge needs to be standardized to allow:
	Change alert mechanism for incoming calls (a simple example would
		be a more discreet alert if you were busy)
	Choose an appropriate voicemail greeting
	Don't set an alert if no one is there to see it
	Send an away message when an IM comes
	...

I think there is need to have a pretty well specified set of states,
hard though that may be.

Brian
	
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, June 12, 2002 10:51 PM
> To: [email-masked]
> Cc: 'Li Hua Tang'; 'DAO TRUNG Tin FTRD/DAC/ISS';
> [email-masked]
> Subject: Re: Status discussion again RE: [Simple] Test message
> 
> 
> Once again this one has stalled, but I think Adrian has captured the 
> essence of why below:
> 
> Adrian Bateman wrote:
> > On 31 May 2002 03:16, Li Hua Tang wrote:
> > 
> >>So can we summary status as below?
> >>Open
> >>    - availble  // always ready to chat
> >>    - away      // temporarily not available
> >>    - invisible // only available to someone I want to chat
> >>    - busy      // not ready to chat or no immediately response to
> > 
> > messages
> > 
> >>    - in call   // may ready to chat later
> >>Closed
> >>    - unavailable      // disconnect and can't chat
> >>    - do not disturb   // don't want to receive message but 
> close the
> >>channel
> > 
> > 
> > 
> > (Apart from the fact that invisible can't really be a state (visibly
> > invisible?) so should look just like disconnnected,) I'll try to
> > reiterate my thoughts on this discussion from a different tack.
> > 
> > Why is it important to try to distill the different IM status values
> > into a definitive set? I don't believe that the group will reach
> > consensus on a definitive minimal set because one person's busy is
> > another's do-not-disturb. Doesn't the benefit come from having a
> > *reasonably* small and *well-known* vocabulary for IM 
> status values? You
> > don't even really need to decide which are open and which 
> are closed -
> > PIDF allows for that already.
> > 
> > Perhaps rather than trying to find the set of status 
> values, attention
> > might be focussed on the reason for having such a set and the values
> > might fall out of that discussion?
> 
> This is the essence of the problem. We don't know *why* we want these 
> various status values. Until we know what kinds of things we 
> need to do 
> with them, it will be hard to determine what we want to do.
> 
> SO, I propose that we focus discussion instead on the things 
> that might 
> be done with such inforamtion. Most importantly, they are 
> things that an 
> automata would do, since anything else can be handled by the note.
> 
> * display icons appropriate to the status
> 
>    This would in fact argue for a set of common reasons, such 
> as "on the 
> phone" and "in a meeting", irregardless if they don't say 
> anything much 
> beyond CLOSED or OPEN in terms of the ability to receive an IM.
> 
> * Provide local language versions of the status
> 
>    Similar to the above item, it would require a set of 
> common reasons.
> 
> * have the secretary automatically connected to the boss in a phone 
> call, when the boss becomes available, where the *secretary* defines 
> available
> 
> This is an interesting one. TO date, our assumption was that 
> availability is the decision of the presentity; that it 
> decides whether 
> or not it wants to receive calls. THere is an argument to be 
> made that, 
> in the case above, for example, the watcher wants to determine what 
> availability means, based on "raw" information about the boss 
> - whether 
> they are in a call or not, in a meeting or not, and so on. In 
> order for 
> that to work, the secretary's application needs detailed 
> information on 
> what the boss is doing so that it can make a decision.
> 
> 
> 
> I am sure there are others; suggestions welcome, as well as 
> comments on 
> the above list. Again, I propose we focus on the usages for 
> the status 
> values, rather than on the values themselves.
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jun 2002 11:13:05 -0400

Another more extreme version of "forwarding decisions based on presence" is in a call center. What you really want is for the capabilities and capacity of each agent to be
reported via presence, and for a server to subscribe to this presence information for all candidate agents. Then it can make forwarding decisions based on optimizing across
all the candidate agents.

For this, you need rich presence information, about media supported, skills, loading, possibly cost. This is more information than is needed for most informal usage, but I
think these cases are merely the extremes of a continuum of applications of presence. I don't know if SIMPLE is interested in the more specialized forms of presence.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Thu, 13 Jun 2002 09:22:19 -0700 (PDT)

I may be misunderstanding you, but I don't
believe capacity and capabilities are necessarily
things you want to publish as presence. I agree
they are useful things to have for routing 
decisions, I just don't think they should be
part of a presence document.

Rather, I would prefer to see something like
CC/PP used in conjunction with presence to enable
the scenarios you are talking about.

/sean

--- Paul Kyzivat <[email-masked]> wrote:
> Another more extreme version of "forwarding
> decisions based on presence" is in a call center.
> What you really want is for the capabilities and
> capacity of each agent to be
> reported via presence, and for a server to subscribe
> to this presence information for all candidate
> agents. Then it can make forwarding decisions based
> on optimizing across
> For this, you need rich presence information, about
> media supported, skills, loading, possibly cost.
> This is more information than is needed for most
> informal usage, but I
> think these cases are merely the extremes of a
> continuum of applications of presence. I don't know
> if SIMPLE is interested in the more specialized
> forms of presence.
> 
> 	Paul
> 
> "Rosen, Brian" wrote:
> > 

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jun 2002 16:30:22 -0400

> part of a presence document.

Maybe we aren't thinking of the same things, because I see these as very relevant to presence.

For instance, capability/willingness to communicate on the subject of auto-repair is just a slightly more refined form of the business/personal distinction.

Another sort of capability is media. I might be available for voice only, or for voice and/or IM and/or video at a given address.

Capacity can be viewed a couple of ways: maybe I can do IM both on my phone and my PC, but I can do it well on my PC with a keyboard, whereas I can only do it poorly on my
phone. 

Capacity can also be a function of the person manning the presentity. Suppose the address is sip:[email-masked]. Sometimes there is an auto guru manning it, so the
capacity for auto-repair is high. Other times only a trainee is present, who will try, but isn't very good at auto-repair questions. So the capacity is less.

> the scenarios you are talking about.

I hadn't heard of CC/PP until now. After a (very) quick search, it sounds like it is solving a different problem. Perhaps it is still applicable, but if so it would still
need to be integrated with presence somehow. If it is XML, then perhaps it could be embedded in a special <status> in the presence document. Because this stuff can change
dynamically, and the presence client may need it to decide who to call, it would be bad to have to initiate some other sort of session with the presentity or contact to get
this information.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Thu, 13 Jun 2002 15:41:39 -0700 (PDT)

I think we are talking about different things. Part
of the confusion on "status" is that it can refer
to *at least* three different things:

 1. Presence - can I communicate
 2. Availability - do I want to communicate
 3. Capability - what are the mechanisms I have 
       at my disposal to communicate with

I believe a raw notion of capability (e-mail, http,
sip, etc.) may be appropriate for a "presence"
document.

However, more advanced notions such as I support
H.263 video or I have a color display capable of
640x480 resolution, etc. are a bit of a stretch.

Part of these device capabilities are covered
by CC/PP (the target application is web browsing,
but the CC/PP framework can be extended to much
broader capabilities ala RDF)

/sean

--- Paul Kyzivat <[email-masked]> wrote:
> Maybe we aren't thinking of the same things, because
> I see these as very relevant to presence.
> 
> For instance, capability/willingness to communicate
> on the subject of auto-repair is just a slightly
> more refined form of the business/personal
> distinction.
> 
> Another sort of capability is media. I might be
> available for voice only, or for voice and/or IM
> and/or video at a given address.
> 
> Capacity can be viewed a couple of ways: maybe I can
> do IM both on my phone and my PC, but I can do it
> well on my PC with a keyboard, whereas I can only do
> it poorly on my
> phone. 
> 
> Capacity can also be a function of the person
> manning the presentity. Suppose the address is
> sip:[email-masked]. Sometimes there is an
> auto guru manning it, so the
> capacity for auto-repair is high. Other times only a
> trainee is present, who will try, but isn't very
> good at auto-repair questions. So the capacity is
> less.
> 
> > 
> I hadn't heard of CC/PP until now. After a (very)
> quick search, it sounds like it is solving a
> different problem. Perhaps it is still applicable,
> but if so it would still
> need to be integrated with presence somehow. If it
> is XML, then perhaps it could be embedded in a
> special <status> in the presence document. Because
> this stuff can change
> dynamically, and the presence client may need it to
> decide who to call, it would be bad to have to
> initiate some other sort of session with the
> presentity or contact to get
> this information.
> 
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Jun 2002 08:59:57 -0400

Sean,

I have not been following the technologies (CC/PP & RDF) that you reference, but I did poke around a bit to figure out what you are referring to.

These may indeed be interesting technologies, applicable to this problem space. But it isn't clear that they were intended for it, so it will be necessary to verify if they
are applicable, and how they might be made to fit. Since you clearly know more about them, can you say more about what you have in mind?

In particular, I gather that these are descriptive notations, encoded in XML, and probably say nothing about how they might be delivered. When we are discussing presence,
then it would make sense to me that they would be delivered as part of a presence document (at least the capabilities part) or possibly as part of a presence filter (the
preference part). Do you agree, or do you have something else in mind?

More below.

	Paul

> sip, etc.) may be appropriate for a "presence"

I think we clearly need more than this. The existing status work has scoped itself strictly to IM, but people also want to apply it to voice, so we clearly need to
distinguish capability to communicate via IM from capability to communicate via voice.

> 640x480 resolution, etc. are a bit of a stretch.

There has to be a line somewhere, but it is difficult to decide exactly where to draw that line. I think it must at least include the medium at the highest level
(video/voice/IM). Below that level it may be reasonable to assume that communication will be possible in some way, possibly involving transcoders.

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 17 Jun 2002 18:32:16 -0500

> sip, etc.) may be appropriate for a "presence"

Yes! But I think of this as "style" or "mode" rather than capability. It
expresses the semantic of "I prefer to communicate in this mode" rather
than "My equipment is outfitted with a ____ ".

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jun 2002 08:56:39 -0400

> than "My equipment is outfitted with a ____ ".

By all means, think of it that way if it makes you feel better. 

But it amounts to the same thing either way. After all, this is *presence*, so you aren't just saying you prefer to communicate in that mode - you are saying you are (or
believe you are) ready and capable of doing so.

(It wouldn't be very useful to advertise your presence for IM unless you actually could receive IM messages.)

The major difference is perhaps that you may be capable of modes that your prefer not to use.

	Paul

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 18 Jun 2002 21:53:45 -0500

When the 3G people talk "capability" they sometimes mean "I have a
160x160 display in 4-shade gray, the following fonts, a speaker phone, a
microphone, AMR, EFR, and FR codecs, and a camera that can capture QQCIF
at 4 fps.  My contract allows authorization of RABs to 144kbps after
8:00 PM in my local time zone. My keyboard map is "  . . .

overloaded term.

--
Dean

----- Original Message -----
From: "Paul Kyzivat" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: "'Sean Olson'" <[email-masked]>; "'Rosen, Brian'"
<[email-masked]>; "'Jonathan Rosenberg'"
<[email-masked]>; <[email-masked]>; "'Li Hua Tang'"
<[email-masked]>; "'DAO TRUNG Tin FTRD/DAC/ISS'"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, June 18, 2002 7:56 AM
Subject: Re: Status discussion again RE: [Simple] Test message

> But it amounts to the same thing either way. After all, this is
*presence*, so you aren't just saying you prefer to communicate in that
mode - you are saying you are (or

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Jun 2002 15:53:12 -0500

> broader capabilities ala RDF)

One could also make this sort of thing up to the underlying 
communication protocol, rather than move them as part of presence. For 
example, I might have a SIP contact in a presence document. I don't have 
to add what codecs I support. If someone wants to talk to me, they send 
an INVITE, and the normal SIP process figures out the codec. There is of 
course some benefit to knowing the mode (am I INVITEing for a video 
session vs. a voice session.)

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jun 2002 18:45:09 -0400

Regarding what sort of "capabilities" should be reflected in presence, knowing the mode (audio, video, etc.) is very important. Individual codecs is probably going too far.

But this is a fine line. While I probably don't want to describe codecs for audio, I perhaps do want to describe the "codecs" for application - e.g. application/wb -
because the likelihood of success isn't very good without.

Maybe this is a matter of judicious use of wildcards - advertise audio/* but application/wb.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Fri, 21 Jun 2002 16:40:33 -0700 (PDT)

Mode seems to make sense. I like the idea
of announcing supported MIME types, BUT I think
it is very dangerous to infer applications from
MIME types (as you hint at for the 
application/wb case). I see this leading to a
rathole. Could we set the bar at just 
announcing "modes" for now? 

/sean

--- Paul Kyzivat <[email-masked]> wrote:
> Regarding what sort of "capabilities" should be
> reflected in presence, knowing the mode (audio,
> video, etc.) is very important. Individual codecs is
> probably going too far.
> 
> But this is a fine line. While I probably don't want
> to describe codecs for audio, I perhaps do want to
> describe the "codecs" for application - e.g.
> application/wb -

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2002 01:22:52 -0400

> announcing "modes" for now?

You have to tell me what you mean by "mode" then.

I don't think of application/wb as an "application" in any specific sense. As far as I am concerned, "application" and "voice" are simply different subdivisions of the
overall mimetype namespace. But "voice" in its own right is much more specific than "application" is. I have a reasonable chance of deciding if I can support "voice"
without more detail. (If I can't support the offered codecs then I can probably find a transcoder that can convert to something I do understand.)

But by itself "application" tells me nothing about what I will be expected to do. And in general there are no transcoders that can convert between application/wb that I
support and application/foo that I don't - there is no least common denominator between subtypes of application. 

If the bar is set so low that mime subtypes can never be used, then presence will not be at all useful for any media that happen to be described by subtypes of application.

	Paul

---

From: "Sean Olson" <[email-masked]>
Date: Mon, 24 Jun 2002 23:37:35 -0700

What I mean is that while application/wb may give you a clue as to the
application,
text/html, image/jpeg, or even message/sip do not. MIME types are not
usually
a good indication of the application that will process that media. 
"voice" is interesting, but as a MIME type would more likely be
represented as
the less useful audio/g711, etc. 

If what you want to convey is a list of MIME types, that's fine. I just
don't want to confuse that with a list of applications. (Of course, MIME
types
are best represented with a suitable subtype as you mention)

By mode, I meant a token that succintly defines an application -- like
"voice" perhaps.
But I definitely don't want to get into the game of defining a list of
codecs ... this 
is much better handled by SIP itself than by a presence document format.

/sean

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, June 24, 2002 10:23 PM
To: Sean Olson
Cc: Ben Campbell; Rosen, Brian; 'Jonathan Rosenberg'; [email-masked];
'Li Hua Tang'; 'DAO TRUNG Tin FTRD/DAC/ISS';
[email-masked]
Subject: Re: Status discussion again RE: [Simple] Test message

I don't think of application/wb as an "application" in any specific
sense. As far as I am concerned, "application" and "voice" are simply
different subdivisions of the overall mimetype namespace. But "voice" in
its own right is much more specific than "application" is. I have a
reasonable chance of deciding if I can support "voice" without more
detail. (If I can't support the offered codecs then I can probably find
a transcoder that can convert to something I do understand.)

But by itself "application" tells me nothing about what I will be
expected to do. And in general there are no transcoders that can convert
between application/wb that I support and application/foo that I don't -
there is no least common denominator between subtypes of application. 

If the bar is set so low that mime subtypes can never be used, then
presence will not be at all useful for any media that happen to be
described by subtypes of application.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Jul 2002 14:32:19 -0400

Sorry - I'm way behind in my mail. 

It still seems to me we are talking past one another. Maybe this comes down to differences about the purpose of presence.

My assumption is that the purpose of presence is to convey willingness to participate in interactive communication. An important subcase of this is when the communication
will be realitime communication initiated via sip - perhaps IM, perhaps voice, perhaps something else.

An important aspect of presence in this regard is determining in advance whether successful communication will be possible. I don't want to call you unless there is a
likelihood that you will answer. Similarly, I don't want to call with voice if all you are willing to do is IM.

If I do send you an invite, we negotiate the kind of communication we are willing to do in common using an exchange of SDP. The media types carried in the SDP don't
explicitly say what applications should be used, but they imply it, because if the invitation is successful, the two ends will be exchanging data in those mime types and
doing something with it. There is nothing else in the invitation to say what will be done. This is true whether the mime type is audio/g711, text/html, image/jpeg or
application/wb.

In the case of audio or image, it is pretty clear what sort of application will be required regardless of the subtype. This is also true to a lesser extent for text. For
application, it is pretty much impossible to figure out what kind of application might be needed, or whether it is available.

So, I think it makes pretty good sense to advertise the mimetype/subtype as part of presence. How much of it is presented to a presence subscriber could be a function of
the UI at the subscriber end.

Frankly, I am not at all convinced that mime types are the best way to describe media in sip, but that is water over the dam.

	Paul