Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try atdata model compromise regarding unique service URI)

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Feb 2005 13:51:02 -0500

Brian - inline.

	Paul

Brian Rosen wrote:
> I've pretty much stayed out of this whole set of threads, but this one
> really had me wondering where everyone's head is again.
> 
> We're getting wrapped around the axle of not having a definition of
> "service" again.

Well, we had decided that a service is whatever a tuple describes.
But functionally I agree it has still not really been resolved.

> Specifically, I believe that the Doom case you describe below is a Service
> called Doom that has a number of media streams it supports.  It does NOT
> offer a voice SERVICE, the DOOM service includes game, audio and video media
> capability.

I infer that you are using "service" to denote what kind of 
functionality is provided via the communication channel(s) described.

So in this case there is an automaton executing the Doom game, providing 
a rendering of that via the output streams, and accepting input to it 
via the input streams.

> Now the TUPLE might offer a voice SERVICE, in addition to Doom, possibly
> using the same hardware, possibly not.  You don't care. 

We currently have no definition of, or way to describe, services such as 
these. The closest we can get to this right now is via a few attributes:

- automaton
- attendant
- message-taker

If all of those are false, in absence of any extentions, I think you 
have a "conversational" service facilitating interactive conversation 
with a human being.

Even with the limited range of "service"s that can be represented via 
those attributes, it is impossible to say in a single tuple that you 
have a conversational service and an automated message taking service, 
except in the negative - by saying nothing about what is provided.

> PTT is a SERVICE.  It supports voice, possibly video and has floor control.

 From what I have inferred above, I don't see how this can be considered 
a service. It says nothing about the content, and its not an automaton. 
It simply provides different ways to control the media in a 
conversational session - like a different codec does.

> But there is nothing in the set of capabilities such as: audio=true,
> video=false, duplex=full, floor-control=false that could possibly indicates
> PTT isn't there.  A dumb but straightforward audio conference phone could
> have exactly the same capabilities.  The dumb conference phone could have
> that also.  The "floor control=true" and "duplex=half" capabilities, in
> particular, are not peculiar to PTT.  A cell phone with PTT today would have
> at least two services (voice and PTT).  Today, those services are separate;
> even the voice path is separate in many implementations.

Why is this any different than audio vs video? I might want to have a 
conversation with you using any of those, and switch back and forth 
between them during the call. I think I know the answer, but its not an 
appealing one - the UA will simply not permit mixing the capabilities in 
a single call, or even switching among them serially within a call. Of 
course there are lots of technological excuses for this, but it makes no 
real sense from a user standpoint.

I can at least imagine using PTT to talk to a VM "service" or auto 
attendant "service". This all suggests to me that PTT is not a service 
in the sense that Doom might me.

The PTT case is, I think, just a matter of wanting a way to describe 
mutually exclusive combinations of capabilities. I believe we agreed 
some weeks ago that this was potentially still of interest, but 
postponed dealing with it. Until then, multiple tuples with the same 
contact provides a way at the expense of being ambiguous about what is 
intended.

I have been trying for years now to understand what you "service" 
oriented people are talking about. It always seems like there is 
*something* there, but its elusive, and you don't all seem to have the 
same concept. I think there may be some opportunity to describe this as 
the behavior behind the media, encompassing VM, Attendant, Doom.

> And please keep in mind that I want to be able to offer a presence service
> with ONE contact, which I assumed was one tuple, but don't care if there are
> multiple tuples as long as they have the same contact URI.  That represents
> the presence information of the presentity, full stop, including all of the
> services it might support. 

You have been quiet for so long now that I thought you had got the 
correct religion, or fallen asleep, or something. :-)

If you are going to offer a single tuple, and hide both a conversational 
voice service and Doom behind it, I don't see how you are going to avoid 
  disappointing someone. Somebody is going to end up on their phone 
talking to a doom game.

