Re: [XCON] Open Issue: Hideable Participants

[Rohan Mahy <[e-mail]>]

On Mar 11, 2004, at 2:26 PM, Rosen, Brian wrote:

> Somehow, you think there are fewer attributes than roles.
> I think there are fewer roles than attributes.
> Reiterating - i think its easier to infer attributes knowing roles
> than it is to infer roles knowing attributes.  I don't
> see much utility in delivering both.
>
> The fact that it's an ass is the important part; i don't think that we
> can provide information figure out which ones are interesting and
> which ones are not.

You need to demonstrate this assertion then.  What would you do with 
the knowledge of a role.  I already showed how based on the "hide-able" 
attribute I can do something useful for a variety of roles.  The burden 
of proof is on you to show how I can do anything useful with roles 
without needed an explosion of them.

thanks,
-rohan

> Brian
> -----Original Message-----
> From: Rohan Mahy [mailto:[e-mail]]
> Sent: Thursday, March 11, 2004 5:16 PM
> To: Rosen, Brian
> Cc: [e-mail]; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam 
> Roach'
> Subject: Re: [XCON] Open Issue: Hideable Participants
>
>
> OK,
>
>
> We had a semantic problem with the word "roster". Let me try once more 
> using
> your sense of the word roster:
>
>
> we are trying to tell if your UI should show the donkey or not *from* 
> the
> roster, and you
> clearly can’t do that if some asses are interesting and others are not.
>
>
> using the example of the human scribe, this is clearly impossible to 
> decide
> why your UI shouldn't display the human scribe unless you define a new
> attribute, *or* define a gigantic explosion of roles, conditional 
> roles, and
> subroles.
>
>
> thanks,
> -rohan
>
>
>
> On Mar 11, 2004, at 1:59 PM, Rosen, Brian wrote:
>
>
> Huh? I thought we already agreed, all participants go in the roster.
> We're talking about what information you supply about the participants
> so that an entity recieving the roster can do interesting things with
> it; we observe that which participants are rendered, and how they
> are rendered, is a local decision, but that decision needs information.
> I'm mostly interested in things like icons representing services in the
> conference. While the caps identified might be useful, they aren't
> enough, and I don't want to solve the problem by inventing a bunch more
> caps. I'd go so far as to suggest that we remove the recorder 
> mechanism,
> and just make it a role.
>
>
> -----Original Message-----
> From: Rohan Mahy [mailto:[e-mail]]
> Sent: Thursday, March 11, 2004 4:53 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 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


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