Subject: [Simple] another try at data model compromise regarding unique service URI

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Jan 2005 00:56:02 -0500

I'll be responding to various messages in the threads we had on the
modeling dispatchers topic. However, I concluded a few things from my
previous compromise proposal (adding an i-belong-to element):

1. there was general agreement that i-belong-to was reasonable, since
more information can't hurt

2. even with i-belong-to, there still seemed to be a desire to support
non-unique contact URIs, when in fact part of the reason I had proposed
i-belong-to was to retain that feature of the data model

3. There was (perhaps) some dispute about whether we need to resolve the
issue of unique contact URI or not for the data model. I believe we do.
I agree
with the approach of pushing off composition for another document, but
the issue of how we name and identify a service, and how you can or
cannot select those services from a presence document, is central to the
data model and needs to be resolved one way or another.

4. I appear to be in the losing minority on the issue of unique URI or
not. It appears Aki and Henning still favor allowing multiple tuples
with the same contact URI. I believe Markus and Paul do as well, but am
not as certain.

5. We've identified several real problems when you rely on things
besides the URI to dispatch to the appropriate service:

    a. it doesnt work with an offerless invite, as in the case of 3pcc.
Like it or not, this is a common case

    b. it doesnt work with cases where my initial SDP does not cause the
appropriate dispatch, but a subsequent re-invite would. For example, I
want to call your videophone, but I want to start with just audio so I
can ask about adding video.

6. We agree to allow simple union-based composition. Henning has
indicated that it is possible that the compositor doesn't understand the
URI schemes in the contact. Thus, a union compositor might generate
presence documents with two URI that are equal. Though I think this is
quite unlikely, it is certainly possible.

 From these things, I concluded that (for reason 6 alone), the data model
cannot outlaw two services from having the same URI. However, it begs
the question of what does it *mean* when that happens. I think that we
are not aligned on this yet. Henning made a statement in one of his
notes that I believe captures the essence of the problem:

Henning wrote:
> There are the following possible cases, all with well-defined
> behavior for the watcher:

I don't think we want to specify the behavior of the watcher at all. 
They should be able to do anything they want to with the data. The key 
to interop is to make the semantics of the data as unambiguous as 
possible. I think that, in the case of multiple services with the same 
URI, the meaning is ambiguous, and depending on what a watcher is 
interested in, might make different choices. Let me give an example.

Lets take an example Aki gave during the SIMPLE meeting in November. He 
was interested in expressing this situation: a user has a multimedia UA 
that can do audio and IM. They want to indicate that they are available 
for IM, but not for audio. Let us say that they represent this by 
including two services in a document (i.e., two tuples) with the same 
contact (their AOR), but one indicating audio with prescaps, and a basic 
status of closed, and the other indicating just IM with prescaps, and a 
a basic status of open.

We have touched on several possible meanings for the case of two 
tuples/services with the same URI:

   MEANING 1 (CONFLICT): These represent conflicting information about 
the same service; one or the other might be true

   MEANING 2 (DISPATCH): These represent different services, but are 
only reachable by a dispatcher (using unknown dispatch logic), and so an 
INVITE sent to the <contact> (which is the AOR), will reach one or the other

   MEANING 3 (COMPONENT): These are one service, but the service has 
been  disaggregated because of a desire to provide differing presence 
status for differing types of communication attempts (this is the 
meaning in the example)

   MEANING 4 (OVERRIDE): An attempt was made to override one service 
definition with another; however, the compositor foolishly placed them 
both in the document. As such, the more recent one is probably correct.

I suspect that there are other meanings.

So, let us consider the differing decisions a watcher might make, 
depending on which meaning it decides to attest to this document. Let us 
assume the watcher wishes to proceed with a multimedia call using as 
many media types as possible:

MEANING 1 (CONFLICT):  The watcher sends an INVITE with an offer 
including both audio and IM media streams, under the assumption that one 
or the other is supported and the presentity will reject one of the 
media streams