> Brian
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>Of Paul Kyzivat
>>Sent: Tuesday, February 01, 2005 9:58 AM
>>To: Aki Niemi
>>Cc: Simple WG
>>Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try
>>atdata model compromise regarding unique service URI)
>>
>>
>>
>>Aki Niemi wrote:
>>
>>>
>>>ext Paul Kyzivat wrote:
>>>
>>>...snip...
>>>
>>>
>>>>For devices with the real estate, it would be better to simply display
>>>>multiple icons for each buddy indicating what capabilities are
>>>>currently available. (Perhaps icons of phones and cameras can turn
>>>>from red to green.)
>>>
>>>I don't buy this. Think of a "doom" icon that can be either red, green,
>>>or  indicate deathmatch. Capabilities are uninportant, it's the service
>>>that is composed of those capabilities that is important.
>>
>>I don't understand your point at all.
>>
>>It seems to me that either:
>>
>>- you have a separate tuple/service for Doom, with its own unique
>>   contact that I can call. In this case doom itself may have
>>   "doom" capability, and perhaps audio, video, etc. as well.
>>
>>   you then have other contacts with differing sets of capabilities
>>   and different contact addresses. Perhaps one with basic voice.
>>
>>- you have a single multipurpose tuple/service. It has capabilities
>>   for voice, and maybe doom as well.
>>
>>- you have multiple tuples - one for doom, another for basic voice,
>>   but they share a contact address.
>>
>>The question is, how do I know what to expect when making a call in each
>>case? E.g. if I make a voice-only call, do I talk to you, or do I hear
>>the audio from a doom game I can't control?
>>
>>I guess it depends a bit on how you expect doom to work. Do you imagine
>>it to consist of a game control protocol plus audio and video streams
>>rendering the game?
>>
>>
>>>And do you really think users will generally be happy to interpret that
>>>someone is available for push-to-talk by examining a set of three (or
>>>more) icons?
>>
>>I see a couple of alternatives here:
>>
>>- the user has a PTT application displaying presence. It is only
>>   interested in PTT, so it filters what it displays. All I get is a
>>   list of buddies with red or green status.
>>
>>- the user has a general purpose presence client, that can do PTT,
>>   regular voice, video, Doom, whatever. (The user has to both pick
>>   a buddy and then pick an action to do something.)
>>
>>   In this case, it has three or more things to display regardless
>>   of how the RPID document is formatted. Either it has multiple
>>   capabilities for a single tuple, or it has multiple tuples each
>>   with (potentially multiple) capabilities. There are many ways
>>   of rendering each of these, but the fundamental complexity of
>>   what is to be rendered is pretty much the same.
>>
>>
>>>>You seem to have in mind a "video service" that includes both voice
>>>>and video, and a separate "audio service" that includes only audio.
>>>>And then either or both can be available.
>>>
>>>
>>>I gave an example of *three* different services. But fine, let's say you
>>>only have two: a videophone capable of both video and audio (together or
>>>separate) and a push-to-talk client (audio, half-duplex and floor
>>>control). Now, let's say video is unavailable, audio is available, and
>>>push-to-talk is unavailable.
>>>
>>>How would you represent that in a single tuple?
>>
>>I left out the PTT to keep things simple, since I don't think we have
>>agreed in detail how to represent it as a capability. But lets try anyway.
>>
>>In the state you describe it, I would simply represent it as a tuple
>>with audio=true, video=false, duplex=full, floor-control=false. What is
>>so hard about that?
>>
>>
>>>>But how is this better (or even as good as) a single videophone
>>>>service that is capable of supporting both voice and video, or just
>>>>voice, or just video, depending on what is negotiated in a call? With
>>>>such a service, if I don't want to be available for video, I just
>>>>disable it, so it won't be offered or answered, and then video then
>>>>isn't advertised in the (single) presence tuple either.
>>>
>>>
>>>I'm not going to debate over details about voice and/or video. My
>>>attempt was to demonstrate that there are "services" that aren't going
>>>to be described only using a single, simple media attribute, like
>>>"voice" and "video", but will be composed of a set of capabilities,
>>>where this capability set then shares a status that will have more
>>>states available than simple on or off.
>>
>>Ahh. This may be hinting at the real issue. But it is only a hint, and I
>>think you need to say a lot more to establish the use case. I've got a
>>feeling that PTT is a bad example because its "differences" are more
>>about limitations in the technology that intrinsic feature differences.
>>
>>I suspect Doom may be a better example. I have the idea that what you
>>have in mind is that when I call the "Doom Service" I get audio and
>>video that are slaved to the game, rather than a conversational adjunct
>>to the game that allows me to converse with the other player(s) while
>>playing. If so, then it is a lot like an IVR or a VM server. If so, then
>>I agree with you that it *should* be represented as a separate tuple.
>>But I also think it *should* have a separate contact, so that it is
>>clear how to reach that particular service.
>>
>>I gather you have in mind that if I negotiate the doom control protocol
>>I will get the doom service and the audio/video will be slaved to it,
>>but if I don't negotiate the doom control protocol then I get the
>>"conversational" service managing my voice/video. I don't see why I
>>would be able to draw that conclusion from the RPID.
>>
>>
>>>However, stepping back for a moment.
>>>
>>>Seems there is still some fundamental desire here to restrict the
>>>presence data model to suit the "unique-URI" concept.
>>>
>>>But like Henning has pointed out many times before, there will be
>>>multiple tuples in a document. So inherently, the watcher is faced with
>>>having to make a selection. Henning has also pointed out that to
>>>determine uniqueness, the contact is a very poor key to use. Whether
>>>some of those tuples have the contact address is therefore immaterial
>>>(and depends exclusively on the uniqueness rules of the URI scheme).
>>>Also, we aren't going to forbid a dumb composer passing all of the
>>>received tuples to the watcher using the union composition.
>>
>>In most cases I see no reason why the watcher has a need to determine
>>uniqueness. All it has to do is present the alternatives to the user,
>>let the user choose one, and send a request to the contact of the one
>>chosen. The kind of request sent can either be determined by default
>>based on capabilities advertised in the tuple and local capabilities, or
>>can be adjusted based on explicit choices made by the user.
>>
>>
>>>If we were to *mandate* that all SIP-enabled services are represented
>>>using a single tuple, where would you enforce this rule? And what would
>>>be the benefit compared to allowing more than a single tuple?
>>
>>I'm not sure this is something to mandate. I think it is more of a "best
>>practices" kind of thing. It seems clear that people are going to do a
>>bunch of weird things, and results will vary. About all we can do is
>>give suggestions on how to get a good result.
>>
>>
>>>Simply saying that it is possible in some instances to do things that
>>>way is not a good enough reason, if there are instances where it does
>>>not work.
>>
>>I think this might best be approached by restarting the work on presence
>>use cases.
>>
>>Here is (a bad) one, based on what I think you have in mind. (Please
>>feel free to provide a better way to handle this case.)
>>
>>Suppose your presence includes one tuple listing audio, video, and doom.
>>My presence client doesn't understand doom or video, so it simply
>>renders the tuple as available for voice. I pick it and make a voice
>>call. Your Doom service slaves audio to the game, so I just hear a bunch
>>of bleeps and gun fire. I am likely to be annoyed with you for having
>>announced that you were available for voice when you were not.
>>
>>Or, your UA refused my call because I didn't offer doom control
>>protocol. I'm still annoyed that you said you were available for voice
>>but refused my call. (But at least this is within the realm of
>>reasonable behaviors.)
>>
>>	Paul
>>
>>
>>_______________________________________________
>>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: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Feb 2005 16:33:54 -0500

