Subject: RE: [XCON] Open Issue: Hideable Participants

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Mar 2004 17:26:44 -0500

Somehow, you think there are fewer attributes than roles.
I think there are fewer roles than attributes.
Reiterating - i think its easier to infer attributes knowing roles
than it is to infer roles knowing attributes.  I don't
see much utility in delivering both.

The fact that it's an ass is the important part; i don't think that we
can provide information figure out which ones are interesting and
which ones are not.

Brian
-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Thursday, March 11, 2004 5:16 PM
To: Rosen, Brian
Cc: [email-masked]; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam Roach'
Subject: Re: [XCON] Open Issue: Hideable Participants

OK, 

We had a semantic problem with the word "roster". Let me try once more using
your sense of the word roster: 

we are trying to tell if your UI should show the donkey or not *from* the
roster, and you 
clearly can’t do that if some asses are interesting and others are not. 

using the example of the human scribe, this is clearly impossible to decide
why your UI shouldn't display the human scribe unless you define a new
attribute, *or* define a gigantic explosion of roles, conditional roles, and
subroles. 

thanks, 
-rohan 

On Mar 11, 2004, at 1:59 PM, Rosen, Brian wrote: 

Huh? I thought we already agreed, all participants go in the roster. 
We're talking about what information you supply about the participants 
so that an entity recieving the roster can do interesting things with 
it; we observe that which participants are rendered, and how they 
are rendered, is a local decision, but that decision needs information. 
I'm mostly interested in things like icons representing services in the 
conference. While the caps identified might be useful, they aren't 
enough, and I don't want to solve the problem by inventing a bunch more 
caps. I'd go so far as to suggest that we remove the recorder mechanism, 
and just make it a role. 

-----Original Message----- 
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Thursday, March 11, 2004 4:53 PM 
To: Rosen, Brian 
Cc: [email-masked]; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam 
Roach' 
Subject: Re: [XCON] Open Issue: Hideable Participants 

On Mar 11, 2004, at 1:36 PM, Rosen, Brian wrote: 

So, this is a discussion of "do you want the characteristics of 
a participant, or a description of it". 

Seems to me that since this is not a protocol mechanism, it's a 
UI issue, that you want a description and not a set of 
characteristics. 
It's pretty easy to figure out what an IVR box does, but its pretty 
hard to figure out that it is an IVR box from a set of caps. 
Infer that it's a donkey from a description of the parts 
vs infer what parts are available knowing it's a donkey. 

if its really relevant to know that its a donkey, then use a 
description/role/whatever. However, *STAYING ON TOPIC*, we 
are trying 
to tell if you should show the donkey or not in the roster, and you 
clearly can't do that if some asses are interesting and 
others are not. 

thx, 
-r 

Since I can always arrange a UI to display characteristics if 
I know what role, but can't go the other way, I think role is 
best. 

Brian 

-----Original Message----- 
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Thursday, March 11, 2004 4:23 PM 
To: Rosen, Brian 
Cc: [email-masked]; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam 
Roach' 
Subject: Re: [XCON] Open Issue: Hideable Participants 

On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: 
What attributes does an IVR box have besides automaton? 
How about a caption service? 

If we create a caps for each service, all orthogonal, is that 
you think makes sense? 

no, i'm not proposing a cap for each service. it is this 
"facilitator" 
attribute that all of these roles *share* that causes my UI to hide 
them in the roster. I don't want to have to update my UI 
(which hid 
IVRs, announcers, human scribes, and recording services) so 
that I will 
hide the caption service you just added. 

if you feel you need to add roles for these services, go 
right ahead. 
I don't object to having names roles, but I want my UI to refer to 
attributes where I think attributes are appropriate. [The 
mere fact 
that all these services I just listed have something in 
common which is 
orthogonal to all the other attributes we have should be a 
strong clue 
that this "facilitator" property should be an attribute.] 

thanks, 
-rohan 

These are all roles, they are not attributes. 

Brian 

