Subject: RE: [Simple] New I-D on presence states for phones

From: [email-masked]
Date: Thu, 17 Jul 2003 15:50:29 +0300

Hi,

I think this draft defines bunch of useful information. However, I would definitely take away the "signal-strength" attribute under the wireless phone state. As already stated in the draft, this information is changing frequently, so I think it is not sensible in the timescale that SIP events work. And even if it would be possible to convey this information, what would it mean in GPRS, WCDMA or WiFi? Is there any use case what any watcher could in _practice_ benefit from this information? 

What might be useful as an addition to "ran" is some more information on the access-link, i.e. that the "downlink capacity class" is ~40 kbps, and "RTT class" is ~500 ms. This _kind_ of information might give watchers some idea what _kind_ of applications/media the device could be able to do at the moment (although you could find that out also through PIDF/prescaps and SDP negotiations). This kind of info is relatively static (in the order of minutes rather than seconds), but still changing. In any case, this would be more valuable than "signal-strength".   

Markus 

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 08 July, 2003 09:42
> To: Simple WG
> Subject: [Simple] New I-D on presence states for phones
> 
> 
> Folks,
> 
> In case folks havent seen it, I wanted to call your attention to:
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-s
imple-pidf-phone-00.txt
http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.txt
http://www.jdrosen.net/papers/draft-rp-simple-pidf-phone-00.html

This draft, written by Jon and myself, defines some PIDF extensions 
for describing phones, including traditional "black" phones, wireless 
phones and enterprise phones. I think these will provide invaluable 
for a device-centric view of a presentity.

Comments and questions welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[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: Alex Audu <[email-masked]>
Date: Fri, 18 Jul 2003 09:49:01 -0500

Hello,

From a user's point of view, I am not sure if "signal strength" is not a valuable
information to have. Granted, it may be changing very frequently, but you can
always limit how often it is updated.

I am not sure however, if  "signal strength" can be a valid attribute of the state
of the phone. It is descriptive, more of the environment the phone is in, than
the phone itself.

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Fri, 18 Jul 2003 09:49:01 -0500

Hello,

Regards,
Alex.

---

From: "Vikas Tandon" <[email-masked]>
Date: Fri, 18 Jul 2003 21:01:05 -0700

Hi Markus, Alex and SIMPLE experts,

As rightly pointed out, signal strength can change several times within
a second based on the attenuation factors and even what is displayed on
the phone is a best-possible view. Having lower signal strength however
might not be  a very useful information to the watcher. Additionally and
noticeably, we are talking about adding more processing on the client
side.

If we were to add some of the phone status attributes, we should look at
ones which display what the user wants to be communicated like - I can
set: My phone is switched off without letting others know that actually
I'm on!! 

These category of information might be a useful information on the
network side for delivery purpose but not for the watcher, and moreover
information of this category as best picked up from the network nodes
themselves rather than making the client thicker.

Regards,
Vikas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alex Audu
Sent: Friday, July 18, 2003 7:49 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Simple] New I-D on presence states for phones

Hello,

From a user's point of view, I am not sure if "signal strength" is not a
valuable information to have. Granted, it may be changing very
frequently, but you can always limit how often it is updated.

I am not sure however, if  "signal strength" can be a valid attribute of
the state of the phone. It is descriptive, more of the environment the
phone is in, than the phone itself.

Regards,
Alex.

[email-masked] wrote:

> Hi,
>
> I think this draft defines bunch of useful information. However, I
> would definitely take away the "signal-strength" attribute under the 
> wireless phone state. As already stated in the draft, this information

> is changing frequently, so I think it is not sensible in the timescale

> that SIP events work. And even if it would be possible to convey this 
> information, what would it mean in GPRS, WCDMA or WiFi? Is there any 
> use case what any watcher could in _practice_ benefit from this 
> information?
>
> What might be useful as an addition to "ran" is some more information
> on the access-link, i.e. that the "downlink capacity class" is ~40 
> kbps, and "RTT class" is ~500 ms. This _kind_ of information might 
> give watchers some idea what _kind_ of applications/media the device 
> could be able to do at the moment (although you could find that out 
> also through PIDF/prescaps and SDP negotiations). This kind of info is

> relatively static (in the order of minutes rather than seconds), but 
> still changing. In any case, this would be more valuable than 
> "signal-strength".
>
> Markus
>

---

From: "Vikas Tandon" <[email-masked]>
Date: Fri, 18 Jul 2003 21:01:05 -0700

Regards,
Vikas

-----Original Message-----

Hello,

Regards,
Alex.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jul 2003 17:39:38 -0400

Generally, I agree that the scope of the draft was too broad, covering 
a bunch of things which probably are outside the scope of presence. 
But, thats the nature of a -00 draft, and the way to get discussion going.

The reason I had put signal strength in there in the first place was 
that, ultimately, a watcher would know that their call/IM/whatever 
won't succeed if the target has poor signal strength. However, I agree 
with Markus that it really does change too much (and also probably 
nearly impossible to obtain in any accurate or timely way). So, I will 
remove it from the next rev of the document.

The best way to determine what is, and what is out, of scope is for 
people to give examples of the kinds of applications that might need 
each piece of presence data. If you can't think of a presence app that 
needs a piece of data, there is a good chance it should just be 
removed from the spec.

So, here are some thoughts on the motivating apps and some of their 
presence needs:

call state: very useful for rendering to watchers, says alot about 
whether now is a good time to make a call to them. Also useful input 
to other pieces of presence which can be derived from it, such as 
OPEN/CLOSED for voice. I agree that the full call state model is 
perhaps not needed. In particular I cant think of a reason why a 
watcher cares to know ringing vs. in a call. Both are probably the 
same in terms of presence.

registration state: this seems pretty fundamental - no communication 
is possible unless this is true. I think its also really useful to 
render to people, to let them know if the phone is on or off. A change 
in registration state is frequently the trigger for push apps, such as 
a ringback application.

data-state: useful for knowing if a SIP IM will succeed or not - 
clearly not if the data-state is not connected. I dont think its 
useful to render to a user, but applications which want to push 
information to a user probably care.

roaming: I think this is really useful to render to watchers. Its sort 
of really high level geoloc information. Frequently, you want to know 
whether someone is on a trip or not, to decide whether to call them, 
and roaming helps the watcher know that.

visited/home strings: not really sure what these might be used for. 
Seems neat, but perhaps its too much. Anyone have any ideas?

barred: I'm not sure this is usefully different than not registered, 
but I need to think about it.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jul 2003 17:39:38 -0400

-Jonathan R.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 30 Jul 2003 18:01:22 -0400

At 05:39 PM 7/30/2003 -0400, Jonathan Rosenberg wrote:
>roaming: I think this is really useful to render to watchers. Its sort of 
>really high level geoloc information. Frequently, you want to know whether 
>someone is on a trip or not, to decide whether to call them, and roaming 
>helps the watcher know that.

Thinking of this in the WiFi space rather than traditional cellular, the 
target may be moving from one hot-spot to another.  Short trip v. 
long-distance trip.

Also given that roaming may occur if the network has spotty coverage, this 
may be more of an issue of whether the user will have full service in the 
visited v. home area, e.g. do they pay by the byte v. use pre-paid bulk 
BW/minutes.  May affect the media that one chooses.

Mike

---

From: Michael Hammer <[email-masked]>
Date: Wed, 30 Jul 2003 18:01:22 -0400

Mike