Re: [XCON] Open Issue: Hideable Participants

[Rohan Mahy <[e-mail]>]

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:[e-mail]]
>> Sent: Thursday, March 11, 2004 4:23 PM
>> To: Rosen, Brian
>> Cc: [e-mail]; 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:[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