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

From: [email-masked]
Date: Mon, 5 Apr 2004 11:18:40 +0300

The issue has completely changed from "should a conference policy indicate that a participant is hidden or not?" to "should a conference policy indicate roles of participants?"

The latter question requires the conference creator to know, beforehand, the roles of the potential participants. I don't think that is feasible.

If the roles are to be expressed as attributes in a URI or header, may I suggest that this be a signalling protocol problem. I.e. When a participant joins a conference by sending an INVITE (in SIP terms), then it includes a header defining it role (or it can put a caps attribute in the contact header). Similarly for the Dial outs, the participant indicates it role in the 200 Ok.

/Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Michael Hammer
> Sent: 19.March.2004 23:21
> To: Paul Kyzivat
> Cc: Rohan Mahy; [email-masked]; Eric Burger; Rosen, Brian; 'Kozdon,
> Peter'; 'Adam Roach'
> Subject: Re: [XCON] Open Issue: Hideable Participants
> 
> 
> 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:
> >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:
> >>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.
> >>>
> >>>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.
> >>
> >>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.
> >>
> >>>Regarding how to denote a recorder, I think the existing 
> message-taker 
> >>>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.
> >>
> >>>I think what we are talking about can be achieved by exposing the 
> >>>contact parameters from each participant in CPCP.
> >>
> >>sometimes.
> >>thanks,
> >>-r
> >>
> >>>     Paul
> >>>
> >>>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?
> >>>>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
> >>>
> >
> >
> >_______________________________________________
> >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