Subject: [clue] Minutes: Design Team Meeting - Jan. 24th, 2012

From: Mary Barnes <[email-masked]>
Date: Wed, 25 Jan 2012 15:00:49 -0600

Hi all,

Below, please find the minutes from the design team meeting held on
Jan 24th, 2012.   The minutes are also on the wiki.  Thanks to
John Leslie and Paul for taking notes.
http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team

I'll send the agenda and Webex details for next Tuesday's call (Jan
31st) by Friday.

Regards,
Mary.
============================================

CLUE WG Design Team Call   January 24th, 2012
Chairs: Mary Barnes, Paul Kyzivat

Attendees:
Espen Berger
Stephane Cazeaux
Spencer Dawkins
Mark Duckworth
Marshall Eubanks
Roni Even
Tom Kristensen
Jonathan Lennox
John Leslie

Summary:
Mary provided an update on the action items from the meeting last week
- all of which were completed.   The meeting discussion focused on
Ticket #7, with the majority supporting the need for additional
attributes in the case that the composed boolean is true.  Additional
WG discussion is required to define the additional attributes to
describe the composed stream.   Whether a boolean is needed if
additional attributes are defined requires further discussion.

Summary of action items:
- Ticket #3.  Update ticket to reflect Roni's email with regards to
RTCWEB use case. [Chairs]   Provide feedback on proposal. [WG]
- Ticket #6.  Chairs confirmed that source selection is in the
charter, thus this ticket is to be closed. [Chairs]
- Ticket #7.  Post proposed attributes to the mailing list [Roni and others]

Notes by Paul Kyzivat
Start Time: 10:00 EST 24-jan-1012
End Time: 10:00 EST 24-jan-1012

Reviewed Active Tickets

Agreed #6 is already in charter. Will close it out.

Discussed description of composed stream.
John Leslie said he thought complexity of describing
composed stream to too great to make required.

Roni says the issue on the table is whether we should
be *able* to describe it. Whether its mandatory
is a separate question.

Mark asks if the description should be in the initial
framework or left for a subsequent revision.

Roni says if all we have is a boolean, then it is
useless to offer more than one composed stream,
because there is no basis to chose between them.

Roni to post more info about composition algorithms.

We didn't reach any conclusion about how much information should be
included. Decision to take it to the list to discuss alternatives.
Proposal that people use the remaining 15 minutes of meeting time to
email something.

Notes by John Leslie
Mary Barnes @ 1005
John Leslie volunteered to take notes
Mary: Roll Call: Roni, Marshall, Spencer, Stephane;
Mary: Tickets: closed 2, opened 7 (want to talk about 7 today); #5
added link to Stephane proposal; #6 believe it is in-charter "which
sources the receiver wants to receive", will close that one
Mary: talk through issue #7; Roni posted a note to mailing-list, not
sure everybody on same page.
Spencer: trying to find that post...
Mary: go to ticket #2 (link on ticket #7)... post shared...
John: complexity of showing details of capture is to great to make it mandatory
Roni: I described simple case (typical); question is whether we should
address this and specify it; whether it is mandatory is a separate
issue
Mary: I think we need the boolean anyway
Mark: I think Roni is saying we need description in initial version,
not a later extension
Roni: if we agree info, we should give a way
Mary: question whether we can put off describing it to an extension
Roni: I'm OK with any way to describe it, but we need some way,
otherwise it's useless, I cannot differentiate switching mode
Mark: Roni is correct, but he didn't answer Mary's question
Roni: we don't have any data structure...
Mary: think Roni is saying we shouldn't have a boolean and a later structure
Roni: not saying that
Mary: why wouldn't that work for you
Roni: we need to discuss whether there's a way to describe composed
Mark: if you have more than one composed screen, you can't distinguish
them... leads people on... leap of faith on what the form of composed
is (and how to display)
Roni: what you do different is a huge issue... let's say author offers
you a "composed" switch... as a consumer you can decide which to take
if offered three different screens
Mark?: suppose I only have only one screen, is "composed" a better choice?
Marshall: you assume somebody put work into the "composed"... leap of faith
Spencer: leap of faith may be reasonable for first pass
Marshall: I would give more of screen to a "composed", lacking other info
Mark: sounds to me as if people are saying there should be more info
John: but we don't know what that info is
Mark: I could imagine an enumerated cases from Roni's list
John: any enumerated list would have to be extensible
Marshall: most common case is composed includes some of the others --
that's useful
Mark: for endpoint, that's useful, but not for middlebox
Marshall: free-text allows end-user to choose
Espen: question, extensible to express detail, how it's composed may
not be needed...
Mary: seems a couple of people perfectly happy with boolean, but
perhaps we'd agree on some more info, but I don't hear consensus on
what
Marshall: free-text next level, list of parts second, geometry is more
complex, temporal changes is yet another level, most-active-speaker is
a common use case
Roni: different switching mechanisms, don't see why enumerated list of
modes isn't the right first-case
Mary: can you post that to the mailing-list; throw that out and we'll
discuss on-list
Roni: people have interest in more information, I'll propose something on-list
Mary: question of whether boolean is enough... "none" would be one of
your enumerated cases
Mark: this whole discussion applies to "auto-swithed" which is also a
boolean, seems like that's where the enumerated list belongs
Roni: disagree... (examples)
Mark: auto-swithched was intended to tell nothing about how it's switched
Mary: I think we've discussed this one enough on this call, anything
else to discuss today
1045 adjourn