Subject: [XCON] Review of draft-ietf-xcon-framework-06

From: "Sperounes, Gregory \(Gregory\)" <[email-masked]>
Date: Thu, 18 Jan 2007 14:30:56 -0500

Review of draft-ietf-xcon-framework-06:

------
In 9.4.1 

"Alice" and "Bob" would remain on the roster of the main conference such
that the other participants would be unaware of the sidebar.
-------

-------
The statement above should probably state:

"Alice" and "Bob" would remain on the roster of the main conference such
that other participants could be aware of their participation in the
main conference while an internal-sidebar conference (or whisper) is
occurring.
-------

The state of internal/external sidebar should be used to denote
main-conference audio mixing while in a sidebar conference.

The concern at the heart of this comment is for clarity of state in the
framework.

An application can expose the whisper state, or show it as a kind of
muted state, or hide the whisper state entirely, but the framework
should expose a very clear state of all participants and conferences and
sidebars, without inferring or hiding state.

I completely agree with the concept of remaining on the meeting roster,
because the participation in the meeting, is separate from being in
a room or sidebar. 

Can the notifications that a client receives, be
managed/filtered/interpreted, by the focus based on the role of the
client after authentication and authorization?

Some means of  interpreting state changes before notifying particular
clients should exist, so long as the heart of the framework provides a
clear indication of all states.   

-------
In the next section 9.4.2, there is a suggestion that the
external-sidebar state be denoted by a hold-state indication.

"Alice" initiates the sidebar by sending a request to the conferencing
system to create a conference reservation based upon the active
conference object.  "Alice", "Bob" and "Ethel" would remain on the
roster of the main conference in a hold state."
-------

The same concern and comment applies:

The framework should be able to clearly expose the external-sidebar
state and allow the application to interpret and present that as an
external-sidebar state, a hold-state, a locked sidebar state, or some
other sidebar state. If there is some means by which the actual state
can be converted or interpreted for specific clients that should be
identified as separate from the actual framework behavior and state
information. 

The heart of the framework should not be masking, or inferring state,
when the actual state is much clearer and provides a more powerful means
of controlling, and negotiating end user perceptions and options.

In the two examples of internal and external sidebars, the state shown
in the roster, may collide in undesirable ways with self-muted and
chair-muted, or self-held and chair-held states, when participants are
actually in sidebars, or when they return form sidebars, or when more
superior applications would benefit from the clarity of sidebar state
information for security purposes.

----------
Along this line of reasoning:

The framework should be able to clearly expose the cause of appearing to
be muted in a conference 
as a result of being a self-muted, a chair-muted (or silenced) , an
operator-muted, conference-feature-muted (lecture, mute-all, Q&A), or
menu-muted (for DTMF commands, or IVR routines). 

All of these mutes for a participant overlap and become important
information for superb application experiences.
The end user may only see isMuted as a light on their screen, the
framework should be able to individually
manipulate the various overlapping and intermingling causes for a mute
state.

I may be interpreting the framework draft examples too precisely.
I thought it would be worth mentioning in case the boundary between
framework state and end-user experience are being blurred.

Greg Sperounes
Conferencing API Team, GCS/UCD
Avaya Inc
+1-978-677-5096

Included: Referenced excerpts in context

9.4.1.  Internal Sidebar

   Figure 12 provides an example of one client "Alice" involved in
   active conference with "Bob" and "Carol".  "Alice" wants to create a
   sidebar to have a side discussion with "Bob" while still viewing the
   video associated with the main conference.  Alternatively, the audio
   from the main conference could be maintained at a reduced volume.
   "Alice" initiates the sidebar by sending a request to the
   conferencing system to create a conference reservation based upon the
   active conference object.  "Alice" and "Bob" would remain on the
   roster of the main conference such that the other participants would
   be unaware of the sidebar.

