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

From: Aki Niemi <[email-masked]>
Date: Tue, 01 Feb 2005 15:44:05 +0200

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.

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?

...snip...

>> Even further, for some services, audio can be "on" while for others 
>> "off". Take for example, push-to-talk, voice, and video call in a 
>> single device. How can you describe a different stratus for each of 
>> these services using a single tuple?
> 
> 
> I still don't understand your model of how the device works.
> 
> 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?

> 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.

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.

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?

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.

Cheers,
Aki

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Feb 2005 09:57:32 -0500

Aki Niemi wrote:
>> 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 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?

> someone is available for push-to-talk by examining a set of three (or 

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 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.
> 
> 

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.

> 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.

> 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.

> way is not a good enough reason, if there are instances where it does 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 1 Feb 2005 10:49:21 -0500

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.

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.

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

PTT is a SERVICE.  It supports voice, possibly video and has floor control.
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.

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. 

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...
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Feb 2005 02:14:24 -0500

inline.

> but refused my call. (But at least this is within the realm of 

We've touched on this kind of case before. Its another example of a case 
where there is a mandatory feature or media stream that needs to be used 
by the watcher in order to connect. If you want this, I think it is far 
preferable to explicitly state that. That makes it more than just a 
capability, so its not just a prescaps issue.

We ran into this previously for PTT, where folks wanted a way to say 
that you HAD to use this floor control protocol. I recall advocating 
that a non-SIP URI might even be the best way to handle these things 
since they are arguably not really SIP proper.

However, I think Aki's case is different still. The example he has been 
giving is "I'm available for IM, not for audio". This is not saying that 
a watcher has to use both IM and audio, and thus seems different from 
the doom case.

I think what it means is that the actual status of communications is no 
longer readily expressed as OPEN/CLOSED. Rather, it is effectively a 
boolean function over a set of session characteristics. In other words, 
whether I am available depends on the details of the session. Here, I'm 
available if we have IM only, but not if we have audio.

One can imagine complex boolean functions which are not readily 
decomposed in a way that makes them amenable to representation using a 
number of separate tuples each just with a simple OPEN/CLOSED.

For example, what if I want to say that I'm available if you have audio 
AND video, but not if you use audio alone or video alone. Admittedly 
this is a stretch, but this seems harder to do using separate tuples. 
Worse case with N variables you could require 2^^N tuples. Yuck.

I would suggest that another approach would be to define an alternative 
status indication that actually contains the boolean function:

<available-bool>(AND (EQUAL audio TRUE) (EQUAL video true))<available-bool>

where I am using rfc2533-style syntax for boolean expressions.

As Paul suggested, I think the <basic> status here would still be OPEN, 
but this more complicated status would provide more complex information 
about availability.

To be clear - I don't think any of this impacts the compromise position 
we have reached around the data model; rather this discussion is follow 
on to help us sort out what multiple tuples might mean in different cases.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Feb 2005 02:18:47 -0500

inline.

Paul Kyzivat wrote:

>>> How is it that the compositor knows the GRUUs are all bound to the 
>>> same AOR? It knows they are bound to the same domain, but AFAIK 
>>> nothing more.
>>
>>
>> I was assuming a compositor that had access to registration data.
> 
> 
> The public registration data (available via reg package), or the 
> complete set of private registration data.

Either, possibly. I happen to think that it is more likely that there 
will be a tight coupling between providers of the registrars and 
presence servers, so the private registration data can be provided 
through proprietary interfaces. If this is not the case then reg-event 
needs to be used.

> 
> The current reg package doesn't give info on GRUUs, so you wouldn't be 
> able to figure this out from that.

True. Thats a known bug which we would need to fix in order to 
ultimately do this.

> 
>>>> GRUU PUA, union compositor: This produces a document that exposes 
>>>> the GRUU to the watcher. Still works fine, though it may not have 
>>>> been desireable to expose the GRUU to the watcher.
>>>>
>>>> GRUU-less PUA, smart compositor: The compositor can correlate the 
>>>> tuples together because they each use the AOR as the <contact>. 
>>>> However, because there is no GRUU, it can't as easily correlate each 
>>>> tuple with a registration that might exist for the UA that generated 
>>>> the PUBLISH. Such correlation would need to be supported through 
>>>> other tuple data.
>>>
>>>
>>> Hmm. You mention the compositor correlating PUBLISH data from PUAs 
>>> with registration data. This is the first mention I have seen of that. 
>>
>>
>> Oh? The whole model we have is based on multiple sources of data...
> 
> 
> Sure it has always been a potential. But we had never gotten into such 
> specifics. If it becomes *necessary* to access registration data to make 
> a compositor, then we had better make that very clear.

I don't think its ever NECESSARY, but it sure would be nice.

As an example, I have heard complaints that it seems redundant that when 
a client device turns on, it would have to *both* REGISTER and PUBLISH 
to indicate availability. If a presence server had direct access to 
registration data, the extra PUBLISH could be avoided.

-Jonathan R.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 02 Feb 2005 08:59:25 -0600

> on to help us sort out what multiple tuples might mean in different cases.

Jonathan:

With a lot of email floating around on this subject, it may help
to enunciate the compromise position(s) we have reached.  I took
a stab at it last week -- see
http://www1.ietf.org/mail-archive/web/simple/current/msg04919.html

If this is helpful, I will update it to reflect the latest
developments.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Feb 2005 09:46:59 -0500

The complexity, compared to the incremental value, seems rather scary.

 From a watcher perspective, I fail to see the substantial difference 
between this complicated version and simply saying

"I'm open for IM" (I might sometimes also do audio, but I'm not right 
now, so this is irrelevant), expressed as prescaps

What advantage does it have to "tease" the observer that I might have 
some other capability at some other time, left undefined, but I won't 
let you have it? (If I know that I will have this capability at some 
future point, timed status would be the appropriate mechanism to express 
this.)

I'm rather concerned about conveying and having users understand fine 
philosophical differences between degrees of unavailability.

Jonathan Rosenberg wrote:
>> 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.
>>