MEANING 2 (DISPATCH): Since the service supporting IM is the only one 
available, the watcher wishes to avoid dispatching to the audio service. 
So, it sends an INVITE with only an IM media stream, hoping that the 
dispatch works correctly.

MEANING 3 (COMPONENT): The watcher sends an INVITE with both audio and 
IM. It figures that perhaps the presentity will accept the audio stream 
anyway, and if not, just reject that stream and proceed with IM.

MEANING 4 (OVERRIDE): The watcher sends an INVITE with whichever media 
type is indicated for the most recent tuple.

As you can see, there is clearly a difference in watcher behavior, 
assuming a specific objective, depending on the semantics of multiple 
services with the same URI.

So, in light of this, my specific proposal is that we allow for multiple 
services with the same URI, but in the data model very clearly define 
its meaning as *ambiguous*; additional tuple meta-data will normally 
need to be present to help clarify the actual meaning. As such, the data 
model would recommend against doing this without meta-data to further 
clarify. A watcher could NOT assume that constructing an INVITE 
compliant to the capabilities listed for a tuple would cause a dispatch 
to that tuple, as Aki has suggested. I think this is the kind of 
dangerous assumption that, as my examples above show, can be wrong 
depending on the actual meaning of this case.

In the spirit of Robert's proposal, I would further propose not to 
pursue the <i-belong-to> extension yet. Let us further study composition 
and then figure out the right set of dispatcher characteristics we wish 
to model.

At this time, we could then make the following recommendations regarding 
what a PUA places into the <contact> element. Namely, if it has a GRUU, 
it puts that. If it doesn't, but it has **strong** awareness that its 
local IP address and port have the GRUU property, it uses that, else it 
places the AOR.

If there are multiple PUA for an AOR, and a compositor in the presence 
engine, we can consider four cases roughly speaking. We have PUA that 
support GRUU (or have a local contact that has the GRUU property), or 
don't, and we have a compositor that just does union, or is smarter and 
combines the contacts together:

GRUU-less PUA, union compositor: This tends to do the right thing. The 
resulting presence document includes multiple tuples, each of which uses 
the AOR. The presentity is at least reachable since the AOR is listed.

GRUU PUA, smart compositor: The compositor can combine together the 
tuples, since it knows the GRUUs are all bound to the same AOR. It can 
thus list a single tuple (if it likes), with the AOR as the <contact>

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.

This is not ideal (the fourth case in particular), but it seems workable.

Where does this leave us with override? I still feel strongly that it is 
a mistake to encode composition policy into the presence document 
itself. Therefore, the presence document is simply not the place to do 
anything special in support of override. In further support of Robert's 
proposal, since override is very much about composition, I propose that 
we simply defer this until we have properly defined policy documents for 
defining it.

Can we move forward based on this?

Thanks,
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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 Jan 2005 13:53:42 -0500

> Like it or not, this is a common case

This assumes that SDP is used for service selection. This is not a 
problem if caller preferences or similar mechanisms that do not involve 
offer-answer are used (e.g., request routing based on MESSAGE vs. INVITE).

> can ask about adding video.

This is either solved by caller preferences or kin, or is a generic 
problem that even presence can't solve (if I initially select audio-only 
capabilities). This has little to do with URIs.

> I don't think we want to specify the behavior of the watcher at all. 

I think we're not that far apart. The meaning to the watcher has to be 
clear - even if that meaning has a "cannot say reliably whether A or B 
is true".

> and then figure out the right set of dispatcher characteristics we wish 

