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

From: "Brian Rosen" <[email-masked]>
Date: Wed, 2 Feb 2005 08:50:08 -0500

I don't think we have a prayer of making a Doom game with audio and video
streams as well as the game stream work in presence without having a notion
of service that has some kind of name which is used to describe the service.
That service description can be text as long as it is unique enough that the
watcher (client) can render some good enough UI and the watcher (human)
understands what to do with it.

So if someone defines "Doom" as being a service that has a game stream and
optional audio and video streams, then you can build a watcher that
understands what Doom is and render a very nice interface with, say, a Doom
icon, and a basic watcher can show the name of the service and the media
streams on it that a human can interpret it.  I think we all agree that, at
the very least, the presence of the Doom service is contained in one tuple.
The only thing you really would like to understand about service is name and
the fact that it can contain multiple streams and multiple capabilities.  

I don't think you can infer this notion of service from the aggregate of
capabilities, and I don't want to try.  You can DEFINE a service as having
some fixed and optional capabilities with the watcher being able to discover
which of them a particular presentity has available at a point in time.
That we can do.  So don't guess that audio and/or video with half duplex and
floor control MEANS PTT, instead DEFINE PTT as a service that has audio,
optional video, half duplex and floor control and let a tuple state that the
presentity supports a PTT service and at the present time only has audio
(not video) available. 

Then I can offer a Telephone service and Doom service, both of which support
audio, and we won't get anyone confused.

Brian	

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, February 01, 2005 1:51 PM
> To: Brian Rosen
> Cc: 'Aki Niemi'; 'Simple WG'
> Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try
> atdata model compromise regarding unique service URI)
> 
> 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: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Feb 2005 09:52:16 -0500

I agree that we need a separate dimension for identifying the content of 
media streams or services. This seems orthogonal to capabilities. In 
some cases, there might be a way to enumerate the service in some 
pick-from-list manner, in a MIME-type fashion, in many others this is 
likely to be pretty useless.

Picture the availability for delta.com (the airline), which might 
include services for flight information, international and domestic 
reservations and probably many more.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Feb 2005 16:53:23 -0500

> likely to be pretty useless.

We have started down this path with:
- attendant
- message-taker

I always had a feeling this was the beginning of a slippery slope.

I suppose I could imagine some kind of registry. But I can't quite 
imagine what criteria would be used to decide what to name - there would 
probably need to be some kind of taxonomy. (This starts to look like the 
yellow pages.)

I'm not convinced we want to go much further down this slope. So far I 
think the cases people have made that they need this are pretty weak. 
While it is possible to structure your implementation to need this, so 
far I think it is also possible to structure things so that isn't needed.

> reservations and probably many more.

Yup. This is really starting to look like the yellow pages.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Feb 2005 15:23:44 -0500

I agree we don't want yellow pages in presence (and, for the case I 
mentioned, this wouldn't even help, since all of these would be listed 
under "airlines"...). I think the sane and simple solution is to use the 
notes field and possibly an icon hint.

Paul Kyzivat wrote:
>> I agree that we need a separate dimension for identifying the content 
>> of media streams or services. This seems orthogonal to capabilities. 
>> In some cases, there might be a way to enumerate the service in some 
>>> the fact that it can contain multiple streams and multiple 
>>> capabilities. I don't think you can infer this notion of service from 
>>> the aggregate of