Subject: Re: [Simple] Three dimensions of service

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Feb 2005 09:50:03 -0500

Brian Rosen wrote:
> I still can't fathom what you are talking about, but I don't think it
> matters.
> 
> You, and Paul, think you can infer the end device requirements to initiate a
> session to a service by the protocol visible characteristics that a presence
> tuple would give you, and you believe that it should be possible to describe
> services in terms of (presumably unique) sets of these characteristics.
> 
> I think you are dreaming, and most services cannot be so simply defined.
> The most common services could be (basic telephony, instant messages, and
> the like).  I think all the other examples we have used, including Doom and
> PTT cannot.

Maybe we aren't so far apart. I think the fundamental "thing" that we 
are describing in presence is availability to communicate - presentity 
to presentity. By that I mean unstructured communications between 
humans. Perhaps in your terms that would be considered a service.

Absent some evidence to the contrary, when I "call" you that is what I 
expect. It isn't necessarily what I will get, but it is what I seek. For 
instance I may call you, but get your answering system, which gives me a 
kind of structured communication with an automaton rather than 
unstructured communication with you.

I think 90% of what people want presence for is focused around that 
unstructured communication.

We are getting hung up on the other 10%. Doom is probably a far fetched 
hypothetical, so we probably shouldn't give it so much emphasis in our 
discussions. Answering systems are of much more significance. At least 
we have them covered, in that we have a way to describe that a tuple 
represents one rather than a real human. I think there is indeed value 
in discussing how to broaden our ability to describe other structured 
forms of communication.

But I don't think basic telephone, instant messaging, video, or real 
time text are different {services / whatever}. They are simply different 
media that may used for the same basic purpose of communication. I can 
have an unstructured communication session with you using any 
combination of these. Or, I can use combinations of these for various 
forms of structured communications - e.g. I could have an IM or RTT 
session with an answering system.

Of course some specialized applications may not be so flexible in the 
media they are capable of using. But that isn't unusual either. Some 
humans also aren't so flexible. How accurately we need to describe those 
limitations is something we can discuss. But for the most part I think 
this is a limitation of an instance rather than a characteristic of a type.

> If Doom supplies audio out, but not audio in, what device would be suitable?
> If you call it with a telephone, would anything useful happen?  How would
> you know?  Suppose it has two audio outputs with labels "Left" and "Right"? 
> You, as a human, can guess what that means.  How would an arbitrary client
> that had ways to handle multiple input streams (i.e. local mixing
> capability).  Suppose doom supports audio in and out.  Now what devices are
> suitable?  Suppose it has a floor control.  Does that floor control the
> audio in?  How do you know?
> 
> You know only if you know what "Doom" means.  Doom is a service.  You cannot
> tell from the presence visible characteristics.  Some other document has to
> tell a client what Doom means.

*If* Doom requires the "caller" to use multiple media streams is very 
specialized ways, then I agree with you. But if Doom is really all about 
a single "Doom-control-protocol", accompanied by other streams that are 
used in the same way they are in normal unstructured communications, 
then I think we can expect the caller to figure it out well enough.

> The same is true of PTT. Sprint PTT and OMA PTT are different services.
> They work differently.  You can't tell the difference from the presence
> visible characteristics.

The reason they work differently is because they are still emerging 
services. I still think this is all about the floor control, and is 
otherwise just unstructured communication. If they can claim to be sip 
based at all, the differences between them should be representable in 
signaling, and we should be able to represent that as capabilities.

They may indeed be incompatible at the moment. I would expect that to be 
reflected as different features that can be negotiated, or not, such as 
different floor control protocols, different sorts of media streams, or 
something like that. If they are more radically different than that, 
then maybe they shouldn't be claiming to be sip at all. (As Jonathan has 
suggested.)

As best I can tell, from the perspective of an endpoint, multi-party PTT 
is just a conference call where one-speaker-at-a-time is being enforced 
with floor control. The floor controller happens to have a special goal 
in mind as it manages the floor - to limit the bandwidth to each of the 
endpoints, but this need not be known by the endpoints. And 2-party PTT 
is just a special case of the multi-party version.

So I don't see why it is rocket science for a UA to figure out what it 
should do when PTT is presented as a decomposed set of capabilities.

> I think this is an unsolvable problem; we will never be able to infer how a
> service works, and thus how to make a good endpoint, if all we have are the
> presence visible characteristics. 

I think we can for the 90% of the cases involving unstructured human 
communication. If you like, consider that as a default "service 
description". I have no problem moving on to discuss how to represent 
the other 10%. And we've already made a start at the rest, by being able 
to describe answering services (message-taker), attendants, and 
automata. Clearly this isn't complete, and there is some doubt about how 
many dimensions are required to do the description, but it is still a start.

We have a gap in that AFAIK we don't yet have a way to describe in a 
tuple that floor control is available and/or required, and what that 
means. There is of course considerable overlap with the conferencing 
work in this regard. It should be possible to provide presence for a 
conference. Perhaps you would consider a conference to be another kind 
of service - different from unstructured conversation with a human. But 
often that is an *optional* capability. (I can call a conference without 
knowing that is what it is, and have a satisfactory experience.)

> I think services are always defined by a
> document that describes the service with sufficient detail that an excellent
> client could be built.   It may be possible for a general purpose device to
> initiate a session with a service it was not built for, and get an
> acceptable enough user experience, but if you wanted a good user experience,
> you need to know how the service works.

