Subject: RE: quantifying activity (was RE: [Simple] Extending <status> fo r pr esence)

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 22 Jan 2003 17:02:35 -0500

Priority and activity may be conflicting in so far as they are both used to
determine which contact in a set is the best place to reach a user. If a
contact has a high priority and low activity, should that be preferred over
a contact with a low priority and high activity? I don't see how the two
could not need to be considered simultaneously. In some sense, activity
contributes to the decision of preference that one makes based on priority.
That's why I was speculating on whether or not we could combine the two, or
at least to define how they interrelate. I don't have a particularly strong
intuition about how to do this, though.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 11:15 PM
> To: Peterson, Jon
> Cc: Paul Kyzivat; [email-masked]
> Subject: Re: quantifying activity (was RE: [Simple] Extending <status>
> for pr esence)
> 
[snip]
> 
> > 
> > If we want a bucket for this in the current document, 
> though, I wonder if
> > the relative 'priority' attribute of <contact> elements, 
> which is already
> > specified in PIDF, would be a good place for quantified 
> activity information
> > to be recorded. Presumably, one use of activity information 
> would be to
> > discover the best contact in a set; it might be confusing 
> to have a separate
> > parameter for this that conflicts with the existing 
> priority parameter in
> > PIDF. It also already has the connotation that it can be 
> set manually.
> 
> I don't see this is conflicting at all. THe priority conveys something 
> quite different - which one of these is preferred by the presentity. 
> Thats not the same as saying "this one hasn't been used by the 
> presentity in a while". Indeed, it may be inactive but still preferred 
> (say, because there is a store and forward app running there).
> 
> In fact, the active/idle indication makes sense for single device 
> systems, where priority clearly doesnt help.
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 23 Jan 2003 00:13:33 -0500

I would argue that ALL of the status elements ultimately contribute to 
the decision about which contact is best to reach a user. FOr example, 
if the presentity publishes that one tuple supports video, and the other 
audio, but the audio is lower priority, and the video is active, and the 
watcher wants to make a video call, it would probably select the video 
tuple.

-Jonathan R.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 23 Jan 2003 10:00:45 -0500

Jonathon,

I would argue the opposite.  Perhaps the presentity can only support one 
video feed at a time (due to BW constraints), thus while the video is 
active, he would not want to receive another and is trying to tell any 
watchers to IM him instead.

Mike

At 12:13 AM 1/23/2003 -0500, Jonathan Rosenberg wrote:
>I would argue that ALL of the status elements ultimately contribute to the 
>decision about which contact is best to reach a user. FOr example, if the 
>presentity publishes that one tuple supports video, and the other audio, 
>but the audio is lower priority, and the video is active, and the watcher 
>wants to make a video call, it would probably select the video tuple.
>
>-Jonathan R.
>
>Peterson, Jon wrote:
>>>-- Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Jan 2003 13:46:07 -0500

Really, the notion of which tuple is "best" is a combination of the 
needs of the caller and of the needs of the called party. There is no 
one right answer, to be certain. We can think of examples back and forth 
which show cases where one status or another is really whats important.

The only thing we can do is convey sufficient information so that the 
caller can make an intelligent decision about how to proceed.

-Jonathan R.

Michael Hammer wrote:
>> if the presentity publishes that one tuple supports video, and the 
>> other audio, but the audio is lower priority, and the video is active, 
>> and the watcher wants to make a video call, it would probably select 
>> the video tuple.
>>
>> -Jonathan R.
>>
>> Peterson, Jon wrote:
>>
>>>> I don't see this is conflicting at all. THe priority conveys 
>>>> something quite different - which one of these is preferred by the 
>>>> presentity. Thats not the same as saying "this one hasn't been used 
>>>> by the presentity in a while". Indeed, it may be inactive but still 
>>>> preferred (say, because there is a store and forward app running 
>>>> there).
>>>>