Re: [XCON] Open Issue: Hideable Participants

[Rohan Mahy <[e-mail]>]

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:[e-mail]]
>>> Sent: Thursday, March 11, 2004 3:47 PM
>>> To: Rosen, Brian
>>> Cc: [e-mail]; 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:[e-mail]]
>>>>> Sent: Thursday, March 11, 2004 2:24 PM
>>>>> To: Rosen, Brian
>>>>> Cc: [e-mail]; 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:[e-mail]]
>>>>>>> Sent: Thursday, March 11, 2004 12:27 AM
>>>>>>> To: 'Kozdon, Peter'; Eric Burger; [e-mail]
>>>>>>> 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:[e-mail]]
>>>>>>>> Sent: Wednesday, March 10, 2004 20:50
>>>>>>>> To: Eric Burger; [e-mail]
>>>>>>>> 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:[e-mail]]
>>>>>>>> Sent: Tuesday, March 09, 2004 1:28 PM
>>>>>>>> To: Kozdon, Peter; [e-mail]
>>>>>>>> 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:[e-mail]]
>>>>>>>>> Sent: Monday, March 08, 2004 6:28 PM
>>>>>>>>> To: '[e-mail]'
>>>>>>>>> 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: [e-mail] [mailto:[e-mail]] On
>>>>>>>>
>>>>>>> Behalf Of
>>>>>>>
>>>>>>>>> Adam Roach
>>>>>>>>> Sent: Monday, March 08, 2004 12:04 PM
>>>>>>>>> To: '[e-mail]'
>>>>>>>>> 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
>>>>>>>>> [e-mail]
>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> XCON mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> XCON mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> XCON mailing list
>>>>>>> [e-mail]
>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> XCON mailing list
>>>>>> [e-mail]
>>>>>> https://www1.ietf.org/mailman/listinfo/xcon
>>>>>
>> _______________________________________________
>> XCON mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/xcon
>


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