Brian Rosen wrote:
> I think the basic model is close to Doom-3, but a bit different from what
> you describe it.  It's not Doom-1 or 2.
> 
> First of all, the audio and video in a Doom game that are the actual Doom
> visual and auditory outputs of the game are locally generated.  The Doom
> control protocol is all that is needed for the basic game.
> 
> I think if there is audio, it's a conference call-like open audio channel
> between players.  As in Doom-3, it would be locally mixed with the local
> Doom game sounds.  It could have PTT, it could have a notion of "side" (ie
> normally I talk to only my side, but I have a floor that lets me talk to all
> the players), but it's defined by the Doom game what it does and how you use
> it.  It's not a general purpose telephone, and it's unlikely to be precisely
> the mobile guy's notion of PTT.  That's what I would do.  Someone else may
> define it differently.  However it's defined, it's an audio service
> specifically specified for Doom.  The audio and game control are intertwined
> into the Doom service.  You can't infer how it works; you need to read the
> description of it in the Doom service. 

This could be refined further, but I don't know if we want to do that.
It sounds to me that the media other than the game control are however 
close enough to what they "normally" mean to be considered "normal". It 
would be pretty reasonable to me for a Doom game machine that supports 
this to answer a voice-only call. The game player then talks while 
playing his game, and the other party only talks and listens. So the 
caller being a regular phone works fine. If this game machine originated 
a call, while it would presumably offer doom-protocol, with voice 
perhaps optionally being offered. If voice was offered, and the 
recipient accepted voice and not the doom-protocol, it would again make 
sense for it to work. (I am using the principle of least surprise here 
to decide what I consider to be reasonable.)

