Subject: [Simple] Re: draft-rosenberg-peterson-simple-pidf-phone-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jul 2003 11:43:01 -0400

I think representing states appropriate to a phone is a good idea. But I 
have serious problems with the details of this draft:

- multiple ways of representing equivalent state

Typically a watcher is likely to care less what kind of phone you have, 
and simply want to know if you are available for a call and/or are in a 
call. Having to decipher three different representations of this same 
information is a needless hassle.

Also, to the caller there is no functional difference between a POTS 
phone with call waiting available, and a business phone with two "lines" 
associated to the same number with one in use and one free. In both 
cases the callee is in a call but still available for a call. 
Representing these situations differently just makes things difficult 
for the watcher.

- problematic extensibility model

This pattern also sets the stage for more complexity in the future as 
new devices with different combinations of features hit the market. 
Suppose I come out with both home (single line) and business (multi 
line) voice/im phones. The home phone can do one voice call or one im 
call. The business phone can do two voice calls and two im calls.

It isn't at all clear that I can extend any of the proposed models to 
accomodate my new phone in a graceful way. I may end up defining two new 
types for my new phones, different from these three types. Then I have 
problems with backward compatibility.

- inclusion of useless data

Identifiers for lines seems useless. They are all associated with the 
same phone number, and are not addressable for any purpose. Showing 
lines that are not in use is also pretty useless except for providing a 
way to know that a new call can be accepted. Data-state could be useful 
but I think I need to know a lot more info to predict what that might 
permit me to do.

ALTERNATIVE:

I think the following kind of structure would accomplish the same thing 
you have proposed yet address my issues:

- a representation for a call. This would subsume your call-state, but 
omitting the not-in-call state. But it would also be extensible for 
other call attributes. This can be repeated as many times as needed to 
represent calls in progress, not lines. (This clearly overlaps with the 
dialog package - something worth discussing. It provides extra 
information in that it can show a call before a dialog is established. 
And with further extension it might provide a way to represent calls on 
hold, if we can figure out what that means.)

- an indication of whether available for another call. In your model 
this seems to be represented by some call-state=not-in-call, or by 
call-waiting=available. But it also seems to be indicated by 
<basic>open</basic>. I'm uncomfortable using basic status for this, 
because the device may still be open for other kinds of signaling, such 
as subscriptions.

In this new model availablily for calls could also be indicated by a 
call-state of available, but I see no need to model lines not in use. 
This is rooted in old world notions that there are some fixed number of 
lines. Conceivably some new attribute could be introduced for this, but 
I think the attributes in RPIDS already have this covered. (This still 
cries out for capabilities, to describe *what* I am available for, but 
that can be dealt with separately.)

- an optional element representing the home network provider. This is 
appropriate for all kinds of phones. (I'm not sure why I would want to 
publish this, but I can go along.)

- optional ran, roaming, visited-network, signal-strength attributes. 
(Assuming you think these make sense to provide at all.) These could be 
grouped under a mobile attribute or left standalone.