With the GRUU discussion and suggestions ("should generally identify AOR 
it belong to") by Paul, this may also not be necessary in a subset of 
cases.

> Can we move forward based on this?

Yes, this seems straightforward.

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 24 Jan 2005 17:17:40 +0100

Jonathan,

Thanks for the summary. The proposal seems adequate. I also see no need 
for the <i-belong-to> element if your proposal is the way forward.

Regards,
Hisham

On Jan 23, 2005, at 6:56 AM, Jonathan Rosenberg wrote:

> Lets take an example Aki gave during the SIMPLE meeting in November. 
> He was interested in expressing this situation: a user has a 
> multimedia UA that can do audio and IM. They want to indicate that 
> they are available for IM, but not for audio. Let us say that they 
> represent this by including two services in a document (i.e., two 
> tuples) with the same contact (their AOR), but one indicating audio 
> with prescaps, and a basic status of closed, and the other indicating 
> just IM with prescaps, and a a basic status of open.
>
> only reachable by a dispatcher (using unknown dispatch logic), and so 
> an INVITE sent to the <contact> (which is the AOR), will reach one or 
> the other
>
> depending on which meaning it decides to attest to this document. Let 
> us assume the watcher wishes to proceed with a multimedia call using 
> as many media types as possible:
>
> including both audio and IM media streams, under the assumption that 
> one or the other is supported and the presentity will reject one of 
> the media streams
>
> available, the watcher wishes to avoid dispatching to the audio 
> service. So, it sends an INVITE with only an IM media stream, hoping 
> that the dispatch works correctly.
>
> IM. It figures that perhaps the presentity will accept the audio 
> stream anyway, and if not, just reject that stream and proceed with 
> IM.
>
> So, in light of this, my specific proposal is that we allow for 
> multiple services with the same URI, but in the data model very 
> clearly define its meaning as *ambiguous*; additional tuple meta-data 
> will normally need to be present to help clarify the actual meaning. 
> As such, the data model would recommend against doing this without 
> meta-data to further clarify. A watcher could NOT assume that 
> constructing an INVITE compliant to the capabilities listed for a 
> tuple would cause a dispatch to that tuple, as Aki has suggested. I 
> think this is the kind of dangerous assumption that, as my examples 
> above show, can be wrong depending on the actual meaning of this case.
>
> pursue the <i-belong-to> extension yet. Let us further study 
> composition and then figure out the right set of dispatcher 
> characteristics we wish to model.
>
> At this time, we could then make the following recommendations 
> regarding what a PUA places into the <contact> element. Namely, if it 
> has a GRUU, it puts that. If it doesn't, but it has **strong** 
> awareness that its local IP address and port have the GRUU property, 
> it uses that, else it places the AOR.
>
> don't, and we have a compositor that just does union, or is smarter 
> and combines the contacts together:
>
> resulting presence document includes multiple tuples, each of which 
> uses the AOR. The presentity is at least reachable since the AOR is 
> listed.
>
> 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.
>
>
> Where does this leave us with override? I still feel strongly that it 
> is a mistake to encode composition policy into the presence document 
> anything special in support of override. In further support of 
> Robert's proposal, since override is very much about composition, I 
> propose that we simply defer this until we have properly defined 
> policy documents for defining it.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jan 2005 18:19:36 -0500

> with the same contact URI. I believe Markus and Paul do as well, but am

I don't like it. But I find the alternatives worse.

My feeling is that this is the way forward. Perhaps composition will 
advance and solve the problem before anything is fielded that exhibits 
this problem. If not, then in cases where this is used inappropriately, 
the results will be disappointing. Then hopefully the offenders will 
stop doing it.

> can ask about adding video.

As Henning pointed out, those are only problems with dispatching based 
on SDP. Dispatching based on something like method and event ID doesn't 
suffer that problem.

Dispatching based on callerprefs also doesn't - if the callerprefs are 
present, and if you can figure out how to dispatch based on them. I 
think it will be difficult to get them there.

> I don't think we want to specify the behavior of the watcher at all. 

I don't think it has been the intent to normatively specify the behavior 
of the watcher. I think this has simply been used as a use case to see 
if what might plausibly be expected to happen has serious problems.

So far, the problems have seemed to be limited in nature and more or 
less expected under the circumstances. But of course it only remains for 
another use case that is more problematic.

> possible.

Without invoking miracles. When the semantics are ambiguous, and nobody 
knows better, best to leave them that way.

> I think that, in the case of multiple services with the same 

Well, I think this is not a good way to represent this situation.
But lets continue anyway, since lots of people seem to want to represent 
it this way.

>   MEANING 2 (DISPATCH): These represent different services, but are only 
> reachable by a dispatcher (using unknown dispatch logic), and so an 

Or both (forking). This would leave it up to the recipient to choose 
which one to use.

> depending on which meaning it decides to attest to this document. Let us 

Part of the problem may be simply assuming that a correct watcher is 
free to make this choice as it wishes. I think we should simply require 
watchers to act on this data as if was ambiguous what the meaning is. 
Leave it to the watching User to ascribe meaning.

> its meaning as *ambiguous*;

OK. I agree with this.

> additional tuple meta-data will normally 

I agree. While there seems to be some value in the proposal, it feels 
half baked.

> thus list a single tuple (if it likes), with the AOR as the <contact>

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.

> 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. It is 
certainly something that is possible in some cases. But seems to need 
some scoping out. For instance, this assumes the PA knows the mapping 
from presentity address to registrar AOR. (In lots of cases this is 
easy, because it is the same. But some people may be thinking otherwise.)

Another case comes to mind:

If the PUAs are GRUU-less, but know something about the compositor, they 
might use their contact even though it is not a GRUU, and depend on the 
compositor to replace it with the AOR, after having used it to correlate 
with registrations. But this presumes the compositor somehow knows it 
should do that. This seems like a weak and ugly case, but it might be a 
pragmatic choice.

> we simply defer this until we have properly defined policy documents for 

Right. I have always thought that override was of more theoretical 
interest than practical.

> Can we move forward based on this?

I think so.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Wed, 26 Jan 2005 13:03:17 +0200

Inline.

ext Jonathan Rosenberg wrote:

...snip...

> both in the document. As such, the more recent one is probably correct.

I guess you're right. I was hoping we would be able to come to an 
agreement, picking just one of these meanings (preferably #3) and rule 
out all others. However, as I read further and as I understand it, your 
proposal is just a different means to an end -- that is, exact meaning 
will need to be prescribed through meta-data in each tuple. And that is 
fine, as long as we define exactly what this meta-data is.

> need to be present to help clarify the actual meaning. 

Exactly, so far so good.

> As such, the data 

All right, but if not capability description, as in method=MESSAGE, what 
meta-data would one put in a pair of tuples to indicate that indeed a 
MESSAGE will be appreciated in this AOR, while an INVITation for voice 
won't (because I'm in a meeting)?

...snip...

> Can we move forward based on this?

Yes, I think so. Perhaps a rough edge or two to smooth out, but this is
an acceptable approach.

Cheers,
Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jan 2005 07:13:25 -0500

inline.

Paul Kyzivat wrote:

> My feeling is that this is the way forward.

What is "this" in the sentence above?

> on SDP. Dispatching based on something like method and event ID doesn't 

It could be an issue there too. One can imagine folks sending SUBSCRIBE 
on an existing dialog, and using INVITE for setting up the dialog. If 
dispatch to something that supports SUBSCRIBE is based on the initial 
request method, this won't work either.

> think it will be difficult to get them there.

This is my point - if the watcher needs to use caller prefs to get the 
dispatch to happen, it needs to SAY that in the presence document.

> if what might plausibly be expected to happen has serious problems.

I had read some of Hennings notes as suggesting that our objective was 
to make sure that watcher behavior was well-defined. I think its 
essential that we be clear that this is not the objective.

>> I think that, in the case of multiple services with the same URI, the 
>> meaning is ambiguous, and depending on what a watcher is interested 
>> in, might make different choices. Let me give an example.
>>

Do you have an alternate suggestion?

> Leave it to the watching User to ascribe meaning.

Without additional meta-data there isn't much of an alternative. 
However, as I show below the wrong thing can definitely happen, and its 
prevented by being more explicit.

>> stream anyway, and if not, just reject that stream and proceed with IM.
>>
>> clearly define its meaning as *ambiguous*;
> 
> 
> OK. I agree with this.

Great.

> 
>> additional tuple meta-data will normally need to be present to help 
>> clarify the actual meaning. As such, the data model would recommend 
>> against doing this without meta-data to further clarify. A watcher 
>> could NOT assume that constructing an INVITE compliant to the 
>> capabilities listed for a tuple would cause a dispatch to that tuple, 
>> as Aki has suggested. I think this is the kind of dangerous assumption 
>> that, as my examples above show, can be wrong depending on the actual 
>> meaning of this case.
>>

Right; as Henning points out it may be unneeded depending on where we go 
with gruu.

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

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

It is
> easy, because it is the same. But some people may be thinking otherwise.)

