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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Mar 2004 15:53:27 -0500

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?

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: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Mar 2004 16:14:04 -0500

Lets not get hung up on whether we call it a role or an attribute. Many 
of the callee-caps things can be considered to be roles.

Regarding Rohan saying there is another new attribute - I don't know 
what that is. Are you talking about a "hideable" attribute? I don't 
think that makes much sense. It puts the responsibility on the focus to 
decide what should be hideable. I think it is better for clients to each 
decide what they do/don't want to see. I may want to hide automata and 
attendants except that I want to see recorders. You may just decide to 
hide automata.

Regarding how to denote a recorder, I think the existing message-taker 
feature tag is probably close enough for the purpose.

I think what we are talking about can be achieved by exposing the 
contact parameters from each participant in CPCP.

	Paul

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 11 Mar 2004 13:22:58 -0800

> If we create a caps for each service, all orthogonal, is that

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

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 11 Mar 2004 14:42:17 -0800

I was so busy trying to get back to the original purpose of this thread 
that forgot to answer Brian question directly.

> What attributes does an IVR box have besides automaton?

business (typically)
fixed (typically)
automaton
interactive
full duplex
its supported media (audio, video, text)

> How about a caption service?

this is really 2 participants.  the listener/watcher and the captions 
themselves.  note that a caption service probably does not assume a 
class (biz/personal).

listener:
automaton (sometimes, more typically a human)
fixed (almost certainly)
non-interactive
receive-only
audio and/or video

captioner:
automaton (sometimes, more typically a human)
fixed (almost certainly)
non-interactive
send-only
text

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 11 Mar 2004 17:06:53 -0800

Paul,

On Mar 11, 2004, at 1:14 PM, Paul Kyzivat wrote:
> Lets not get hung up on whether we call it a role or an attribute. 
> Many of the callee-caps things can be considered to be roles.
>
> think that makes much sense. It puts the responsibility on the focus 
> to decide what should be hideable.

yes.  It makes the focus responsible for setting and believing this 
attribute. I think this is an excellent thing.  IMO, the focus is the 
only entity that can do a reasonable job of this.

> I think it is better for clients to each decide what they do/don't 
> want to see. I may want to hide automata and attendants except that I 
> want to see recorders. You may just decide to hide automata.

feel free to do that, but you may not like the results.  what if the 
predominantly interesting thing in the conference is an automaton with 
VCR-style controls that the humans in the group are annotating?  What 
if the automata is providing other useful information as a participant 
(rendering a summary of last months sales figures for example).  I 
think the "ignore automatons" approach.  It also doesn't allow you to 
ignore the "tea lady" participant or the "human scribe" participant.

> feature tag is probably close enough for the purpose.

this may be reasonable, but there are slightly different routing 
semantics if I want my call routed to someone/something who can take a 
message for me, and something that just records what I said.

> contact parameters from each participant in CPCP.

sometimes.

thanks,
-r

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 13 Mar 2004 17:27:05 -0500

Replying to this whole thread, not just to Rohan...

It seems to me that this discussion is replicating that which took place 
around presence, in how to define "services". I have the impression that 
what Brian is calling "role" here is similar to what others have called 
"service" there.

In the presence case we could find no useful unique way to define a 
service, and decided it was largely in the eye of the beholder. So we 
decided that we should just describe the features of a presentity, and 
let the watchers interpret certain collections of features as a service.

The same should work here, although the application is a bit simpler. It 
is simply a matter of a client deciding what combination of features 
constitue a participant that is/isn't interesting to that client.

Whether "hideable" is a distinct feature is a separate question. I am 
inclined to think it is not, because whether something is hideable is a 
subjective decision, and not everyone will want to make the same decision.

	Paul

Rohan Mahy wrote:
> VCR-style controls that the humans in the group are annotating?  What if 
> the automata is providing other useful information as a participant 
> (rendering a summary of last months sales figures for example).  I think 
> the "ignore automatons" approach.  It also doesn't allow you to ignore 
> the "tea lady" participant or the "human scribe" participant.
>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 19 Mar 2004 16:20:50 -0500

Likewise to the whole thread.  (Apologies for the late comment.)

A user may not care whether an indicator is a primitive (attribute?) or a 
constructor (role?), but when I read the list of values suggested in this 
list thus far it is not clear to me which ones other than perhaps 
message-taker (a little vague as to what that means -- verbatim or summary) 
or recorder will result in someone playing my words back to me and making 
me eat them.  For legal purposes, any participant that records the 
conversation (probably audio or video) will need to have an unambiguous 
indication to each participant.  Facilitator and automaton do not tell me 
much of anything.

Also, I would suggest (to keep clear of lawful intercept stuff) to describe 
this as "Displayable Participants".  As Paul notes, this is really a UI 
issue, based on useful indications in the protocol.

Mike

At 05:27 PM 3/13/2004 -0500, Paul Kyzivat wrote:
>decided that we should just describe the features of a presentity, and let 
>the watchers interpret certain collections of features as a service.
>
>>>decide what should be hideable.
>>
>>>I think it is better for clients to each decide what they do/don't want 
>>>to see. I may want to hide automata and attendants except that I want to 
>>>see recorders. You may just decide to hide automata.
>>
>>>>>here.  I believe this is still highly orthogonal to the other attributes.
>>>>>
>>>>>2) it allows a new thing/role to exist which we haven't thought of yet