- I consider data-state to be a capability. (If you think it is useful 
at all - it isn't clear to me what this implies I can do.) I would deal 
with it together with other capabilities, like voice, video, IM.

Using the above, representations for POTS phones, business phones, and 
wireless phones are simply usage profiles. The watcher won't explicitly 
know what kind of phone it is except by inference from the kinds of 
presence he sees it use. To me this is a good thing.

	Paul

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jul 2003 11:43:01 -0400

ALTERNATIVE:

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jul 2003 18:03:32 -0400

Thanks for the comments. Responses inline.

> information is a needless hassle.

I think a watcher may want to know what type of phone you have - 
knowing that its home vs. wireless vs. business is useful presence 
information in itself, I believe.

> Representing these situations differently just makes things difficult 

I think I agree with that. I should point out that our split of the 
doc and schema along the device type lines was primarily to facilitate 
a division of labor, not because of a fundamental belief that these 
needed to be totally separated. That said, there definitely are 
differences in states and infrmation between devices. I'm all for 
making as much common as is possible though.

Perhaps a better way to deal with this is to indicate that there 
exists another call in progress, or perhaps an indication of how many 
calls are in progress (useful for call routing to customer support 
operators perhaps?).

> problems with backward compatibility.

I'm not sure I see the specific problem here - is it because your 
phones can do IM also, and none of the phone types in the doc discuss IM?

If this is the case, I would argue that it comes back to a 
service/device view. The current draft doesnt separate the two. Many 
aspects of the draft refer to a service view, where the service is 
telephony. Others refer to the device view - things such as access 
network and signal strength (which I agree should be booted) are 
device properties that span services. For example, IM and PTT may also 
run on the phone, and things like signal strength would affect all of 
them.

So, if I have a device as you describe, I could present it with a 
service view that lists telephony as one service, IM as another. The 
device-specific attributes would perhaps get replicated in each 
service, or else composed in some way into the overall availability 
(OPEN/CLOSED).

What do you think about splitting the attributes along those lines?

> way to know that a new call can be accepted. 

I'll agree with that.

> Data-state could be useful 

As per my other note, its useful for applications that want to push 
data to the phone.

> hold, if we can figure out what that means.)

This is different from dialog package in that there isnt a sip dialog. 
Nothing in the simple-pidf draft is specific to sip phones. In my 
mind, the model is that a presence server might itsefl subscribe to 
the dialog package for a phone, and based on that information, 
generate presence documents using the pidf information. For other 
phone types, such as a wireline phone, it might use the spirits 
interface or some proprietary i/f to a switch.

> that can be dealt with separately.)

I think your proposal is reasonable - the phone "service" is modeled 
by zero or more call elements that represent some amount of call 
state, and information on ability to take another call.

I see this as different from basic status, in that basic status would 
depend on other things too. For example, if I'm in a meeting, even if 
I can take another call, the basic status for my telephony service 
would be closed.

> publish this, but I can go along.)

I can go either way on this too. Now, is this a device or service 
property? I can have an IM service on my phone from a different 
provider than the one that provides me data access. Arguably, the data 
access provider is a device property.

> grouped under a mobile attribute or left standalone.

I dont think they can be in a single mobile attribute, there is a 
bunch of separate information here.

> with it together with other capabilities, like voice, video, IM.

I think its a device capability that says something about availability 
across a number of services.

> presence he sees it use. To me this is a good thing.

Well, I would still argue that an attribute that describes the type of 
device is useful.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jul 2003 18:03:32 -0400

I'll agree with that.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Jul 2003 21:46:43 -0400

Jonathan Rosenberg wrote:

> I think a watcher may want to know what type of phone you have - knowing 
> that its home vs. wireless vs. business is useful presence information 
> in itself, I believe.

Isn't that partially covered by the device-capabilities extension that 
was split off again from RPIDS?

> 
> Perhaps a better way to deal with this is to indicate that there exists 
> another call in progress, or perhaps an indication of how many calls are 
> in progress (useful for call routing to customer support operators 
> perhaps?).

Only if the presentity is a group, not an individual, I'd think.

>> represent calls in progress, not lines. (This clearly overlaps with 
>> the dialog package - something worth discussing. It provides extra 
>> And with further extension it might provide a way to represent calls 
>> on hold, if we can figure out what that means.)

One of the questions is whether this or dialog state is the right model 
for directed call pickup. If I can subscribe to another user's phone and 
get the Call-ID and other identifying information, I can then pick up 
the call via REFER. I suspect that dialog-package is the better one, but 
one of them should be made to work for that...

>> (Assuming you think these make sense to provide at all.) These could 
>> be grouped under a mobile attribute or left standalone.
> 
> 
> I dont think they can be in a single mobile attribute, there is a bunch 
> of separate information here.

I am dubious on 'roaming'. This can mean many different things and 
nothing at all. Without having detailed knowledge of the presentity's 
carrier subscription and its coverage, it says essentially nothing. (In 
NJ, the pin-drop carrier can make you roam into analog just a few miles 
west on Rt. 4, as that's the border of digital coverage, so this says 
nothing about distance from home.) Also, are there currently any 
interfaces that would allow you to retrieve this information?