I think using the same AOR is definitely the right thing.

> should do that. This seems like a weak and ugly case, but it might be a 

I considered that, but this introduces the possibility of a mismatched 
client and compositor. If the client puts its contact in, and its 
something like 10.0.1.1, and the compositor does union, this is a 
systematic failure.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jan 2005 07:05:32 -0500

inline.

> offer-answer are used (e.g., request routing based on MESSAGE vs. INVITE).

Yes. However, the use case of SDP-based dispatch was raised several times.

> capabilities). This has little to do with URIs.

It has everything to do with being explicit vs. making implicit 
assumptions about what needs to do in order to dispatch. My proposal is 
that whatever we decide - caller prefs, SDP, or whatever, we make it 
explicit what the watcher needs to do.

> clear - even if that meaning has a "cannot say reliably whether A or B 

Right.

> it belong to") by Paul, this may also not be necessary in a subset of 

Fair point; we seem to be heading that direction in the gruu discussions.

> Yes, this seems straightforward.

Great, thanks.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jan 2005 07:16:02 -0500

inline.

Aki Niemi wrote:

> out all others.

I think we have a lot of work to do to scope out #3. As Paul hinted as 
well, I'm not even sure viewing them as separate tuples is the right way 
to go. But let us debate this later. In the spirit of Robert's proposal, 
we need to gain some real world usage scenarios and requirements before 
working this stuff.

  However, as I read further and as I understand it, your
