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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Mar 2004 14:29:42 -0500

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 12:47:03 -0800

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