>> wireless phones are simply usage profiles. The watcher won't 
>> explicitly know what kind of phone it is except by inference from the 
>> kinds of presence he sees it use. To me this is a good thing.
> 
> 

What's the difference between a 'business' phone on an analog PBX and a 
POTS phone?

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Jul 2003 21:46:43 -0400

---

From: Alex Audu <[email-masked]>
Date: Thu, 31 Jul 2003 10:12:05 -0500

Jonathan,

I think I'll agree with Paul on the issue that a watcher could care less about
the
type of device on the other end.  Frankly, all we should care about is the
service
type. The device type has no value (in my mind).  New devices that provide
telephony/IM services are coming to the market almost daily. And of course,
lets
not forget softphones which can be staged on any computing device.

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Thu, 31 Jul 2003 10:12:05 -0500

Jonathan,

Regards,
Alex.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jul 2003 14:06:40 -0400

>> calls are in progress (useful for call routing to customer support 

[note: "this" above referred to representations of "lines" currently in 
use.]

> Only if the presentity is a group, not an individual, I'd think.

I disagree, though it may also apply in that case. The use case was when 
the presentity is already on the phone, but has call waiting, or has a 
phone that can otherwise support multiple "calls" per "line". The user 
may not be able to talk to multiple calls at the same time, but still 
may accept and switch among them, with the extra ones on hold.

So the point is that being on-the-phone isn't mutually exclusive with 
being able to accept a call. Both pieces of information (being 
on-the-phone and ability to take a call) are useful presence status. 
When on-the-phone, it might also be useful to know how many active calls 
there are.

>>> - a representation for a call. This would subsume your call-state, 
>>> but omitting the not-in-call state. But it would also be extensible 
>>> for other call attributes. This can be repeated as many times as 
>>> needed to represent calls in progress, not lines. (This clearly 
>>> overlaps with the dialog package - something worth discussing. It 
>>> provides extra information in that it can show a call before a dialog 
>>> is established. And with further extension it might provide a way to 
>>> represent calls on hold, if we can figure out what that means.)
> 

For directed call pickup I think you point is valid. I certainly don't 
think that is the only purpose of this information.

I think one way to draw a line is to decide what is needed to maintain a 
presence status display - say of a buddy list. Everything you need to 
display the presence of a buddy should be included in the presence 
document. It is highly undesirable to have to subscribe to other event 
packages for each buddy, or send OPTIONS requests, or whatever, on a 
coninual basis.

OTOH, I think its ok if there is stuff you need to query for after 
making a decision to use a particular tuple.

> interfaces that would allow you to retrieve this information?

I agree. I would much rather have some kind of specific information that 
can be used in a well defined way to decide whether to contact this 
endpoint. For instance, if roaming is going to affect how much it costs 
me to call, then the specific info that permits my UA to make the cost 
computation would be helpful. Similarly if it affects how the callee 
will be charged and I might care to minimize (or maximize that).

If this is simply about being away from home then I think this is 
inappropriate, and geoloc or one of the other attributes should be used 
instead.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jul 2003 14:06:40 -0400

Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 31 Jul 2003 18:21:18 -0400

inline.

> When on-the-phone, it might also be useful to know how many active calls 

I agree. My example of a call center rep is also referring to a 
presentity that is one person, but that can handle multiple calls at once.

>>>> provides extra information in that it can show a call before a 
>>>> dialog is established. And with further extension it might provide a 
>>>> way to represent calls on hold, if we can figure out what that means.)
>>
>>
>> One of the questions is whether this or dialog state is the right 
>> model for directed call pickup. If I can subscribe to another user's 
>> phone and get the Call-ID and other identifying information, I can 
>> then pick up the call via REFER. I suspect that dialog-package is the 
>> better one, but one of them should be made to work for that...
> 
> 

I don't think that directed call pickup is really a "presence" 
application though. The way to tell is whether information beyond 
dialog state is useful for it. In the case of ringback, for example, I 
think it is a presence application. Its useful to know that you are 
truly available, as opposed to just no longer in a dialog. Not so for 
directed pickup (unless you have a different service definition in 
mind than I do).