> fine, as long as we define exactly what this meta-data is.

Right. And we may or may not define it later...

> won't (because I'm in a meeting)?

<dispatch-criteria>
   <method>INVITE</method>
</dispatch-criteria>

> Yes, I think so. Perhaps a rough edge or two to smooth out, but this is

Can you elaborate on those edges?

Thanks,
Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jan 2005 16:49:41 -0500

Inline. Trimmed out stuff I didn't comment on.

	Paul

> What is "this" in the sentence above?

this = "allowing multiple tuples with the same contact URI".

It seemed obvious to me at the time, but in retrospect it isn't.

>> But lets continue anyway, since lots of people seem to want to 
>> represent it this way.
> 

I have a different way to represent the situation in the first place, 
that I prefer:

The UA only publishes one tuple, regardless of its status. It uses 
prescaps to indicate the availability (or not) of both Audio and IM. It 
indicates it is OPEN if it is available for anything.

Note that there is a case to be made that the tuple should be OPEN if it 
can do anything - perhaps just respond to OPTIONS. So it may be the case 
that it is OPEN, but not available for either Audio or IM.

>>> If there are multiple PUA for an AOR, and a compositor in the 
>>> presence engine, we can consider four cases roughly speaking. We have 
>>> PUA that support GRUU (or have a local contact that has the GRUU 
>>> property), or don't, and we have a compositor that just does union, 
>>> or is smarter and combines the contacts together:
>>>
>>> GRUU-less PUA, union compositor: This tends to do the right thing. 
>>> The resulting presence document includes multiple tuples, each of 
>>> which uses the AOR. The presentity is at least reachable since the 
>>> AOR is listed.
>>>
>>> tuples, since it knows the GRUUs are all bound to the same AOR. It 
>>> can thus list a single tuple (if it likes), with the AOR as the 
>>> <contact>
>>
>> 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.
> 