9.4.2.  External Sidebar

   Figure 13 provides an example of one client "Alice" involved in an
   active conference with "Bob", "Carol", "David" and "Ethel".  "Alice"
   gets an important text message via a whisper from "Bob" that a
   critical customer needs to talk to "Alice", "Bob" and "Ethel".
   "Alice" creates a sidebar to have a side discussion with the customer
   "Fred" including the participants in the current conference with the
   exception of "Carol" and "David", who remain in the active
   conference.  "Alice" initiates the sidebar by sending a request to
   the conferencing system to create a conference reservation based upon
   the active conference object.  "Alice", "Bob" and "Ethel" would
   remain on the roster of the main conference in a hold state.  Whether
   or not the hold state of these participants is visible to other
   participants depends upon the individual and local policy.

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

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 19 Jan 2007 15:20:58 -0600

Hi Gregory,

Thanks for your comments.  I'm replying from my gmail account as my usual
email server is down right now.  My responses are below [MB].

Just to give folks some time to comment, I'll wait till noon CST on Monday,
January 22nd to submit the updated document.

Mary.

On 1/18/07, "Sperounes, Gregory \(Gregory\)" <sperounes at
avaya.com<[email-masked]>>
wrote:
> that other participants could be aware of their participation in the main
> conference while an internal-sidebar conference (or whisper) is occurring.
>
> -------
>

[MB] Agreed. I'll make this change.

> An application can expose the whisper state, or show it as a kind of muted
> state, or hide the whisper state entirely, but the framework should expose a
> very clear state of all participants and conferences and sidebars, without
> inferring or hiding state.
>
> managed/filtered/interpreted, by the focus based on the role of the client
> after authentication and authorization?
>
[MB] Yes, that's the intent and I think it's fairly clear per the text in
section 8.2 (Notifications).  I could further expand the text that I have in
the examples where it mentions that notifications are sent to indicate that
it is, of course, also based on the role, etc. if folks think that's
necessary?
[/MB]

> clients should exist, so long as the heart of the framework provides a clear
> indication of all states.
>
> -------
> In the next section 9.4.2, there is a suggestion that the external-sidebar
> state be denoted by a hold-state indication.
>
> system to create a conference reservation based upon the active conference
> object.  "Alice", "Bob" and "Ethel" would remain on the roster of the main
> conference in a hold state."
>
> -------
>
> The framework should be able to clearly expose the external-sidebar state
> and allow the application to interpret and present that as an
> external-sidebar state, a hold-state, a locked sidebar state, or some other
> sidebar state. If there is some means by which the actual state can be
> converted or interpreted for specific clients that should be identified as
> separate from the actual framework behavior and state information.
>
> The heart of the framework should not be masking, or inferring state, when
> the actual state is much clearer and provides a more powerful means of
> controlling, and negotiating end user perceptions and options.
>
> In the two examples of internal and external sidebars, the state shown in
> the roster, may collide in undesirable ways with self-muted and chair-muted,
> or self-held and chair-held states, when participants are actually in
> sidebars, or when they return form sidebars, or when more superior
> applications would benefit from the clarity of sidebar state information for
> security purposes.
>
> ----------
[MB]  The basic intent of these examples in the  framework document was to
show how the logical elements fit together and the basic flow of control
between the different logical functions and the messaging at a high level.
The actual details of the data to be manipulated by the framework and the
data to be sent over the signaling interfaces is out of scope and will be
defined by the detailed data model and the detailed specification of the
conference control protocol and any new conference event packages that are
determined to be necessary for the notifications.  The introductory text in
section 9 is intended to set the scope for the examples.  In reality we will
need a much more detailed set of scenarios to show the exact details from
the data model and conference control protocol once those details are all
worked out.   I should perhaps change that first sentence to be very
explicit that the states mentioned in these scenarios are also for
illustrative purposes and do not necessarily reflect the detailed states
represented in the data model, something like the following:
OLD:
The details shown in the messages are for illustrative purposes only and
don't reflect the structure of the conference control protocol messages, but
rather provide a high level primitive view of the necessary operations and
general logic flow, including the data manipulation aspects.

NEW:
The scenarios provide a high level primitive view of the necessary
operations and general logic flow. The details shown in the scenarios are
for illustrative purposes only and don't necessarily reflect the actual
structure of the conference control protocol messages nor the detailed data,
including states, which are defined in separate documents.
[/MB]

 Greg Sperounes
> XCON at ietf.orghttps://www1.ietf.org/mailman/listinfo/xcon
>
>