-----Original Message----- 
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Thursday, March 11, 2004 3:47 PM 
To: Rosen, Brian 
Cc: [email-masked]; Eric Burger; Rohan Mahy; 'Kozdon, 
Peter'; 'Adam 
Roach' 
Subject: Re: [XCON] Open Issue: Hideable Participants 

Hi, 

<disclaimer>I'd like to apologize to the group that some of 
these ideas 
are SIP-specific or very SIP influenced</disclaimer> 

Here are the binary or ternary attributes that already exist from 
draft-ietf-sip-callee-caps: 

automaton/human 
personal/business 
mobile/fixed 
duplex/send-only/receive-only 

these are 100% orthogonal with respect to each other 

Various folks have proposed that we need the following additional 
attributes in various parts of conferencing and/or signaling: 

interactive/noninteractive 
anonymous/identified 

(again, these are 100% orthogonal with respect to each 
other and the 
other attributes) 

finally I am proposing this new attribute we have been 
describing here. 
I believe this is still highly orthogonal to the other 
attributes. 

I believe this new attribute is more appropriate than an 
enumerations 
for two main reasons: 

1) you can code behavior based on the presence of the attribute 
directly rather than checking for a bunch different 
roles and then 
making sure there are not conditions attached to those roles. 
2) it allows a new thing/role to exist which we haven't 
thought of yet 
that can still unambiguously provide its attributes. 
existing code 
will work quite well with this new thing if it describes 
itself using 
(in part) a number of existing attributes. 

thanks, 
-rohan 

On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: 

Rohan 

I'm not sure I agree. I clearly do want to provide 
information across 
the wire unambiguously, but I don't think a lot of binary 
attributes 
is a good way to do that. I think we are talking about a 
role, rather 
than an attribute. A single automaton, like a single 
human, is capable 
of multiple roles, so you need a list in both cases. 

Brian 

-----Original Message----- 
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Thursday, March 11, 2004 2:24 PM 
To: Rosen, Brian 
Cc: [email-masked]; Eric Burger; Rohan Mahy; 'Kozdon, 
Peter'; 'Adam 
Roach' 
Subject: Re: [XCON] Open Issue: Hideable Participants 

Brian, 

There are many different orthogonal attributes we should be 
able to get 
access to. This "non-interesting" participant or "facilitator" 
attribute is orthogonal to your status as an automaton 
or human. I 
don't think an enumeration here is a good substitute for this 
attribute. It may be that indicating a recorder is a good 
value to add 
to the "actor" media feature tag, which currently has 
a msg-taker 
value, or that we can reuse the msg-taker value for the 
recorder. The 
goal is maximum orthogonality. We probably can't 
achieve complete 
orthogonality but I think we can get very close. 

thanks, 
-rohan 

On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: 

Seems to me that you are on the right track, but we need to 
go farther. 
We have to classify these participants so that the UI, if 
it wanted to, 
could render an appropriate indication. The example of 
the recorder 
is pretty compelling. Just knowing that there is an 
automaton out 
there 
is one thing. Knowing its a recorder is another. So, 
really you 
don't want a flag, you want an enunumeration. It may 
actually be 
a list, because a single automaton could have multiple 
functions. 

Brian 

-----Original Message----- 
From: Adam Roach [mailto:[email-masked]] 
Sent: Thursday, March 11, 2004 12:27 AM 
To: 'Kozdon, Peter'; Eric Burger; [email-masked] 
Subject: RE: [XCON] Open Issue: Hideable Participants 

[not as chair] 

I don't think anyone is currently arguing whether indication 
of such automata should be available to the users. Most 
of what I've heard people say on this list -- after Korea, 
at least -- seems to agree that such elements *should* 
be indicated in the protocol. Note that this is not the 
same thing as saying that they must be forcibly rendered 
to users regardless of the users want, which is what you 
seem to be arguing for. 

What I've heard -- and I agree with this viewpoint -- is 
that there should be some flag that indicates "this element 
is a facilitator, not a participant," so that users who don't 
*care* about seeing such elements (existence proof: me) 
could configure their clients not to display them. 

To expand on the flag's meaning, it would make the most 
sense to have it mean more precisely "this element is not 
truly a participant, but is providing some service related 
to the conference." In other words, I would want it to 
cover e.g. human transcribers, human translators, etc., 
in addition to automata. 