The public registration data (available via reg package), or the 
complete set of private registration data.

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

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

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 think using the same AOR is definitely the right thing.

I gather that various people have in mind a Presence Server that is 
independent of the SIP provider. In that case the registration info may 
not be readily accessible. Mapping from presentity address to sip AoR 
may be available of PS is *subscribing* for presence data of the SIP 
AoR, but may not be if it is relying on PUBLISH to learn this.

---

From: Aki Niemi <[email-masked]>
Date: Mon, 31 Jan 2005 16:56:07 +0200

> we need to gain some real world usage scenarios and requirements before 

At this point I'm not too hung up on the idea of separate tuples either. 
  But to me it seems like the cleanest (if not the only) way to enable 
things like: "I am open for IM, but busy for voice". Since I guess a 
tuple is still supposed to share the basic status, or will we need to 
now group all things OPEN into one tuple, and all things CLOSED into 
one? Yuck!

Unless you are disagreeing with me that this is a real world usage scenario?

...snip...

> Can you elaborate on those edges?

Edge 1: moving from saying "non-unique contacts are forbidden" to 
"non-unique contacts are allowed but meaningless without meta-data to 
give explicit meaning" and then not defining this meta-data at this 
point is not progress.

Edge 2: breaking SIP-things into components must still work. I must be 
able to say that doing SIP IM with me is ok, but voice I'd not prefer 
(because I'm busy for example). Therefore I'd count the component 
meaning as something we need to solve in the first stages.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Jan 2005 10:30:52 -0500

> now group all things OPEN into one tuple, and all things CLOSED into 

I think basic status is just too crude to be of use for a sophisticated 
device. So give up on it. Only indicate CLOSED when you can't do 
anything. OPEN means you can do something, but exactly what is all in 
other attributes.

For a watcher, it means a little extra work to decide whether to make 
that icon green or red. Instead of basing that on OPEN/CLOSED, green 
comes from OPEN plus some capability that the watcher can use. For a 
voice-only watcher, its OPEN+audio.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Mon, 31 Jan 2005 18:23:16 +0200

ext Paul Kyzivat wrote:
>> At this point I'm not too hung up on the idea of separate tuples 
>> either.  But to me it seems like the cleanest (if not the only) way to 
>> enable things like: "I am open for IM, but busy for voice". Since I 
>> guess a tuple is still supposed to share the basic status, or will we 
>> need to now group all things OPEN into one tuple, and all things 
>> CLOSED into one? Yuck!
> 
> 

I was talking about things that go beyond <basic>. The PIDF structure is 
simple: it has a <status> element, that describes the status of the 
tuple. It can have OPEN + some.

> voice-only watcher, its OPEN+audio.

So you're still advocating a black-and-white world (or green-and-red 
world), where something is either on or off, and can never exhibit finer 
grained status?

Sorry, but my world is not binary, but a service can be in 
"do-not-disturb", "busy", "inconvenienced", "actively sending" and a 
host of other non-standard statuses -- including ones that are not 
standardized, or come in the form of freetext notes.

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?

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Jan 2005 12:36:25 -0500

Aki Niemi wrote:
>>> either.  But to me it seems like the cleanest (if not the only) way 
>>> to enable things like: "I am open for IM, but busy for voice". Since 
>>> I guess a tuple is still supposed to share the basic status, or will 
>>> we need to now group all things OPEN into one tuple, and all things 
>>> CLOSED into one? Yuck!
>>
>> I think basic status is just too crude to be of use for a 
>> sophisticated device. So give up on it. Only indicate CLOSED when you 
>> can't do anything. OPEN means you can do something, but exactly what 
>> is all in other attributes.
> 

No, I'm not. I thought you were. So I was simply demonstrating how it 
can be provided if wanted.

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

> standardized, or come in the form of freetext notes.

My world isn't binary either.

But I thought that now things like "do-not-disturb", "busy", 
"inconvenienced" are attributes of the person, not the service. So we 
don't have a way to say do-not-disturb for a service.

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

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.

	Paul