> Probably, someone wrote a spec for
> it and published it.  Probably, they registered the service name with IANA.

Is this just an off-hand suggestion, or are you referring to some real 
IANA registry that already exists?

If there is one that already exists, that you think is applicable here, 
then lets discuss it. If not, then that becomes yet another item of work 
which we may or may not want to take up. Seems analogous to what Henning 
mentioned, for describing media *content*.

> That lets multiple implementations of the client exist and interoperate. You
> don't know, for example, unless you understand the Doom service, if it makes
> any sense to run the Doom game stream without the audio or vice versa.
> 
> 
>>I don't get this. The floor control is the essence of PTT. Otherwise it
>>is just audio. As Jonathan has pointed out, this may be a case where the
>>implementation won't allow you to negotiate a session without the floor
>>control. If so we need some way to indicate that. But that is the only
>>special thing.
> 
> Nope, floor control is not the "essence" of PTT, it's just one of its common
> characteristics.  You can have floor control without PTT. 

Certainly true. My impression is that what is special about PTT is that 
currently the floor control protocol is special for PTT. If PTT used a 
"standard" floor control that was also implemented as part of a generic 
conference server, then you wouldn't be able to tell the difference 
between doing PTT and calling such a conference server.

> You actually can
> have PTT without floor control; a real radio system is PTT without floor
> control -- you push the button and talk -- if two people do it at the same
> time, third parties hear one or both, and the two speakers don't hear each
> other.  Some PTTs assume half duplex, others don't.  You can define a PTT
> service that is half duplex, and another that is half or full duplex.  There
> isn't going to be ONE PTT service, their probably will be more than one.

I think you can imagine various ways of implemented "PTT", as you 
describe. But I don't think you need a registry of different flavors of 
"PTT Service" to understand these. The only things that seem to matter 
here are:
- what kinds of media streams are included
- what floor control protocol (if any) is negotiated
- whether the stream(s) are "half duplex"

The half duplex is problematic, because its meaning in the context of 
sip isn't well defined. We probably ought to either get rid of it, or 
define what it means operationally. I can think of two ways to define it:
- half-duplex-1: a=sendrecv isn't allowed. Direction of communication
   is negotiated via offer/answer.
- half-duplex-2: this session requires a floor control protocol

With all of this I think what needs to be done can be understood 
entirely by the combination of the various attributes.

	Paul