As Eric points out, I think people are getting hung up on 
the name without thinking the issue through completely. 
I've updated the subject line accordingly. 

/a 

-----Original Message----- 
From: Kozdon, Peter [mailto:[email-masked]] 
Sent: Wednesday, March 10, 2004 20:50 
To: Eric Burger; [email-masked] 
Subject: RE: [XCON] Open Issue: Hidden Participants 

I agree that automatons are processing resources 
and could be 
considered as 
logical parts of the conference fabric, for example an IVR 
could monitor the 
conference and provide a trigger in response to a phrase 
that could be 
consumed elsewhere. Similarly a device that announces 
participants, etc.. 
However, IMHO a conference recorder does not fall into this 
category and 
should probably be a visible resource maybe with an 
indicator to show 
whether it is or is not active. Similarly - a player 
resources which 
delivers content or information to the conference 
should also 
be visible - 
it seems desirable to know where such content is 
coming from. 

-----Original Message----- 
From: Eric Burger [mailto:[email-masked]] 
Sent: Tuesday, March 09, 2004 1:28 PM 
To: Kozdon, Peter; [email-masked] 
Subject: RE: [XCON] Open Issue: Hidden Participants 

I think we got caught up on the name. 

There are two needs. 

The first, which I think we may have consensus on, is the 
need for anonymous 
participants. That is, participants that are present in the 
conference, but 
do not have their identities revealed. 

The second, which is more blurry, is the need for 
participants that are 
truly hidden. Some want to use hidden participants for 
automatons, e.g., 
IVR systems or conference recorders. (IMHO, bad idea, but 
that is really 
just MHO, not strictly black-and-white.) 

We do have consensus that Lawful Intercept is entirely 
orthogonal to 
conference participants. However, the logic of the above 
follows. Just as 
IVR systems or conference recorders are not really 
participants, neither is 
LI hardware. If we say that the approach for IVR 
is to plumb 
in as a hidden 
participant, then LI would have the same approach. 
If we say 
that IVR is 
something different, e.g., just a part of the conference 
mixer, then it is 
truly "not there". Likewise, I would expect LI to be 
"not there" -- 
something outside the XCON framework entirely. 

-----Original Message----- 
From: Kozdon, Peter [mailto:[email-masked]] 
Sent: Monday, March 08, 2004 6:28 PM 
To: [email-masked]' 
Subject: RE: [XCON] Open Issue: Hidden Participants 

Hidden listeners operation is probably illegal in many US 
states as 
well as in many countries - when you make a call there is a 
requirement in California the all parties are aware of the 
presence of 
a 3rd party or recording device, note- that party may be 
anonymous, 
etc.. 
(Exception -- 
legal intercept.) 

We should follow the similar logic for XCON - provide an 
indication of 
a recording device and/or anonymous participant's) 

Peter Kozdon 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] On 
Behalf Of 
Adam Roach 
Sent: Monday, March 08, 2004 12:04 PM 
To: [email-masked]' 
Subject: [XCON] Open Issue: Hidden Participants 

[as chair] 

At the XCON meeting, there was a rather lively 
discussion that 
continued the "Hidden Participants" discussion that had 
started on the 
list. It was agreed that the topic was worth discussion, 
but that we 
did not have enough time to pursue it in the meeting. 

I'm calling on everyone, especially those involved in 
the meeting 
discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to 
continue this 
discussion so we can close this issue in the near future. 
Alan and I 
would like to be able to last-call this document shortly, 
and this is 
the key issue that needs to be resolved before a new 
revision of the 
draft can be produced. 

/a 

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

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

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

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

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

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

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 11 Mar 2004 16:57:32 -0800

> can provide information figure out which ones are interesting and

You need to demonstrate this assertion then.  What would you do with 
the knowledge of a role.  I already showed how based on the "hide-able" 
attribute I can do something useful for a variety of roles.  The burden 
of proof is on you to show how I can do anything useful with roles 
without needed an explosion of them.

thanks,
-rohan