> 
>>>> - optional ran, roaming, visited-network, signal-strength 
>>>> attributes. (Assuming you think these make sense to provide at all.) 
>>>> These could be grouped under a mobile attribute or left standalone.
>>>
>>>
>> carrier subscription and its coverage, it says essentially nothing. 
>> (In NJ, the pin-drop carrier can make you roam into analog just a few 
>> miles west on Rt. 4, as that's the border of digital coverage, so this 
>> says nothing about distance from home.) Also, are there currently any 

OK, I will agree with all of this. The real information I was after 
with roaming is geoloc. Cost is another potential derived piece of 
information, and I agree its better to represent it directly if we 
want to (though I think its out of scope).

Unless someone can think of something else to do with the roaming flag 
(and I can't), I'll remove it.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 31 Jul 2003 18:21:18 -0400

inline.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jul 2003 19:02:34 -0400

Jonathan Rosenberg wrote:
> 
>> Typically a watcher is likely to care less what kind of phone you 
>> have, and simply want to know if you are available for a call and/or 
>> are in a call. Having to decipher three different representations of 
>> this same information is a needless hassle.
> 

Others have brought up the problem of how can you enumerate all the 
types of phones. It has also been controversial in the attempt to define 
characteristics of a business phone.

I don't think a watcher is likely to care, but who am I to say you 
shouldn't want to know this. As long as it is an independent piece of 
information that may or may not be present then I have no problem with 
it. But in this draft it is *necessary* to divulge what kind of phone 
you have in order to publish phone characteristics. That's bad.

>> phone with call waiting available, and a business phone with two 
>> "lines" associated to the same number with one in use and one free. In 
>> both cases the callee is in a call but still available for a call. 
> I think I agree with that. I should point out that our split of the doc 
> and schema along the device type lines was primarily to facilitate a 
> division of labor, not because of a fundamental belief that these needed 
> to be totally separated. That said, there definitely are differences in 
> states and infrmation between devices. I'm all for making as much common 
> as is possible though.

Certainly there are states or attributes that some phones have and 
others don't. I think we can effectively deal with that in a generic way.

> in progress (useful for call routing to customer support operators 

Yes, something like that might work. That would minimize the overlap 
with the dialog event package. But we do need to sort out how much of 
the dialog package state also makes sense in presence. Offhand I can't 
think of a reason to include more about a call than its existence, but 
maybe somebody else can.

Number of calls could be sensitive information, so (like <idle>) if we 
go this way I think there is a requirement to leave the actual number 
unspecified - just indicating that it is > 0. (There might be some 
objections to just anybody learning how many calls are in queue to the 
help desk.)

But lets note that this information probably belongs in RPIDS rather 
than here - it is in now way specific to phones. I am just as interested 
in how many chat sessions you are in as I am in how many phone calls you 
are in. And in reality we can't typically classify a call as a chat call 
or a voice call - its just a call that involves some assortment of media.

>> accomodate my new phone in a graceful way. I may end up defining two 
>> new types for my new phones, different from these three types. Then I 
>> have problems with backward compatibility.
> 
> I'm not sure I see the specific problem here - is it because your phones 
> can do IM also, and none of the phone types in the doc discuss IM?

Yes. Although that is just an example.

> network and signal strength (which I agree should be booted) are device 
> properties that span services. For example, IM and PTT may also run on 
> the phone, and things like signal strength would affect all of them.
 >
> device-specific attributes would perhaps get replicated in each service, 
> or else composed in some way into the overall availability (OPEN/CLOSED).
> 

I disagree with the service view for this (and almost everything else) 
because I don't think it is desirable to partition these things into 
disjoint services. (I won't mind so much if your concept of service 
permits the same tuple to support multiple services.)

The devices I am concerned with can support IM and voice independently 
or together in the same session. So I need to describe them as part of 
the same tuple. Otherwise a subscriber won't know they can be used together.

>> lines that are not in use is also pretty useless except for providing 
>> a way to know that a new call can be accepted. 
> 
> I'll agree with that.
> 
>> Data-state could be useful but I think I need to know a lot more info 
>> to predict what that might permit me to do.
> 
> As per my other note, its useful for applications that want to push data 
> to the phone.

As I read it, the data state didn't say anything about what kinds of 
features it enabled. If it implies certain features *at the same address 
as the voice features being reported", then I would rather see those 
features explicitly enumerated.

But I suspect what you suggest is even weirder than that. I suspect you 
have in mind a cell phone that has one way of doing voice (non-sip) and 
another way of doing "data", which might include sip for IM, or other 
internet protocols.

If so, then I don't see how those belong as part of the same tuple. At 
the very least they ought to be in a different tuple, associated with 
the address at which the features can be invoked.

>> ALTERNATIVE:
>>
>> I think the following kind of structure would accomplish the same 
>> thing you have proposed yet address my issues:
>>
> Nothing in the simple-pidf draft is specific to sip phones. In my mind, 
> the model is that a presence server might itsefl subscribe to the dialog 
> package for a phone, and based on that information, generate presence 
> documents using the pidf information. For other phone types, such as a 
> wireline phone, it might use the spirits interface or some proprietary 
> i/f to a switch.

OK, maybe it doesn't conflict with the dialog package because it applies 
to non-sip phones. Good. It is still worth discussing if this level of 
detail is needed, vs the existence (or a count) of calls in progress.

An interesting question is what to do about phones that have multiple 
"lines". (Register contacts with multiple AORs). The presence is being 
reported on an address-by-address basis. Typically the presentity will 
be associated with one of the lines on the phone, so status of calls on 
other lines doesn't belong in the presence document at all. But the fact 
that the phone device itself is engaged in a call may be significant 
nevertheless.

Perhaps this is sufficiently covered by activity="on-the-phone".

Another piece of information that is significant is if the phone is 
off-hook (i.e. in process of placing a call) even though not actually in 
a call. But maybe that is also covered by "on-the-phone".

>> because the device may still be open for other kinds of signaling, 
>> such as subscriptions.
>>
>> This is rooted in old world notions that there are some fixed number 
>> of lines. Conceivably some new attribute could be introduced for this, 
>> but I think the attributes in RPIDS already have this covered. (This 
>> still cries out for capabilities, to describe *what* I am available 
>> for, but that can be dealt with separately.)
> 
> I think your proposal is reasonable - the phone "service" is modeled by 
> zero or more call elements that represent some amount of call state, and 
> information on ability to take another call.
> 
> depend on other things too. For example, if I'm in a meeting, even if I 
> can take another call, the basic status for my telephony service would 
> be closed.

Hmm. That seems quite backward to me. If all my "lines" are in use so 
that I can't take a call, then I think I would show that as closed. If I 
am in a meeting where I shouldn't be disturbed, I might show that as 
closed, or I might show it as open with some qualifiers.

OTOH, if my phone can accept pages vis MESSAGE, and I am willing to do 
those while in the meeting, then I will want to show my tuple as open, 
with capabilities that include use of MESSAGE but not voice calls. I 
know this is crossing the line from phone status, but I think these 
things can and should be mixed in the same tuples, so they can't be 
discussed in total isolation.

> property? I can have an IM service on my phone from a different provider 
> than the one that provides me data access. Arguably, the data access 
> provider is a device property.

I still don't get this distinction between device and service 
properties. Whatever a service is, doesn't a given tuple have to be one 
or the other?

> of separate information here.

Whatever. I don't care. This seems like very weird stuff to publish, but 
if you want it I see no reason to object.

>> at all - it isn't clear to me what this implies I can do.) I would 
>> deal with it together with other capabilities, like voice, video, IM.
> 

That 'service' word again. :-(

> Well, I would still argue that an attribute that describes the type of 

As noted above, if you want an *independent* phone-type attribute I'm 
not going to object. Make sure you either make it a text string or set 
up an extension mechanism for new values. (I think IANA may be too 
cumbersome for the number of types that people are likely to want.)

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jul 2003 19:02:34 -0400

Paul