As above, *if* you can have an acceptable experience without 
understanding this, then the rest is all *optional*, and can simply be 
another attribute or capability.

What you are describing doesn't sound all that different to me than a 
resume of the person who will answer the call, or a description of the 
screen size of the video screen at the far end.

> I think we need to uniquely name services, and have the name be associated
> with a document.

I think more than anything we have a terminology problem, and solving 
that might go at least half way to solving our other disagreements.

The problem is with the term "service". In the presence model Jonathan 
has defined it, and it is what a tuple describes. You are using the term 
differently. It seems that you consider a service to be a "type" 
described by one of these documents. And then presumably you associate 
each tuple with one of these types. So in your terms there could be 
several tuples in a presence document, each being a distinct instance of 
the same service.

We can't use the same term both ways. I suggest you choose a new term. 
We had a couple of bad names used earlier in this thread - D2 and D3. 
But I think it would be best if you choose a term and define it the way 
you think it should be defined, but in a way that is consistent with the 
presence model.

	Paul

> Brian
> 
> 
> 
> 
>>-----Original Message-----
>>From: Henning Schulzrinne [mailto:[email-masked]]
>>Sent: Monday, February 07, 2005 10:57 PM
>>To: Brian Rosen
>>Cc: 'Paul Kyzivat'; 'Simple WG'
>>Subject: Re: [Simple] Three dimensions of service
>>
>>
>>
>>>Here is an example of where I am lost.  I haven't the faintest idea of
>>
>>what
>>
>>>you mean.  The "semantic content of a resulting session" can't be known
>>
>>to
>>
>>Obviously, for many normal conversations, the semantic content is not
>>defined beyond "human-to-human conversation". But for many of the
>>services that have been used as examples, they are precisely
>>distinguished by the fact that they don't lead to normal human
>>conversation, but instead to talking to a Doom game engine or other
>>services. For some human-to-human communications, semantic content can
>>be described to the extent that it is useful to distinguish tuples; see
>>my airline information example. While the Delta airlines rep may be
>>willing to talk about the weather and your new startup company if
>>pressed, they may still want to advertise the service as "flight
>>information".
>>
>>
>>
>>>anyone but the humans; not even the automatons know what the semantic
>>>content is.  The semantic content of the protocol mechanisms used to
>>>establish the session might be specifiable, but I don't get that we are
>>>arguing about that exactly, although we are discussing what the semantic
>>>content of a tuple is.
>>>
>>>
>>>Not necessarily, and I'm not really sure if that is needed here.  What
>>
>>we
>>
>>>need really is just to make sure that when a service is called out in a
>>>tuple, both ends understand what it means, and for that, a unique ID,
>>
>>which
>>
>>>is bound to some kind of document, is sufficient.
>>
>>We discussed indirection before (it was offered by somebody else) and
>>there seemed to be agreement that indirection simply defers the problem
>>to agreeing on what this document might contain. A description in
>>unstructured English prose isn't any more useful than a notes field.
>>
>>
>>
>>>
>>>>What kinds of things would you expect to be in that, in order to
>>>>describe "how they work"?
>>>
>>>What media streams are supported, and how they relate to one another,
>>
>>what
>>
>>>kinds of control mechanisms (such as floor control) are supported, and
>>
>>how
>>
>>>they relate to the media streams.  Things like that.
>>
>>That's all D1 and D2 stuff.
>>
>>
>>
> 
> 
> 

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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 17 Feb 2005 12:46:23 -0500

At what point has one crossed over the line to being notified of what
communications capabilities are possible and actually being already
involved in the communications?

The example of the status of the Doom game below has parallels to
conference control:  who is chair at this moment, who is speaking, etc.
I can see how presence could be used to do floor control.  Perhaps the
subscriber only want to know that you are capable of doing Doom or
conferencing, but not interested in any of the blow-by-blow action in
progress.

Mike

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Henning Schulzrinne
>Sent: Thursday, February 17, 2005 9:03 AM
>To: Aki Niemi
>Cc: 'Simple WG'
>Aki Niemi wrote:
>> The requirement from my point of view is: One needs to be able to 
>> indicate finer grained status for a "service" than a simple on/off.
>> Capabilities can only go as far as indicating on/off status, but 
>> that's not enough.
>
>If I understand you correctly, this is much more closely 
>related to activities than to a capability.
>
>
>> 
>> For example, even with a "game/doom capability", you'd still 
>need to be 
>> able to indicate things like whether you're hosting, in deathmatch, 
>> idle, or practicing at the moment. Each state would be 
>represented to 
>> the user in the form of a different icon, for example, all very much 
>> dependant on the "service".
>
>The game state indication seems like a natural extension to the 
>'activities' element in RPID. This, along with other RPID element, 
>provides context to the open/closed  status and thus qualifies 
>it to the 
>watcher.
>
>RPID already has a 'status-icon', which seems rather close to what 
>you're proposing.
>
>
>> 
>> But again, we don't need to define anything except to say that such 
>> extensions (I believe D3 in Henning's terminology) may exist, and 
>> probably should go under the <status> element.
>
>I don't think this is a capability necessary to ensure connectivity 
>(which is what I meant D1 through D3 to describe at various layers).
>